JMAP sounded promising several years ago, and it was great to hear it published as a standard. But it seems like it’ll just remain as what Fastmail (the email provider) uses. Maybe the JMAP team is very small and can’t get more people. Maybe Fastmail doesn’t have enough money and/or enough interest to make it easier to use and to evangelize it with major email providers and email client developers.

I don’t see Outlook365 or Gmail (or even Apple for its iCloud email that has a relatively smaller user base) announcing any implementations of JMAP on their services. I don’t see smaller paid email service providers announce support for it. As it stands now, I don’t see a future for JMAP outside of Fastmail.

A popular client like Mozilla Thunderbird still hasn’t started implementing JMAP [1] and one of the reasons is because…the client and server documentation for JMAP haven’t been updated for a few years. [2]

So yeah, JMAP is like IMAP, but not really. We probably need a successor to JMAP that is liked enough to be implemented by email service providers and by email clients.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1322991

[2]: https://github.com/jmapio/jmap/issues/323

Is it too late for any significant improvements to email? It seems like, to our lament, we're headed in the direction of proprietary instant chat services and protocols.

Also, you can't overlook that a significant number of people use Gmail/Google Apps and Outlook.com/Office 365 which each use a proprietary communication protocol that is unlikely to change in the future.

So, it does make me wonder, who does JMAP benefit?

See here for a list of software supporting JMAP: https://jmap.io/software.html

Whoa I love SMTP and email, as a distributed systems nerd I'm a huge fan of the federated protocol and it's simplicity but JMAP I'm sorry is garbage. The http/json part is great, the potential to simplify email access and use is great, even using DNS SRV records is a potential good use of DNS and a compliment to MX records. But the actual JMAP protocol is horrible. This is something built incrementally for fastmail, it's not how you design a protocol. We need to go back to square one and redesign and access and communication protocol as one thing that's ultra simplistic as a building block and starts with very basic primitives. JMAP combines too many things while being very ad-hoc and custom not taking into account a lot of progress made in things like gRPC protos, etc. Tempted to build it from scratch just to prove a point.

So, it isn't just IMAP but for electrical engineers? (/s)

On a related note: the author links to his open source web mail platform Cypht. It looks cool and sounds promising. Anyone tried it? I can't remember if it has been on HN. The git history of the project is very active.

JMAP sounds like a crutch for mobile devices that can't keep a TCP connection open. The internet is slowly being gimped to support mobile devices.

I would go further and also replace SMTP with the same for clients. As I understand we still need SMTP to pass mail between servers but a client already having access to IMAP/JMAP/whatever could just put the mail into the outbox folder for the server to deliver it.

There are 3 different kinds of email services that only have limited interoperability:

* Corporate email services, aka Outlook/Exchange

* Surveillance email services, aka Gmail, etc

* Real email services that expose the raw email database, such as Maildir, to the users.

For the first 2 kinds, I'd rather POP and keep my interaction with them to the minimum. For the last kind, IMAP/JMAP is too limiting in capability.

hrm, handful of new github stars in one day? That's odd. Must have gotten picked up by something. Oh, HN repost of a blog post I wrote 3 years ago, cool!

To sum up my thoughts about this thread:

Appreciate the great discussion! Wherever you land on the validity of JMAP, as a long (long) time IMAP client developer I stand by my position that JMAP is a huge improvement over legacy IMAP. Not perfect, but walks a reasonable line between what IMAP client devs understand and the modern world of APIs 30 years later. Is it REST compliant or a SOAP derivative? Most likely no and yes. Does it only benefit client developers? Probably, but that is a big benefit to the E-mail ecosystem. IMO the biggest barrier to new and innovative E-mail clients is the obtuseness of the protocol itself, and JMAP goes a long way to bridge that gap.

The article explains the technical advantages of JMAP, but I'm not clear how (if at all) it benefits email users. Without clear end-user advantages its hard to see why email providers would want to implement it when they already support just-good-enough IMAP.

> Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. A method is an action or query you want to perform like “give me the 20 newest messages in this mailbox”

Can the HTTP spec just add a CALL verb already?

undefined

JMAP is nice if you sell self-hosting data mining software. One less connector to write.

Does JMAP do anything about the fact that it takes on average multiple whole number seconds, with frequent spikes into 10s of seconds, for email delivered to show up in people's inboxes? Source: https://status.postmarkapp.com/

If not, is anyone doing anything to improve this situation?

Sending packets over the internet across the farthest ends of the earth takes about 300ms roundtrip. What's preventing email from approaching this?

Latency is the biggest UX issue facing email IMHO, and a huge part of why it is continuing to lose ground vs alternative messaging systems, most of which are proprietary, but offer sub-second latency delivery. The world will become a worse place if the trend continues to its logical conclusion and proprietary silos eventually fully supplants email's remaining use cases.

The high average latency and even higher variance leads to people second guessing if an email they sent will ever arrive, and if an email they're expecting has ever been sent, resulting in crude workarounds like resend buttons becoming commonplace and seen as necessary, perpetuating the uncertainty around deliverability, and even further eroding trust in the system.

But most importantly, the latency problem makes email unsuitable for the most compelling use case for messaging platforms: real-time conversation.

Holding a spontaneous real-time conversation over email is painful, as anyone who has tried can probably attest. Both sides are constantly left wondering if the other side is simply taking their sweet time to reply, or if the email is just taking even longer than email usually takes to get delivered. Conversations that could have taken mere seconds end up taking minutes as a result.

This is why email has been consistently losing to messaging apps for fun conversations between friends where email's latency would suck much of the fun out of them, to Slack for mission critical work conversations where wasting time means literally wasting money, to live chat widgets for businesses looking to provide a customer support experience that delights, whereas conversations over email frequently tends to frustrate, the list goes on...

Solving the latency problem for email I believe is the key to slowing and possibly reversing the trend of email's slow but steady decline, and society will benefit massively from the continued prosperity of this rare miracle of an open system that managed to survive for so long despite all its shortcomings.

Now, to build a better IMAP on top of UMAP.

I want hashes for email and not just UIDs. Does any protocol do this currently where it hashes the entire message?

2019.

undefined

undefined

  Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”.

Yeah, what can't be fixed by shoveling JSON shit into HTTP instead of a dedicated protocol?

JMAP was stupid when the Fastmail CEO or whoever was here pushing it, and it's still stupid.