You know, you shouldn't do #JMAP. It really is pretty awful. And while IMAP4 is weird, that's what you should do. But my real question is, what was the JMAP client I should try? 🙈
I think what annoys me the most is that this doesn’t embrace HTTP standards at all, it’s a single endpoint that is completely custom behind that, and I don’t understand why that can’t be done properly. Each mailbox and message should be a URL and not hidden behind some arbitrary RPC #JMAP
@helge Yeah, if you want to do mail-over-HTTP then do mail-over-HTTP, don’t use port 80 for some other protocol. And also there’s no good reason for JMAP to exist, just use IMAP. The IMAP protocol design is perfectly fine, and Marc Crispin ensured it’d even work extremely well over a 2400bps link.
@eschaton I mean there is a valid reason: You cant really implement IMAP in a web client. But that doesn’t mean you can’t do the bridge properly …
@eschaton They do the same with jCal and jCard. While it is ok to desire a JSON variant of the payload and have a standard for that, it’s technically nonsense that adds nothing. You can just use Versit.
@helge Not being able to implement IMAP in a web client is a positive, not a negative. JavaScript was a mistake.
GitHub - GoogleChromeLabs/telnet-client

Contribute to GoogleChromeLabs/telnet-client development by creating an account on GitHub.

GitHub
@eschaton @helge I don't know what's different about JMAP. But, having written an email client at one time, I would dispute the claim that IMAP is perfectly fine.
@atomicbird @eschaton It’s difficult (UTF 7!!) but efficient and widely supported. There is no question that it’s weird but there is also no question that it just works.
@atomicbird @eschaton If you run a service at the scale of Fastmail, stateless protocols certainly have an advantage, though iCloud also runs on IMAP and seems to have no particular issues doing that.
I'm absolutely not opposed to HTTP mail, like at all, I love it, I just don't think that piping everything through one endpoint is a good approach. This can be, and has been, done better.
@helge Oh, so like GraphQL 🤪
@dimitribouniol SOAP is the original here … (XML-RPC is, but I find this acceptable for some reason)
@helge Why’d you start on such a bizarre journey? Why care about JMAP at all?
@atlauren Because @obrhoff being annoying about it 🙈
I mean why not, more standards are better than less, and while it is not a good standard, it’s the sole one for HTTP based email, ie for webmail apps.
I also dislike the proposition that standards are hard, they usually are not. You can just do it, if you care.
@helge @atlauren Appreciate the effort to let me look like a fool. Although I thought it would be easier 😈
@obrhoff @atlauren I mean to be clear the claims of JMAP really are complete nonsense.
IMAP is awkward but hard to beat on efficiency, and the awkward part doesn’t matter that much because the libs are available.
If they would have branded that on what it is, mail for web clients, it would be more reasonable.
I suspect it’s because they can’t do stateful efficiently with Cyrus because it’s old, but I’m not sure.
@helge Did you meet the Fastmail folks while at CalConnect? Good blokes. IIRC they were significant movers WRT JMAP and particularly JMAP Mail.
@atlauren Yes I actually did! They are cool people generally. At the time it was jCal/jCard which are also kind weird. (but also easy to support)
@atlauren Just to be clear, the thing which rocks here is that they are not doing anything proprietary.
I think the claims are very misleading/wrong and generally it's not well done, but at least they, unlike others, are doing an open protocol others can implement. I'd still vouch for iCloud, because they apparently can do the actual standard w/o complaining 🙂
Plume — Email, as it should be.

A native Swift email client built on JMAP. Fast, private, and built for iPhone and Mac.