Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

For context: RFC 8620 is the JMAP core, just published. It defines an RPC framework, an object synchronisation protocol, and miscellaneous other things like push channels. It has no data model associated with it, beyond handling blobs.

The JMAP mail spec, which is what most people will be more interested in, is awaiting final sign-off before publication as RFC 8621.

We’re using JMAP in production at Fastmail on our Fastmail and Topicbox products, right through the stack. Both of their web interfaces speak JMAP to the server. Unfortunately at this time it’s not ready for public use: definition of authentication technique is one thing that is deliberately left out of JMAP, and we’re currently using our own system which has no public documentation (and we don’t expose /.well-known/jmap yet either). The intrepid user may be able to figure it out, but we won’t be providing any support for it yet. We use the JMAP mail spec, the draft calendar and contacts specs, and a handful of our own specs for our own data types, also not publicly documented at this time.

JMAP is much more complex than the standard sort of simple REST API, but there is cause for all aspects of its complexity; the most notable complexity in it is its record state management, part of it being an object synchronisation protocol; an advantage of that is that robust offline support is feasible, even fairly straightforward. I’m looking forward to working on offline support in the Fastmail web app.

I personally think the increased complexity is well worth-while, and I have several products I’ve been sketching out and working on personally (completely unrelated to the world of email or to my employer Fastmail), and all the ones with any kind of client-server API I intend to build atop JMAP, because they’ll benefit heavily from it with respect to features like real-time interface updates and offline support (for web, desktop and command line programs).

I've hacked IMAP long enough to want it thoroughly dead, so I've been following JMAP from afar and waiting for Fastmail to publish this for a long time. Props to the team, and I hope the (publicly) missing parts will come soon enough.

Note that IETF working groups publish drafts all along the way, so there’s https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ for the current text of the mail spec, which is probably what will be published.

Are there open-source JMAP implementations you recommend? I understand not wanting to commit to the protocol for customers but I suspect it's been dissuading the creation of third-party clients since there's nothing to use it with.

(Also, a little bit off-topic, but as a Pobox customer, can I use JMAP / am I already using it from the webmail interface?)

Our own implementation sits atop the open-source Cyrus mail server. I’m not sure if JMAP is enabled by default in stable releases yet, or whether you have to go for the bleeding edge to get it.

I personally have no basis upon which to make any recommendations for JMAP clients, servers or libraries. The JavaScript one we use in our webmail is not particularly suitable for others to use, despite being open source, as it’s quite tied to our Overture web framework which pretty much only we use.

There is, however, a list at https://jmap.io/software.html of software that supports JMAP.

On your Pobox question: when reading your email at fastmail.com, you’re using the Fastmail webmail, which speaks JMAP.

I've lately toyed with using Avro in place of JSON and found it shows some fairly substantial savings. It has a JSON encoding as a backstop for places where the binary encoding isn't kosher.

Section 1.5 of the RFC nails the colours to I-JSON with a "MUST". Do you envisage any amendment to allow equivalent encodings? I know this is indirectly discussed elsewhere, I'm just going through an Avro infatuation.

All JMAP servers must support that format, but that doesn’t preclude supporting other formats via extensions. We use custom compression, for example; and a WebSocket transfer layer for the API parts, instead of HTTPS, is being standardised. In such cases, the server declares its support for such capabilities in the session object (which will be in the baseline format, JSON), and clients that know about them can opt into their behaviours, knowing that the server supports it.

If you say 'object sync protocol', would it work to build a dropbox alternative? I'd love for you guys to make one, I'd pay a premium over the 120/yr I now pay Dropbox for a sync-only product that you would just leave alone (well, as long as it's in a working state) after that, ie none of the fucking around dropbox is doing.

I’ve been waiting on JMAP to be published for years. Looking forward to its standardization.

Do you know why in particular 8621 is still in AUTH48? Usually when there's a family of new standards they all get issued essentially simultaneously that I've seen.

Yeah, a couple of last minute editorial things - "headers" -> "header fields", an example to show the use of Content-* headers for single-part messages because it was considered a little unclear, and an update to the contact address for the IANA registrations. They should be cleared up this week with everyone (except me, boohoo, couldn't make it due to local commitments at home) in Montreal for IETF105.

Reply on news.ycombinator.com