Yeah, it’s a shame. IMAP is not a great protocol (to say the least), but jmap is nowhere near critical mass. At present, its not worth the effort to implement for pretty much anyone, so it’s only idealists like Fastmail who’ve done so anyway.

Wasn't JMAP initiated by Fastmail and initially mostly based on their internal implementation.

Initially, the proposition relied on Fastmail protocol, which was/is superior to IMAP. It was pleasing that standardization began, as MS Activesync charged a few dollars per user just for the protocol. Even the Apache James mail server supported it as a draft. Despite becoming a standard make it better , but lost momentum.

Still hope at least both will add push notification to 3th party apps. And a BIG hope for https://stalw.art/

+1 for Stalwart

> its not worth the effort to implement for pretty much anyone, so it’s only idealists like Fastmail who’ve done so anyway.

Worth mentioning that Fastmail use an open source backend: Cyrus[0] - which started adding JMAP support in 2015 (though I suspect that was Fastmail devs contributing the feature).

[0] http://www.cyrusimap.org/

Yeah, but the target of Proton’s efforts with Gluon is the clients, since Gluon is part of the ProtonMail Bridge software.

Their primary targets are Microsoft Outlook, Apple Mail and Thunderbird, none of which speak JMAP at present. So Proton has very little to gain from implementing JMAP, since only niche clients support it at this point.

Classic chicken and egg problem, unfortunately.

Who is actually using JMAP? I never heard of that, what's the point of implementing something that is not used at all.

Mostly Fastmail but there are also a few open-source projects that support it https://jmap.io/software.html

It is used by Fastmail (who was also developers of the standard)

I think it is not a great idea to say that it is not a good idea to not implement things that no one uses, because that is a certain way to not make more people use it.

There are some servers that support it such as Stalwart [0], though I don't know about any older servers and/or clients that support it well.

[0]: https://github.com/stalwartlabs/jmap-server

Until Dovecot and systems like it support JMAP, I don't see it gaining the critical mass it needs to succeed.

Well I can't see Dovecot devs deciding to implement it if they keep reading comments like this dissuading the effort...

What advantage would they gain by implementing it?

There's three considerations

(a) is IMAP good / sufficient / fit for purpose

(b) if not, is there a better alternative available

(c) if there is, is it worth the development effort to support it.

If we assume the answers to (a) & (b) are NO & JMAP, then the benefits are included in those answers & only question remaining is (c). The person I was replying to seemed to be only arguing that the answer to (c) is NO.

(a) No (b) JMAP (c) Long term, probably.

Cyrus is a system like dovecot?

This is an chicken-egg problem.

> what's the point of implementing something that is not used at all

If this question made any sense we would never make anything new at all. How do you think new things get started?

With all this recent attention on HN around imap, smtp, mail servers and the like....i also expected something more modern to be announced - either JMAP or somrthing else altogether. I'm not disappointed because the more, the merrier...but nowadays with so much of my time in the matrix world, i somewhat xpected to start hearing anouncements of alternatives to email.

My prediction is that e-mail will still be around in 10 years, and Matrix will be abandoned, because e-mail is mostly centered around protocols, whereas Matrix is mostly centered around specific libraries and clients (in my opinion). You can already see Matrix crumble under its own complexity, in a few years they will have added so much functionality that it will become impossible for anyone but Element to provide fully-featured client software. IMAP & POP3, by comparison, are so simple and haven't changed in decades, which is why they are so useful.

My hope is that they're both around (& actively developed & used) in 10 years, but yes: email is much less likely to die than Matrix.

I’m not sure you could kill Matrix now even if you wanted to? Heck, given people still run gopher & WAIS & fidonet servers today, so even if everyone runs away from Matrix, it’ll still keep burbling away somewhere :)

Certainly not kill it, I just don't think it will be nearly as ubiquitous as e-mail.

My prediction is that with further advances in networking, devices will be permanently online and asynchronous communication will become less relevant (because you can always directly reach your peer), so all these fancy E2EE crypto protocols will be replaced with TLS or a similar protocol.

> ...e-mail is mostly centered around protocols, whereas Matrix is mostly centered around specific libraries and clients (in my opinion)...

I disagree on this, but that's ok that we differ in opinion. Also, i would disagree about the crumbling of matrix - either in the protocol sense or app/client or even implementation sense. Could some areas like clients, UX, etc. improve? Sure, of course! Evolution of software need not end if there's room to improve. I'm an admitted fanboy of matrix, but even i know that its not perfect and i hope for continued improvement of matrix. As great as email has been for decades - warts and all - i simply have been expecting (hoping?) for something else by now. It need not be matrix - though again, i'm a fan - but i just meant i hope for open, decentralized mechanism, protocols that serve the world, and become as solid and de facto as email has been (again warts and all). In 10 years, i also beleieve email will still be around...Now, whether it will be considered as standard and universally-accepted as a means for communications, we'll see i guess.

> with so much of my time in the matrix world, i somewhat xpected to start hearing anouncements of alternatives to email.

I presume you're suggesting a new alternative to email rather than Matrix being itself an alternative (which isn't its intent).

