Most active commenters
  • woodruffw(3)

←back to thread

JMAP for Calendars, Contacts and Files Now in Stalwart

(stalw.art)
316 points StalwartLabs | 11 comments | 22 Oct 25 17:26 UTC | HN request time: 0.211s | source | bottom
Show context
sylens ◴[22 Oct 25 19:44 UTC] No.45674189[source]▶
We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.
replies(3): >>45674372 #>>45675000 #>>45675410 #
1. woodruffw ◴[22 Oct 25 19:59 UTC] No.45674372[source]▶
Serious question: what’s the differentiator if major email providers don’t support it?

(This should not be interpreted as a defense of IMAP.)

replies(4): >>45674503 #>>45674641 #>>45675645 #>>45676469 #
2. dijit ◴[22 Oct 25 20:08 UTC] No.45674503[source]▶
I'd make a reasonable guess that it enables much better Javascript clients, either via Electron or the Web Browser.

You don't need major providers to support it, they support SMTP and that's how messages are relayed. JMAP is just so you: the client, can fetch your mail from wherever you host your mail.

3. sylens ◴[22 Oct 25 20:19 UTC] No.45674641[source]▶
Fastmail supports it, and it sounds like Thundermail will too
replies(1): >>45676067 #
4. mjrpes ◴[22 Oct 25 21:54 UTC] No.45675645[source]▶
One big differentiator is JMAP allows one network connection to track new emails that may get delivered across different folders. With IMAP you need a connection open for each folder.
replies(3): >>45675675 #>>45676450 #>>45676464 #
5. woodruffw ◴[22 Oct 25 21:57 UTC] No.45675675[source]▶
Okay, that's a great feature! But I guess I'm asking what the differentiator is if major email providers don't use it.
6. Vinnl ◴[22 Oct 25 22:39 UTC] No.45676067[source]▶
Thundermail will be built on Stalwart, so yeah :)
7. mmooss ◴[22 Oct 25 23:27 UTC] No.45676450[source]▶
Why is that necessarily a good thing? If there's a problem with one folder - or just a large email - all are delayed?
8. kilburn ◴[22 Oct 25 23:29 UTC] No.45676464[source]▶
Implementing IMAP NOTIFY [1] would be a simpler path assuming you have IMAP implemented already though.

[1] https://www.rfc-editor.org/rfc/rfc5465.html

9. whatevaa ◴[22 Oct 25 23:29 UTC] No.45676469[source]▶
IMAP is a shit protocol in general. Notably, email UIDs are not guaranteed to be static across sessions (aka, next time you connect they may be different), which is just straight up dumb. You IMAP client has to do a lot of workarounds just for this, which leads to gnarly bugs and inefficiences.
replies(2): >>45676646 #>>45678693 #
10. woodruffw ◴[22 Oct 25 23:57 UTC] No.45676646[source]▶
I don’t even remotely disagree with this. But that wasn’t the point: the point was that JMAP is only a competitive advantage if (major) email providers actually adopt it. Bad technologies regularly win because of inertia.
11. brongondwana ◴[23 Oct 25 06:08 UTC] No.45678693[source]▶
That's not strictly true. IMAP has two things, UIDs which are mostly static (there's a UIDVALIDITY cache invalidation key to let a client know that UID information has been lost and recalculated); and message numbers.

UIDs don't change, but of course they can be deleted so it's a gappy list, meaning you can request even quite a large looking range of UIDs and get nothing back.

Message numbers change in every session, and also change every time you get an EXPUNGE. They're basically an ordered list without gaps, so you do a memmove at the offset of the EXPUNGE each time you get an expunge.

There are efforts like UIDONLY (RFC9586) to avoid having to keep that mapping at all, and there's OBJECTID (RFC8474) to let you cache a lot more even when UIDs are changed or when messages are moved between folders.