6 ms·

Hi! I really like the initiative of JMAP, however I haven't been able to look into it properly - I can give you a better answer once I've done that, my email is

Hi! I really like the initiative of JMAP, however I haven't been able to look into it properly - I can give you a better answer once I've done that, my email is in my profile

chrismorgan 8y ago
One of the things we’re really hoping with JMAP is that, by drastically lowering the barrier of entry (because doing IMAP/POP3/SMTP well is hard), people will be able to experiment much more, making things like Ivelope, because they can start making UI almost immediately rather than shaving IMAP yaks first. I have a talk planned entitled “building a fair dinkum email client in half an hour with JMAP”—because you genuinely can make a basic but useful email client that quickly! (I’m planning to submit it for Strange Loop. Any know of other conferences that would like such content?) JMAP’s support for both labels and folders may be helpful for Ivelope too. I love seeing a new approach to an email UI, based on the same old email that still works. Thanks for making it!
- mike-cardwell 8y ago
  I'm not convinced that JMAP existing will make it easier for people to develop things like Ivelope. I don't know in this particular case, but if I were writing Ivelope I wouldn't first write an IMAP library of my own. I'd use an existing one. And all commonly used languages have pre-existing IMAP libraries anyway. I doubt the ability to do "var client = new JMAP()" instead of "var client = new IMAP()" will lead to a flood of new clients.
  - chrismorgan 8y ago
    I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least. IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone”; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow, difficult, or impossible to do in IMAP that JMAP can express elegantly. http://jmap.io/#why-is-jmap-better-than-imap http://jmap.io/#why-is-jmap-better-than-imap lists a few reasons. Bugs in clients or servers that cause data loss over IMAP are not unheard of. IMAP is also only one part of the app: one of the hardest parts is MIME, and figuring out what to show for an email and how to craft an email; there are fewer libraries to do this than there are IMAP clients—and almost none that are any good. (You’ll find some that do the plain parsing of most of the message, but how do I decide what to do with multipart/alternative, multipart/mixed, text/plain, Content-Disposition, Content-Encoding, &c. is answered by no library that I know of.) JMAP doesn’t solve all these problems, but it handles most of them by handing you a sanely parsed message (putting the burden of sanity on the server, and the spec provides good guidance and there’s a JMAP test suite being made to ensure the sanity of the server): things like exposing To, Cc, &c. as lists of addresses; and fields like preview, htmlBody, textBody and attachedFiles to save you the trouble of deriving the crazy convoluted rules of multipart messages. You can send messages without having to implement SMTP and grok MIME, too. For authors of existing MUAs, JMAP doesn’t have much to offer by this stuff from the last paragraph—they’ve already done the hard slog. But for authors of new MUAs and other programs that might want to do email at all—sending or receiving—JMAP really is “all that”. Some of the experiments that I’m looking forward to seeing won’t look like existing MUAs at all. They’ll be other things altogether that just happen be able to send or receive emails directly, now, because it’s finally easy enough to. IMAP is not particularly well suited to being used as a purely-online client with no local storage or persistent cache. You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. We couldn’t make something like the FastMail web UI speaking IMAP; it just wouldn’t work in too many places. JMAP, on the other hand, is designed to work in such a situation, and suffers from few of those sorts of shortcomings. Sure, you’ll probably want to introduce offline support and may want to reimplement search on the client somewhere down the track, but it’s not necessary-work-that-must-be-done-before-the-client-is-generally-useful like it is in IMAP. JMAP allows you to get started quickly and efficiently. Because it speaks HTTP and JSON and is deliberately designed as a synchronisation protocol, and because it lacks the cruft of decades of fragmented extension that IMAP has¹, JMAP is really easy to work with. Even things like synchronisation and notifications come at very low cost even without a library, especially if you are running in a web browser. Don’t forget that JMAP replaces IMAP and SMTP for the MUA. And having only one thing to configure and get right, with a standard configuration procedure (SRV and .well-known, so that you can just provide an email address and it’ll figure out the rest) instead of two with no consistently applied configuration procedure is a surprisingly big deal for users. The talk that I plan will be predominantly live coding, starting from scratch—no frameworks at all—and building a basic but functional MUA in half an hour. You really can’t do that in IMAP/SMTP, but you can in JMAP², and it genuinely gets better beyond there. I have no interest in making a realistic MUA with IMAP/SMTP, because I know that I would spend weeks on the groundwork, to produce a result that is strictly inferior to what I am confident I can produce in an hour with only a general understanding of the JMAP spec, and access to the JMAP core and mail spec docs. Oh yeah, I just remembered another absolutely massive thing about JMAP, though the dust has not yet fully settled—calendars and contacts. Because this IMAP/SMTP MUA estimate of mine just went up by a couple of months to handle them for some ESPs, whereas with JMAP that groundwork will take maybe another whole hour. Seriously, JMAP is a big deal. --- ¹ For now, and it has a more thoughtful design to future extension so that it will avoid some of the troubles of aging. ² I’m delicately ignoring the matter of authentication here, which is omitted from the JMAP spec, and assuming something really basic.
    - tonyarkles 8y ago
      Last time I was working on a MUA (which was admittedly a long time ago), within about 3 days I ended up submitting a patch upstream for Ruby's Net::IMAP. It's a fiddly protocol, and there's a lot of ways to get things wrong. I, too, am quite excited about JMAP, although I have my doubts about ever trying to write an MUA ever again.
    - saurik 8y ago
      (Yes: I have personally implemented IMAP, and SMTP, and in fact even Seieve, all from scratch. No: I did not find writing a fully compliant parser difficult, and I have no sympathy for people who seem incapable of writing one.) > You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. By "folders", I will assume you mean "mailboxes" (as that is how most, if not all, existing clients and servers choose to represent "folders"). This was addressed in RFC 7377. I realize that you will argue "but what servers actually implemented that?", but the answer is "probably more than have decided to implement JMAP". That said, JMAP has chosen to unify labels and folders into a term "mailboxes". The same solution applies to IMAP: I think a more correct usage of IMAP is to unify labels and folders into what IMAP calls "flags" (as opposed to what IMAP calls "mailboxes") at which point I think you will find that 90% of the struggles people have with IMAP disappear. I realize that no IMAP server does this, but that is for historical reasons related to how mail was stored on disk and I think totally ignores what makes IMAP as a protocol interesting. I honestly feel like a lot of people just never took the time to understand either IMAP (or Mark Crispin) (or how to quickly write a parser :/) and then spent decades complaining about the annoying and limited ways people mapped semantics. That all said, I would at least begrudgingly agree that for some simple use cases, JMAP is likely convenient for certain classes of mail consuming systems. But come on... to try to claim that IMAP is somehow not designed for online usage or is somehow broken for that usage is such a totally disingenuous claim that I will go so far as to say that it outright slanders the memory of Mark Crispin, who seriously seemed to believe people writing offline email clients with persistent caches that required synchronization were embarking on a "fools errand", and (for better or for worse) effectively assumed servers would always be better than local hardware.
    - mike-cardwell 8y ago
