Comment by mcint | Hacker News Reader

Comment by mcint | Hacker News Reader

Parent Full thread

JMAP benefits people who want to use broadly accepted, open standards. Especially standards better adapted to present and future needs: mobile use - lower latency & fewer round trips, lower end-user device power usage.

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://jmap.io/

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)?

Thanks for the callout :) I'm not doing so much development on Cyrus any more - I still attend the weekly team meetings and do code and design review, but trying to keep my focus more on company operations and standardisation work.

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.

Bringing the documentation up to date would be then a logical step.

Cannot overstate the significance and value of documentation.

The multiplexing of requests has me pretty interested.

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.

> Especially standards better adapted to present and future needs: mobile use - lower latency & fewer round trips, lower end-user device power usage.

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.

Reply on news.ycombinator.com