Previous discussions of JMAP:

* https://news.ycombinator.com/item?id=7141152

* https://news.ycombinator.com/item?id=8785894

* https://news.ycombinator.com/item?id=10781894

* https://news.ycombinator.com/item?id=14283659

Thank you! The first link goes to jmap.io and the other three go to blog posts at fastmail.com that are 1+ years old.

I tried finding more info on JMAP from fastmail by searching for "jmap site:blog.fastmail.com" (https://www.google.com/?gws_rd=ssl#q=jmap+site:blog.fastmail...) but they haven't written anything relatively new unfortunately.

By searching for "jmap site:edu" in Google, I found: https://cyrusimap.org/

Cyrus IMAP supports JMAP but I am unable to find any JMAP clients that are being used in production.

There is currently a standardisation effort at https://datatracker.ietf.org/wg/jmap/about/

I can't believe I am saying this about something like an email protocol that would normally be quite mundane, but there is some real elegance to the simplicity of their approach by reusing what already exists (HTTP, JSON, mobile OS push notifications). It all seems unbelievably rational, especially for an email protocol standard.

Then you probably would have liked Internet Mail 2000 (IM2000), a half-hearted djb proposal: https://cr.yp.to/im2000.html

(I say half-hearted because when djb is enthused, the first people hear of it is a complete first draft of a server and a client...)

IM2000 would have been great for spam! The spammer can just blast out little message availability notifications, containing links to their bulletproof hosting or compromised servers.

While we at Nylas did build our APIs to help with IMAP troubles, we also handle Gmail (via IMAP) and Exchange as well. We'd be happy to add JMAP support to our APIs if it takes off since we're committed to 100% coverage of email mailbox accounts (including calendar via CalDav parsing).

(If the Fastmail people are reading this, feel free to contact me.)

I used Nylas a little while ago, loved the N1 client. But had to stop due to restrictions on emails being stored off site. Is there an option for people wanting to use Nylas where they have restrictive security policies on where email can be stored?

tl;dr their new mail standard is a web app.

"Why use HTTPS/JSON? The short answer is it’s good enough, widely understood and it’s by far the easiest thing for developers to adopt. There’s support in basically all OSes and programming languages. It’s easy to read and debug."

Why not INI files, then, or a CSV, delivered over DNS? "Wide support and rapid adoption" is great if you're trying to make money, but not necessarily a great technical design framework.

The reason webapps work with HTTP/JSON is they had to. They were built on top of old standards which had to be backwards compatible, and they had to work around holes in the existing technology. So they took existing tech and extended it, and made it simple enough for everyone to adopt it warts and all, rather than improve it. We've been slowly patching its gross inefficiencies ever since.

An IMAP replacement does not have to work over a web platform, so it does not need this kind of unnecessary coupling of disparate, complicated standards to make it more clunky. But they're doing it anyway. So, why build a complicated new protocol on top of difficult, completely unrelated standards?

This new standard only exists as a vehicle for their own services and products, because they need other people to adopt it for it to make sense as a product they can make money on vs their competitors. They could have just worked with the industry on the next generation of IMAP, but that wouldn't be adopted "as quickly" to lock an industry into the model they are already developing.

HTTPS/JSON is common place, developers are familiar with debugging problems in that stack. INI or CSV delivered over DNS would be esoteric an unknown to most developers.

You might see it as more clunky but I think it's great that the transport and security layer are bundled into something I already work with and know how to debug. I don't think the extra overhead is a concern these days. Most servers can handle that sort of load easily and most clients have not issue with HTTPS/JSON.

It seems like you feel very strongly about this. What is this industry-wide, next-generation IMAP replacement project you refer to?

> It’s based on years of experience and real-world experimentation at FastMail

Here's a nice blog post about that: https://blog.fastmail.com/2014/12/23/jmap-a-better-way-to-em...

I know that it's open source, and open, interoperable protocols are a good thing.

But. I don't think IMAP is the real competition here. This is, for most people, a solved problem, and a problem that's been solved by exchange and gmail.

So for better or worse, showing you're better than IMAP doesn't cut it. You have to show you're better than exchange.

One of the things I don't understand is why email protocols were allowed to languish for so long, making proprietary groupware suites practically mandatory for getting work done.

I think you're last statement, in a way, answers your second to last.

> You have to show you're better than exchange.

> making proprietary groupware suites practically mandatory for getting work done.

It's not proprietary groupware is why it's better than exchange. I'd argue that if you can get the same work done, you're winning.

> It's not proprietary groupware is why it's better

you must not work enterprise much

Seems like this is missing an RFC to make any real traction.

You don't need RFC to get real traction, if clients/servers are written for it. There is already an implementation in Cyrus SASL, and last I heard work was ongoing for a dovecot impl.

I'm currently poking around the protocol, and thinking of implementing it into K9-mail (A popular android email client, that happens to be open source). I'm self-hosting my email already, and I'd really love to use this. It seems to fit much nicer into the current ecosystem than IMAP.

I'm using k9 with fastmail. I'd definitely use JMAP if it were an option.

About that...

https://datatracker.ietf.org/wg/jmap/charter/

I hope someone will roll out a good (and preferably open) implementation for Android and/or iOS. Email without a mobile client is a non-starter.

Open-source servers apparently exist (listed on the site).