JMAP – a better way to email

Its expected that you'll run JMAP over HTTPS which takes care of the wire encryption. For end-to-end encryption, there's a heap of problems that still aren't solved (key distribution, need for content analysis). There's no reason JMAP couldn't be extended in the future to support these via additional properties, attached encrypted payloads, etc but mandating it from the outset would quickly see the whole protocol dead before it began.

First thing I thought: It's one better than IMAP and meant to replace it. I++ == J. JMAP.

> "J" is misleading because it's not JSON that distinguishes JMAP from IMAP, but rather the use of HTTP

Not actually true; the protocol does not require HTTP. Any bi-directional stream transport will work just as well.

> "M" is misleading because this protocol is designed for a lot more than mail.

Maybe "Messaging" would have been better. I don't know.

Part of the JMAP name is to make it look like IMAP so its easy to see the relationship. J is after I. And so on.

But lets not quibble about names. Perhaps its not a great name. It doesn't really matter because products get different, better names.

> reinvented HTTP > yet another bloated protocol

This is kind of "citation needed" stuff. I'm not saying JMAP is perfect, in concept or in implementation, but we've have a shipping product running on it for a couple of years. Its got runs on the board already, and we're inviting everyone to pick it apart and make it better.

> IMAP+SMTP using a stateless protocol would be cool

Both IMAP and SMTP are inherently stateful, and that's not the worst of their problems. Why not fix it all properly?

The name is somewhat misleading, but we spent ages and couldn't come up with anything that described it better, was snappy, and wasn't already taken.

By the way, I've spent years on the protocol mailing lists with people who claimed that making it possible to submit email via IMAP was creating a bloated protocol. Support considerations, pah - real world problems don't matter. Meanwhile everyone was moving to ActiveSync so that they could actually get shit done rather than congratulating themselves on the purity of their model.

We definitely do want a model that extends easily (the record update and state-based changes model) to everything that a client wants to do, so that a client can get push updates to the things it cares about in a single way. If this model extends past email, then yay for that. Interestingly, caldav with its sync-token is further along this path than most protocols - it just doesn't have an open push mechanism.

I strongly believe that edge-triggered updates are the right way to do push. Send a small packet with no confidential data through the push channel - it doesn't even need to be encrypted, and it doesn't matter if it comes through multiple times - the client can protect itself by only checking for updates every N seconds if there were any pushes during that time period. The only attack is to block the pushes, but that one can't be avoided by any system - if you can't communicate, you can't communicate.

The actual data updates are pulled through the same secure channel as regular communication. Again, if you can get a secure link, and communicate down it, JMAP works.

In our case we send multiple state strings at FastMail right now (one each for email,contacts,calendar) so the client knows which things to ask for updates on. In theory, just a single token would be enough.

HTTP push features are only used at FastMail in the desktop client. On Android it's using Google's push. On iPhone it's using Apple's push. It's trivial to add new push channels, because they're just an edge trigger.

That presents an interesting problem: can any implementation of a communication protocol enforce a requirement that arbitrary payloads are cyphertext?