The thing about email is it's a set of related protocols - if you want a modern alternative you need to look at those protocols & address legacy problems with them, replacing the ones that need replacing. That's what JMAP is. What you're asking for is JMAP.

JMAP probably isn't perfect, but nothing is & there's no better alternatives I know of. And one major provider using it = more adoption than any other modern alternatives.

> no better alternatives

IMAP. IMAP is the better alternative.

It’s universally supported and battle-tested. We have great servers and clients for it.

It’s not perfect, but it’s also not fundamentally flawed in any way that might put the future of e-mail at risk.

Bolting HTTP and JSON onto e-mail via JMAP — and requiring that everyone implement an entirely new, larger protocol stack — is not an obvious value proposition.

> IMAP is the better alternative.

So the definition of the word "alternative" in this instance is "something other than IMAP" - the argument for JMAP is not competing with IMAP, there's a pre-determined assumption that we're already unhappy with IMAP, hence the search for an "alternative".

It sounds like you disagree fundamentally with moving on from IMAP in the first place, which is fair enough. That's not a debate I'm getting into here: all I'm saying is IFF we are moving on from IMAP, JMAP looks like the best alternative.

Disagree, the dominance of IMAP makes email much worse than it needs to be. To the very point of putting email at risk in the long run.

> We have great servers and clients for it.

I don't know about servers, but I'm still waiting to see a great email client. (For now I get by with Thunderbird, and it's actually going downhill.)

> I presume you're suggesting a new alternative to email rather than Matrix being itself an alternative (which isn't its intent)...

Yes, the intent of my statement was hoping for an alternative to email, and i did not mean to imply that matrix would be the thing that would replace email. Both things seek to achieve different things. and even in some rare overlappiny use-cases, i would say that at this time matrix does not universally replace email.

What i should have stated was that with such attention and (at least in some circles) excitement around newer areas like matrix...That maybe traditional email software devs might have - by now - looked into newer alternatives to email. With apologies to email software devs.

And, yep, I had heard of JMAP some time ago....and i figured by now that it would be far more popular than it is, and that it would have been implemented by many more entities by now. Oh well.

> i figured by now that it would be far more popular than it is, and that it would have been implemented by many more entities by now. Oh well.

Well IMAP is 37 years old and Google still haven't gotten around to implementing it properly. Email as a technology moves pretty slowly.

To be fair here, IMAP has some terrible ideas that have only been remedied with later standards.

For example the (in)famous label thing, why should a letter belong in a single folder. Pointless restriction.

What's the infamous label thing? Are you talking about IMAP or Gmail's broken implementation?

I was under the impression the first public IMAP spec had support for "flags"... did it need later fixing?

Lol! You are so right on all points there!!! :-D

There’s no clear value proposition for a JSON-over-HTTP replacement for IMAP-over-TCP, especially for clients and servers that have already implemented IMAP.

Why would dovecot want to add an entire HTTP server just to reproduce what they already have, with more layers of poorly fit abstraction, despite there being no significant mail clients that require it?

JSON happens to be over JSON and HTTP, IMAP is over TCP and the IMAP protocol. both of those pieces are a relatively small amount of code to parse messages from rather than what to do with said messages. You can transport jmap over whatever you want theoretically.

Each JMAP server should include IMAP QRESYNC like functionality at least. Plus the ability to batch JMAP calls. For instance, if you have five folders with IMAP, it might take at least five hops to access them. With JMAP, it could be accomplished in just one call, returning the location of each new email in each folder.

This really benefits when you first connect a client to a server that has to sync all the mail locally, and partially each time the client starts that has to check all the folders for new messages. But realistically when a client is opened (that is when you turn on the computer till you turn it off, if you turn it off and don't put it to sleep). Also most people has only a few folders, say less than 10.

At this point, JMAP is like Duke Nukem Forever or Winds of Winter. Why does email need JSON over HTTP? IMAP might not be the sexiest protocol, but it serves hundreds of millions of users just fine.

JMAP, on the other hand, is hardly used, and it doesn't seem to solve any issues that users face, which means demand is never likely to reach critical mass.

Because it was designed for webmail frontends, which can communicate with servers from the client side.

Well, if using the system... it makes serialization far less complex in terms of normalization. You can serialize/deserialize through what have become relatively standard libraries for pretty much every language under the sun. This can be utilized in/out of class/record based representations of the data in your language of choice, and acted upon directly. The use of HTTP is as sensible as anything else, as the HTTP actions and paths align relatively well to resource endpoints as well as a text based protocol.

The abstractions and libraries available make this easier... if you look at IMAP it's byzantine by comparison.

The biggest issue with IMAP is that writing a quality client for it that works on all possible permutations of the spec (especially with the botched Gmail IMAP implementation in the mix) is a huge, huge pain in the rear which is why there's a dearth of high quality FOSS mail clients… you've got the old standbys like Thunderbird and Claws and that's about it. Newer clients like Geary either die on the vine or get stuck in a somewhat spartan state because making it more full-featured takes knowhow, time, and manpower that's not generally available.

On the other hand lots of devs know how to work with JSON-over-HTTP APIs and a lot of modern languages even come with JSON serialization/deserialization out of the box, with makes writing quality clients a lot more accessible to a lot more people.