> You're comparing developing mail software using libraries for JSON, HTTPS and other pieces, versus doing the same thing while developing IMAP from scratch.
This is nonsense. Most of my comment was describing protocol-level advantages of JMAP over IMAP: things that you can’t get with IMAP (+ SMTP + CalDAV + CardDAV + …), and things that affect the user experience. I did mention at one point that JMAP is such that you don’t even need any library to achieve useful things with it, whereas you wouldn’t tend to get far without such libraries on SMTP/IMAP, but I wasn’t making that comparison in any other way.
> It's not realistic to develop a new mail client without IMAP (complete non-starter) even if it suports JMAP.
Not true. It depends on who you’re targeting and what you’re trying to achieve. Sure, most will still want to support IMAP/SMTP due to JMAP’s current lack of widespread adoption, but honestly going native JMAP only carries some pretty compelling technical and functional advantages.
> This only benefits people who are trying to be the next Gmail.
I rebutted this fairly clearly in my previous comment. You seem to be fixing on first-party software, where service and software are provided by the same entity, but this is something that JMAP is better about compared to IMAP/SMTP, removing some of the unfair advantage first-party software had and levelling the field for all service providers and domain names, due to autodiscovery that works, and exposing the server in a way that even a web frontend can directly access.
Just because Fastmail is currently the only notable provider shipping JMAP doesn’t mean that JMAP is about Fastmail. There’s a fair bit of interest from other providers, it just takes time. Also I would point out that Fastmail has not the slightest ambition of being “the next Gmail”; their business model, history and market positioning should make that very clear.
> I'm logged into my self-hosted RoundCube webmail which is accessing my inbox with IMAP, and sends with SMTP. Of course, it does those things at the PHP back end.
That RoundCube requires a backend, and its frontend has to talk something other than IMAP and SMTP, is a problem. Until JMAP, every single webmail client has done its own thing for a client–server protocol, and they’ve almost all been terrible, and so you’ve kinda had to learn two things to develop it, and you’ll have functional limitations all over the place that make developing the frontend hard. By contrast, with JMAP, a webmail frontend and a desktop app are talking the same protocol. That’s very valuable.
I did go a little too hard on this in that a backend can allow you to connect to arbitrary mail sources (though in practice webmail is almost always first-party, service and software coming from the same provider), but that fact that you need that extra backend is still a problem, for performance and for privacy: your software vendor shouldn’t need to be able to access all your mail; it’s much better if the software can talk directly to the service provider.
> If such a thing is not able to speak SMTP or IMAP, maybe the Javscript world should tool up?
It’s not possible due to the web’s security model; it’d be a fiasco if browsers let JS initiate arbitrary TCP connections—far too much software assumes that only trusted software can talk on the local network. From time to time there are ideas about relaxing this limitation by server opt-in (along the lines of CORS preflight requests), but they’ve never gone anywhere yet and I don’t think they will any time soon, and certainly it will never be fully relaxed.
Your definition of email is transparently unreasonable, if you insist it can only refer to what IMAP and SMTP provide. When do you freeze IMAP? Version 1, 2, 4, 4rev1, other? Are SPF, DKIM, DMARC part of “email”?
I said you seemed to be fixing on first-party software because a lot of your arguments about centralisation of power and such and assumed motives of companies pushing JMAP only make sense in that light. I’ll say it once more: by its design, JMAP distributes the power, supporting usable decentralisation better than IMAP/SMTP/CalDAV/CardDAV/&c. Adoption is limited yet, but that doesn’t change this fact.
As for Gmail: you’ll get a second-rate experience if you don’t use a Google client or Google-specific APIs. Dodgy IMAP (partly understandable—when they started, IMAP didn’t support the concept of labels and so they had to make some kind of workaround—but IMAP has very obviously been a second-class citizen through all Gmail’s history). No notifications unless you hold an IMAP connection open (which you can’t on mobile platforms). The necessity of Gmail-specific authentication (or else some users won’t be able to use it at all, and the rest must jump through increasingly-scarified hoops). That’s what Google is pushing. Gmail’s dominance has absolutely involved locking people to first-party clients, and IMAP/SMTP support is a concession. JMAP is nothing like all of that.
This is nonsense. Most of my comment was describing protocol-level advantages of JMAP over IMAP: things that you can’t get with IMAP (+ SMTP + CalDAV + CardDAV + …), and things that affect the user experience. I did mention at one point that JMAP is such that you don’t even need any library to achieve useful things with it, whereas you wouldn’t tend to get far without such libraries on SMTP/IMAP, but I wasn’t making that comparison in any other way.
> It's not realistic to develop a new mail client without IMAP (complete non-starter) even if it suports JMAP.
Not true. It depends on who you’re targeting and what you’re trying to achieve. Sure, most will still want to support IMAP/SMTP due to JMAP’s current lack of widespread adoption, but honestly going native JMAP only carries some pretty compelling technical and functional advantages.
> This only benefits people who are trying to be the next Gmail.
I rebutted this fairly clearly in my previous comment. You seem to be fixing on first-party software, where service and software are provided by the same entity, but this is something that JMAP is better about compared to IMAP/SMTP, removing some of the unfair advantage first-party software had and levelling the field for all service providers and domain names, due to autodiscovery that works, and exposing the server in a way that even a web frontend can directly access.
Just because Fastmail is currently the only notable provider shipping JMAP doesn’t mean that JMAP is about Fastmail. There’s a fair bit of interest from other providers, it just takes time. Also I would point out that Fastmail has not the slightest ambition of being “the next Gmail”; their business model, history and market positioning should make that very clear.
> I'm logged into my self-hosted RoundCube webmail which is accessing my inbox with IMAP, and sends with SMTP. Of course, it does those things at the PHP back end.
That RoundCube requires a backend, and its frontend has to talk something other than IMAP and SMTP, is a problem. Until JMAP, every single webmail client has done its own thing for a client–server protocol, and they’ve almost all been terrible, and so you’ve kinda had to learn two things to develop it, and you’ll have functional limitations all over the place that make developing the frontend hard. By contrast, with JMAP, a webmail frontend and a desktop app are talking the same protocol. That’s very valuable.
I did go a little too hard on this in that a backend can allow you to connect to arbitrary mail sources (though in practice webmail is almost always first-party, service and software coming from the same provider), but that fact that you need that extra backend is still a problem, for performance and for privacy: your software vendor shouldn’t need to be able to access all your mail; it’s much better if the software can talk directly to the service provider.
> If such a thing is not able to speak SMTP or IMAP, maybe the Javscript world should tool up?
It’s not possible due to the web’s security model; it’d be a fiasco if browsers let JS initiate arbitrary TCP connections—far too much software assumes that only trusted software can talk on the local network. From time to time there are ideas about relaxing this limitation by server opt-in (along the lines of CORS preflight requests), but they’ve never gone anywhere yet and I don’t think they will any time soon, and certainly it will never be fully relaxed.