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?
Google is not going to support this, and isn't that >50% of the market?
The website lists jmap-proxy (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/) 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.
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.
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.
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.