- ryan-c 8y ago
  It looks like JMAP is on top of HTTP - does this mean a normal browser could speak it directly? How is new mail notification handled? Polling?
  - chrismorgan 8y ago
    Push subscription and EventSource: http://jmap.io/spec-core.html#push http://jmap.io/spec-core.html#push The FastMail web UI will soon (later this year, we plan) be speaking JMAP. What it speaks at present is a precursor to JMAP.
brongondwana 8y ago
Thanks for that - I'll pop you an email. I'll be in Munich in June for M3AAWG and then popping over to Paris to meet the Linagora team and chat with them about their JMAP work - don't think I can come up with an excuse to visit Sweden this trip sadly :( My next trip after that is Montreal in July for IETF102. Hopefully we'll be finalising core and mail specs at that conference, hence the interest in getting feedback now! Easier to fix spec issues before publishing. I've done a bunch of implementation on two different servers, so I'm comfortable with that half, but we only really have one client implementation in-house (hence wanting to chat to Linagora about theirs!)

Hi! I really like the initiative of JMAP, however I haven't been able to look into it properly - I can give you a better answer once I've done that, my email is in my profile

chrismorgan 8y ago

One of the things we’re really hoping with JMAP is that, by drastically lowering the barrier of entry (because doing IMAP/POP3/SMTP well is hard), people will be able to experiment much more, making things like Ivelope, because they can start making UI almost immediately rather than shaving IMAP yaks first. I have a talk planned entitled “building a fair dinkum email client in half an hour with JMAP”—because you genuinely can make a basic but useful email client that quickly! (I’m planning to submit it for Strange Loop. Any know of other conferences that would like such content?) JMAP’s support for both labels and folders may be helpful for Ivelope too. I love seeing a new approach to an email UI, based on the same old email that still works. Thanks for making it!

