Also, you can't overlook that a significant number of people use Gmail/Google Apps and Outlook.com/Office 365 which each use a proprietary communication protocol that is unlikely to change in the future.
So, it does make me wonder, who does JMAP benefit?
JMAP benefits FastMail (and others). The CEO of FastMail is also a heavy-lifter in standardizing JMAP, Bron Gondwana. It's probably appropriate to mention he's also a lead developer of the Cyrus IMAP free-software project, so it's hard to accuse him of making a private moat for his company.
Self-hosters, and small businesses, who can run software, and possibly contribute, but not write their own email software from scratch—-benefit.
JMAP is targeting email, and soon calendar, contacts, and maybe more general messaging, to run better suited to current network and user conditions.
https://www.ietf.org/blog/jmap/
Who does TCP benefit, JSON, .well-known?
who does vcf/vCard benefit, or .ics (even if it started as a proprietary format)?
If I made myself the spare time, or had a business model, I would love to implement chat bridges (for personal, self-hosted) small-scale use, using JMAP.
I like, I'm hopeful for the potential of, the promise of, REST-ful state transfer but with multiplexing of requests internal to the protocol.
Think of the protocol as sending a git-patch to modify state, instead of sending a diff per file, "resource".
Analogous to how QUIC (which is still adding standardization features) works around the problem of head of line blocking on TCP connections (and on http2's HTTP sequentially multiplex-able response streams), a core theme supporting in existing JMAP for email & attachments is multiple application requests per web-request, on-the-wire payload.
Said another way, I appreciate the multiplexing in: - per web request, - per application request (JMAP adds multiplexing here) - per resource, accessible to the user, on the server, - you can create, read, update, delete, move, etc.
JMAP core and email standards haven't changed in the past few years because they're done! In the JMAP working group at the IETF we're currently heavily focused on getting the calendaring and contacts bits finished. That unlocks significantly more benefit for a JMAP client because you don't need multiple different authentications.
As for email clients - yeah, it's been slow going, partly because when COVID hit we all shrank back into our shells a bit, and certainly my travel and networking was cut back! It's good to see how it's perceived from outside our little bubble where JMAP is doing great and we're moving more and more of Fastmail's internal APIs to be JMAP-style because it's so easy to multiplex requests together and route them separately through our middleware into different systems, then combine the results back to together in a single response to the calling system or browser.
IMAP development started in the 1980s (RFC 1064), and was run over POTS modems for many decades: I find it hard to believe that it can't handle the 'low-end' of things.
The fact that many clients assume high-end / high-speed links is not a fault of the protocol.
All of those support IMAP currently, an open standard. Exchange has MAPI as well.
Email is the best federated system we might ever have, and it has thousands of clients that can work with nearly any provider.
JMAP has not taken off, but there is a chicken and egg problem. Most clients don't support it so there is no pressure on services to support it. Though I imagine if Gmail supported it then suddenly all the clients would support it
Gmail supports IMAP, with custom extensions to support threading. As far as I understand it they use a custom protocol for their own gmail apps because of IMAP's shortcomings.
Its basically impossible to build a modern email app directly on top of gmail's public APIs. You can do it - but only by mirroring and re-indexing all the email.
Technology and people move quickly so fossilized systems such as email get left behind. There is too much friction to improve a system which has a large number of different implementations. Where any change is hotly debated and people still resist features added to email over a decade ago. Naturally the proprietary systems win when they can roll out a new feature and have it universally work on day one.
Do others believe/experience this?
I ask because this sounds like a very Bay Area comment.
Email is for significant communications.
Outside of work, I'm using daily for things like booking bands, talking to strata, etc.
While email in a lot of large companies might tend to be becoming a one-way distribution system; it is still vibrant and heavily used in smaller enterprises.
And that’s just internally. How do you handle stuff that also requires external contributors?
Across countries everyone uses a different messenger app. For some whatsapp, other LINE, etc. Email is faster to make sure you reach them all.
I don't think many companies operate this way. Any formal things, e.g. regulation, finance, HR, will likely use email much more. And talking to a third party company, which some people will talk to 200 of in a year, will all be email, at least to start with.
Side Note: My wife's work went all in on MS Teams. They held multiple trainings and kept showing how it could handle all the functionality of email. You could schedule appointments and even share file..... Six months later everyone still uses email and MS Teams is barely used at all.... email just works.
From my end it looks like the "no one uses email anymore" is just marketing hype.
The IMAP spec is poor; it's ambiguous and unclear. The only way to build a reliable client is to test interworking against as many IMAP servers as you can find. A better protocol would be a good thing.
The SMTP spec is NOT poor. There's no need to replace SMTP. It works fine.
It's some time since I read an explanation of JMAP (with the article doesn't provide). As far as I'm aware, it provides roughly the same service, but using HTTP and JSON. I'm not a supporter of the "replace everything with JSON" movement; I don't see the point.
I'm not that keen on the "replace everything with HTTP" movement either; if you piggy-back your new protocol on an existing protocol, there's a risk that your new application will start dragging the underlying standard along with it, to the detriment of the original application the underlying protocol was designed for. I.e., it would be regrettable if JMAP resulted in pressure on the HTTP standard to start including features motivated by the requirements of mail retrieval.
No. This doesn't even come close to representing my real-world experience.
What a weird way to call a technologically superior solution.
I think you may have become bubbled.