3 ms·

First they need to get massive email providers to offer JMAP support, and then get clients to support it. Surely this is simply too big a ship to steer. Google

by awill 3y ago

First they need to get massive email providers to offer JMAP support, and then get clients to support it. Surely this is simply too big a ship to steer. Google is not going to support this, and isn't that >50% of the market?

solarkraft 3y ago
They just need an IMAP/SMTP <-> JMAP bridge. This allows (small) providers to add support without much effort and there's suddenly a demand for clients (and vice versa good clients will increase demand for JMAP support). The website lists jmap-proxy (https://github.com/jmapio/jmap-perl https://github.com/jmapio/jmap-perl) Its age, technology choice and lack of documentation aren't exactly confidence inspiring, however. Stalwart (https://github.com/stalwartlabs/imap-server/ https://github.com/stalwartlabs/imap-server/) seems to include a proxy feature (for both, though it's non-obvious to discover) and be better maintained. A functioning proxy is make or break for me. If it works I can jump right into making a client, if it doesn't there's no point.
- mildred593 3y ago
  The problem with the proxy is that to be efficient, I believe the proxy will need to store all IMAP messages in an indexed form on the proxy-side. The problem with IMAP is that some requests are not possible efficiently, and the real breakthrough of JMAP is that those requests are now possible and clients are now allowed to be fast. For that though, the server-side JMAP needs to access the indexed mail store directly.
- awill 3y ago
  but a proxy doesn't have any benefit over regular IMAP. It's just a stop-gap.
  - solarkraft 3y ago
    It has all the benefit. I don't want to have to worry about IMAP and that's what it allows me to do - with not only theoretical browser compatibility, but a complete complete client library fully ready.
- chrismorgan 3y ago
  Stalwart is the other way around: Stalwart JMAP Server is an actual JMAP-native server, then Stalwart IMAP Server is an IMAP4-to-JMAP proxy, allowing you to connect with IMAP clients, and converting that into JMAP. What you want is a JMAP-to-IMAP4/SMTP proxy, which is what the jmap-perl proxy is/was (or at least the IMAP4 part). On the matter of technology choice, note that most of Fastmail’s backend is Perl, so it was an obvious choice for such a tech demo being made by Fastmail devs. It wasn’t designed for production use.
  - solarkraft 3y ago
    Oh, that's unfortunate. I had hope for Stalwart, not so much for the Perl proxy. Is there anything else on the horizon? Switching away from my current E-Mail provider isn't a realistic option for me and won't be for almost anyone else. Man, that sucks.
    - chrismorgan 3y ago
      jmap-perl was only ever a tech demo and somewhat incomplete (e.g. it lacks push subscriptions, and a few bits that could theoretically be supported are stubs), but it’s not actually all that much code—even in fairly verbose Perl and including contacts and calendar support, the entire repository is around 11,000 lines of code (naturally depending on libraries for things like HTTP, OAuth, IMAP, SMTP, CalDAV and CardDAV), and could be shorter.

by awill 3y ago

solarkraft 3y ago

They just need an IMAP/SMTP <-> JMAP bridge. This allows (small) providers to add support without much effort and there's suddenly a demand for clients (and vice versa good clients will increase demand for JMAP support). The website lists jmap-proxy (https://github.com/jmapio/jmap-perl https://github.com/jmapio/jmap-perl) Its age, technology choice and lack of documentation aren't exactly confidence inspiring, however. Stalwart (https://github.com/stalwartlabs/imap-server/ https://github.com/stalwartlabs/imap-server/) seems to include a proxy feature (for both, though it's non-obvious to discover) and be better maintained. A functioning proxy is make or break for me. If it works I can jump right into making a client, if it doesn't there's no point.

mildred593 3y ago
The problem with the proxy is that to be efficient, I believe the proxy will need to store all IMAP messages in an indexed form on the proxy-side. The problem with IMAP is that some requests are not possible efficiently, and the real breakthrough of JMAP is that those requests are now possible and clients are now allowed to be fast. For that though, the server-side JMAP needs to access the indexed mail store directly.
awill 3y ago
but a proxy doesn't have any benefit over regular IMAP. It's just a stop-gap.
- solarkraft 3y ago
  It has all the benefit. I don't want to have to worry about IMAP and that's what it allows me to do - with not only theoretical browser compatibility, but a complete complete client library fully ready.
chrismorgan 3y ago
Stalwart is the other way around: Stalwart JMAP Server is an actual JMAP-native server, then Stalwart IMAP Server is an IMAP4-to-JMAP proxy, allowing you to connect with IMAP clients, and converting that into JMAP. What you want is a JMAP-to-IMAP4/SMTP proxy, which is what the jmap-perl proxy is/was (or at least the IMAP4 part). On the matter of technology choice, note that most of Fastmail’s backend is Perl, so it was an obvious choice for such a tech demo being made by Fastmail devs. It wasn’t designed for production use.
- solarkraft 3y ago
  Oh, that's unfortunate. I had hope for Stalwart, not so much for the Perl proxy. Is there anything else on the horizon? Switching away from my current E-Mail provider isn't a realistic option for me and won't be for almost anyone else. Man, that sucks.
  - chrismorgan 3y ago
    jmap-perl was only ever a tech demo and somewhat incomplete (e.g. it lacks push subscriptions, and a few bits that could theoretically be supported are stubs), but it’s not actually all that much code—even in fairly verbose Perl and including contacts and calendar support, the entire repository is around 11,000 lines of code (naturally depending on libraries for things like HTTP, OAuth, IMAP, SMTP, CalDAV and CardDAV), and could be shorter.