Hacker News Reader

Comment by stonogo | Hacker News Reader

This is a problem, but the other problem is the tools to implement the service. You can use Cyrus, Apache James, or Stalwart, and that's it. These tools do not integrate with anything; in the case of Stalwart (the only JMAP server not in "experimental" status) you can't just install a JMAP server attached to an existing email service; you have to hand it complete control of everything, even unto the on-disk storage of mail. This is a complete non-starter for any email service outside of hobby/personal hosting.

In other words, even if someone wanted to make JMAP available to their users, they'd have to tear the whole thing down and rebuild it in JMAP's image, and the tools available to do so are not fully-featured or integratable enough to do so.

View on HN

> These tools do not integrate with anything; in the case of Stalwart (the only JMAP server not in "experimental" status) you can't just install a JMAP server attached to an existing email service; you have to hand it complete control of everything, even unto the on-disk storage of mail.

This point you mention is being improved. The next release of Stalwart JMAP (expected in one or two months) will delegate user management to either a SQL database or an LDAP directory. Messages will be stored in either Maildir or MinIO/S3. And all other information will be in either SQLite or FoundationDB. All these features were already implemented except MinIO/S3. Development progress can be tracked at https://github.com/stalwartlabs/mail-server/tree/main/crates...

Cyrus is what fastmail use for their own mail servers. And even the fastmail web ui uses jmap.

I don’t know where it says jmap support is experimental, but I think it’s pretty stable and well supported in practice. The main maintainers of the project depend on it utterly.

They don't use the word "experimental" any more but they call it a "work in progress": https://www.cyrusimap.org/imap/developer/jmap.html bottom of the page.

The file storage approach is unfortunately super common and makes a bunch of really basic things difficult and slow. Need to phase it out more heavily, especially from new implementations.

Telling people who have decades of perfectly serviceable email solutions that they need to 'phase out' what works is a great example of an unconvincing argument. What you say might be true from a developer's perspective but maildir is a battle-tested, accessible, well-understood and interoperable storage format. Bundling everything up behind some bespoke SQL schema might ease performance hurdles but it sucks for everything else.

Does it work though? Nobody runs such systems at scale, for very good reasons, because maildir just sucks in so many ways. Horses have also been battle-tested, they're well-understood, but they don't transport tonnes of cargo and getting kicked in your face because they don't like you isn't pleasant.

So if it takes a custom schema in a (No)SQL database, so be it, it's simply so much more performant, scalable, reliable and usable. It's simply idiotic how much maildir-based software starts "dying" at around 100000 emails in a folder, in 2023!

Reply on news.ycombinator.com