Hacker News Reader

> "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.

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

You mean ++I == J

It must be a generational thing: for me, anything starting with "J" must have something to do with Java.

... But to be honest, I don't really care. A lot of people don't know what IMAP and POP and SMTP actually stand for -- they don't care, and neither do I.

I thought that it'd be lowercase "j" that signifies Java, not a capital "J"...

"And before you know it, the protocol is bloated as hell and you've basically reinvented HTTP."

I don't think this assertion makes sense. If it's JSON over HTTP (as you've said above), why would they need to reinvent HTTP to achieve any of the stuff they're trying to achieve? They already have all of HTTP to choose from, no need to reinvent it. And, you've made a lot of claims based on some kind of slippery slope argument (which is a fallacy).

I think it would be educational for everyone talking on this subject to spend some time learning a bit about the existing protocols in the space. SMTP is messy, and shows its age in a lot of regards (character encoding complexity, transfer of large data, authentication of sending servers, etc.). IMAP is somewhat less messy and slightly more modern, but still quite old.

Neither protocol is well-tuned for modern email usage. I don't know that JMAP will solve it, but given how much effort is going into web tools, both on the server and client side, and how many more people have experience developing with HTTP, I don't see any reason to not leverage that for email, too.