4 ms·

JMAP is a rather misleading name. "J" is misleading because it's not JSON that distinguishes JMAP from IMAP, but rather the use of HTTP, along with recently ad

by kijin 12y ago

JMAP is a rather misleading name. "J" is misleading because it's not JSON that distinguishes JMAP from IMAP, but rather the use of HTTP, along with recently added HTTP features such as push. JSON is just the message packing scheme. HTTP is what does all the heavy lifting. "M" is misleading because this protocol is designed for a lot more than mail. It also handles contacts and calendars, and I wouldn't be surprised if Fastmail made their file storage service accessible through JMAP as well. What's even worse is that once you come up with a protocol that covers everything that Fastmail does, everyone and their dog will try to add more services to the protocol. Instant messaging? Got it. Collaborative editing a la Google Drive? No problem. And before you know it, the protocol is bloated as hell and you've basically reinvented HTTP. Please don't try to do everything. Do one thing, do it well, and put a strict limit to the scope of the project for the time being. A few more minutes of battery life on a phone is not worth polluting the world with yet another example of massive scope creep. IMAP+SMTP using a stateless protocol would be cool, but anything more and I'm not sure.

quink 12y ago
First thing I thought: It's one better than IMAP and meant to replace it. I++ == J. JMAP.
- gboss 12y ago
  You mean ++I == J
toyg 12y ago
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.
- mdadm 12y ago
  I thought that it'd be lowercase "j" that signifies Java, not a capital "J"...
robn_fastmail 12y ago
> "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?
brongondwana 12y ago
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.
SwellJoe 12y ago
"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.

by kijin 12y ago

quink 12y ago

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

gboss 12y ago
You mean ++I == J

toyg 12y ago

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.

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

robn_fastmail 12y ago

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

brongondwana 12y ago

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.

SwellJoe 12y ago

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