Live data from Hacker News

JMAP: Like IMAP but Not Really

unencumberedbyfacts.com

231–235 of 235 posts

Re: JMAP: Like IMAP but Not Really

#231

Earlier quoted context omitted.

Here's a few things: - constantly changing things around. UI gets less intuitive for every release. - slower for every release - violates IMAP standard by re-using IDs across tags/IMAP folders, risking actual data loss. Example: if you in a real email-client try to delete a email from a single folder, you will also delete this email from all other folders it has been "tagged" in. - similar IMAP issues with sent email…

The messed up deletion behavior baffles me to this day. The stock mail app on iOS will behave correctly if you muck with the Gmail POP/IMAP settings and turn off 'Archive' in MobileMail, but I have zero confidence that this will work on macOS because Apple pays less attention to the desktop and Gmail don't give a crap if actual client applications work correctly. They just assume everyone uses the web interface.

> They just assume everyone uses the web interface.

More likely, they want you using their app and their web interface, and merely tolerate third party apps. For now.

Google wants you in the Googleverse forever.

Re: JMAP: Like IMAP but Not Really

#232
post #224
post #183

Earlier quoted context omitted.

> if someone had just jammed XMPP and SMTP together. Xmpp is/supports federated/ion (user1@server1.com can message user2@server2.com). But the major players (by numbers) wanted silos: Google (talk) and fasebook (first gen of messenger). They basically went lol, screw users (arguably because: spam. But hello, Gmail? And today fb spam...). So thank Google and Facebook for deliberately gimping it so you can't fb message…

The official reason for Google to give up on this is that there was a real problem of incoming spam from lousy domains, and no major player wanted to play the federation game with them. It's not as simple as you make it sound.

1) they are able (forced to) handle spam for Gmail (and internally for gtalk) - I'm not convinced by the spam argument.

2) there were only two "big" players, Google and Facebook. The benefit of federation would be as with email: an open internet with federation across organisation level services (community/company run servers).

The fact that Google didn't implement ssl for federation doesn't mean people "wouldn't" federate with them, it mean Google didn't make a real effort.

Re: JMAP: Like IMAP but Not Really

#233
post #79
post #59

Earlier quoted context omitted.

> ...Gmail does many things well, except for being a good email service. Gmail/Gsuite seem to be good email services from my perspective as lay user and occasional admin. Can you expand on why you think they are not good email services?

I’m not a fan of Gmail either, mostly because it lacks push vis iOS Mail (which Fastmail supports, so it is possible), and its non-standard tagging system doesn’t not play well with any third-party client that does not take extraordinary steps to accommodate it. Folders are better. Its proprietary apps are terrible and its web interface is weird, unintuitive, ugly, and slow.

I find it's "non standard" tagging system is a massively superior model for managing email. I really wish there were alternatives that did similar, and a protocol like IMAP or JMAP that assumed the tagging based model underneath.

Re: JMAP: Like IMAP but Not Really

#234

Earlier quoted context omitted.

I considered FM a while back but... you pay per account! $50/account no less! I separate my email into three accounts across two domains and my wife does the same and I have kids who'll have their own email addresses at some point. I can't even begin to consider using it at the price point I presume I'd be in.

$30 for a smaller inbox though. I have all my email since 90s in there and it all still fits just fine.

If I read their pricing page correctly, you have to be on the $50 plan to use your own domain name.

Re: JMAP: Like IMAP but Not Really

#235
post #2

I was really hoping for a GraphQL API standard for mail before reading this. But this sounds good too.

Understand that JMAP is an object synchronisation protocol. It’s most interested in the problems that are out of scope for GraphQL.

You could have a variant of JMAP with GraphQL syntax and semantics, but there would be a fair bit of mismatch, for their purposes and focuses are quite different: JMAP is concerned with object identity and synchronisation, for what you might call thick clients (and JMAP Mail needs to be broadly IMAP compatible), while GraphQL is UI-focused, for what might reasonably be considered to be thin clients (not that they are logicless, but that they are very much focused on offloading burden to the server). I see no compelling case for a JMAP-like GraphQL thing.

It could still be an interesting task to develop a object synchronisation protocol like the JMAP core on top of GraphQL.

Post reply on HN