mike-cardwell 8y ago
I'm not convinced that JMAP existing will make it easier for people to develop things like Ivelope. I don't know in this particular case, but if I were writing Ivelope I wouldn't first write an IMAP library of my own. I'd use an existing one. And all commonly used languages have pre-existing IMAP libraries anyway. I doubt the ability to do "var client = new JMAP()" instead of "var client = new IMAP()" will lead to a flood of new clients.
- chrismorgan 8y ago
  I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least. IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone”; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow, difficult, or impossible to do in IMAP that JMAP can express elegantly. http://jmap.io/#why-is-jmap-better-than-imap http://jmap.io/#why-is-jmap-better-than-imap lists a few reasons. Bugs in clients or servers that cause data loss over IMAP are not unheard of. IMAP is also only one part of the app: one of the hardest parts is MIME, and figuring out what to show for an email and how to craft an email; there are fewer libraries to do this than there are IMAP clients—and almost none that are any good. (You’ll find some that do the plain parsing of most of the message, but how do I decide what to do with multipart/alternative, multipart/mixed, text/plain, Content-Disposition, Content-Encoding, &c. is answered by no library that I know of.) JMAP doesn’t solve all these problems, but it handles most of them by handing you a sanely parsed message (putting the burden of sanity on the server, and the spec provides good guidance and there’s a JMAP test suite being made to ensure the sanity of the server): things like exposing To, Cc, &c. as lists of addresses; and fields like preview, htmlBody, textBody and attachedFiles to save you the trouble of deriving the crazy convoluted rules of multipart messages. You can send messages without having to implement SMTP and grok MIME, too. For authors of existing MUAs, JMAP doesn’t have much to offer by this stuff from the last paragraph—they’ve already done the hard slog. But for authors of new MUAs and other programs that might want to do email at all—sending or receiving—JMAP really is “all that”. Some of the experiments that I’m looking forward to seeing won’t look like existing MUAs at all. They’ll be other things altogether that just happen be able to send or receive emails directly, now, because it’s finally easy enough to. IMAP is not particularly well suited to being used as a purely-online client with no local storage or persistent cache. You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. We couldn’t make something like the FastMail web UI speaking IMAP; it just wouldn’t work in too many places. JMAP, on the other hand, is designed to work in such a situation, and suffers from few of those sorts of shortcomings. Sure, you’ll probably want to introduce offline support and may want to reimplement search on the client somewhere down the track, but it’s not necessary-work-that-must-be-done-before-the-client-is-generally-useful like it is in IMAP. JMAP allows you to get started quickly and efficiently. Because it speaks HTTP and JSON and is deliberately designed as a synchronisation protocol, and because it lacks the cruft of decades of fragmented extension that IMAP has¹, JMAP is really easy to work with. Even things like synchronisation and notifications come at very low cost even without a library, especially if you are running in a web browser. Don’t forget that JMAP replaces IMAP and SMTP for the MUA. And having only one thing to configure and get right, with a standard configuration procedure (SRV and .well-known, so that you can just provide an email address and it’ll figure out the rest) instead of two with no consistently applied configuration procedure is a surprisingly big deal for users. The talk that I plan will be predominantly live coding, starting from scratch—no frameworks at all—and building a basic but functional MUA in half an hour. You really can’t do that in IMAP/SMTP, but you can in JMAP², and it genuinely gets better beyond there. I have no interest in making a realistic MUA with IMAP/SMTP, because I know that I would spend weeks on the groundwork, to produce a result that is strictly inferior to what I am confident I can produce in an hour with only a general understanding of the JMAP spec, and access to the JMAP core and mail spec docs. Oh yeah, I just remembered another absolutely massive thing about JMAP, though the dust has not yet fully settled—calendars and contacts. Because this IMAP/SMTP MUA estimate of mine just went up by a couple of months to handle them for some ESPs, whereas with JMAP that groundwork will take maybe another whole hour. Seriously, JMAP is a big deal. --- ¹ For now, and it has a more thoughtful design to future extension so that it will avoid some of the troubles of aging. ² I’m delicately ignoring the matter of authentication here, which is omitted from the JMAP spec, and assuming something really basic.
  - tonyarkles 8y ago
    Last time I was working on a MUA (which was admittedly a long time ago), within about 3 days I ended up submitting a patch upstream for Ruby's Net::IMAP. It's a fiddly protocol, and there's a lot of ways to get things wrong. I, too, am quite excited about JMAP, although I have my doubts about ever trying to write an MUA ever again.
  - saurik 8y ago
    (Yes: I have personally implemented IMAP, and SMTP, and in fact even Seieve, all from scratch. No: I did not find writing a fully compliant parser difficult, and I have no sympathy for people who seem incapable of writing one.) > You can do it, and many clients have over the years, but you will sacrifice a lot, like the ability to search multiple folders efficiently. By "folders", I will assume you mean "mailboxes" (as that is how most, if not all, existing clients and servers choose to represent "folders"). This was addressed in RFC 7377. I realize that you will argue "but what servers actually implemented that?", but the answer is "probably more than have decided to implement JMAP". That said, JMAP has chosen to unify labels and folders into a term "mailboxes". The same solution applies to IMAP: I think a more correct usage of IMAP is to unify labels and folders into what IMAP calls "flags" (as opposed to what IMAP calls "mailboxes") at which point I think you will find that 90% of the struggles people have with IMAP disappear. I realize that no IMAP server does this, but that is for historical reasons related to how mail was stored on disk and I think totally ignores what makes IMAP as a protocol interesting. I honestly feel like a lot of people just never took the time to understand either IMAP (or Mark Crispin) (or how to quickly write a parser :/) and then spent decades complaining about the annoying and limited ways people mapped semantics. That all said, I would at least begrudgingly agree that for some simple use cases, JMAP is likely convenient for certain classes of mail consuming systems. But come on... to try to claim that IMAP is somehow not designed for online usage or is somehow broken for that usage is such a totally disingenuous claim that I will go so far as to say that it outright slanders the memory of Mark Crispin, who seriously seemed to believe people writing offline email clients with persistent caches that required synchronization were embarking on a "fools errand", and (for better or for worse) effectively assumed servers would always be better than local hardware.
  - mike-cardwell 8y ago
ryan-c 8y ago
It looks like JMAP is on top of HTTP - does this mean a normal browser could speak it directly? How is new mail notification handled? Polling?
- chrismorgan 8y ago
  Push subscription and EventSource: http://jmap.io/spec-core.html#push http://jmap.io/spec-core.html#push The FastMail web UI will soon (later this year, we plan) be speaking JMAP. What it speaks at present is a precursor to JMAP.

brongondwana 8y ago

Thanks for that - I'll pop you an email. I'll be in Munich in June for M3AAWG and then popping over to Paris to meet the Linagora team and chat with them about their JMAP work - don't think I can come up with an excuse to visit Sweden this trip sadly :( My next trip after that is Montreal in July for IETF102. Hopefully we'll be finalising core and mail specs at that conference, hence the interest in getting feedback now! Easier to fix spec issues before publishing. I've done a bunch of implementation on two different servers, so I'm comfortable with that half, but we only really have one client implementation in-house (hence wanting to chat to Linagora about theirs!)