For context: RFC 8620 is the JMAP <i>core</i>, 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.<p>The JMAP <i>mail</i> spec, which is what most people will be more interested in, is awaiting final sign-off before publication as RFC 8621.<p>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.<p>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.<p>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 <i>and command line</i> programs).
IMAP's killer design flaw was that it imposed a strict UID consistency requirement between replica servers if client sync was to work correctly, i.e. you needed a master-slave setup or Paxos, you couldn't use a true multi-master setup or CRDTs with eventual consistency because of the possibility that clients might miss UIDs.<p>There have been attempts to solve this with even-odd UIDs etc. but those broke down on further analysis. There have also been papers claiming to implement multi-master IMAP servers over CRDTs but these never addressed the strict UID consistency requirement and never tested with actual client implementations for sync correctness.<p>How does JMAP address the distributed multi-master server sync problem, assuming eventual consistency?
The introduction, for those not wanting to click too deeply into the link:<p><pre><code> The JSON Meta Application Protocol (JMAP) is used for synchronising
data, such as mail, calendars, or contacts, between a client and a
server. It is optimised for mobile and web environments and aims to
provide a consistent interface to different data types.
This specification is for the generic mechanism of data
synchronisation. Further specifications define the data models for
different data types that may be synchronised via JMAP.
JMAP is designed to make efficient use of limited network resources.
Multiple API calls may be batched in a single request to the server,
reducing round trips and improving battery life on mobile devices.
Push connections remove the need for polling, and an efficient delta
update mechanism ensures a minimum amount of data is transferred.
JMAP is designed to be horizontally scalable to a very large number
of users. This is facilitated by separate endpoints for users after
login, the separation of binary and structured data, and a data model
for sharing that does not allow data dependencies between accounts.</code></pre>
JSON is an incredibly inefficient format for shareable data: it is annoying to write, unsafe to parse and it even comes with a lot of overhead (colons, quotes, brackets and the like).<p>I'd prefer s-expressions.
Is there an extensible JMAP core (what this RFC presents) server framework available? I know there are JMAP mail/contacts/calendar server implementations, but it'd be interesting to have a fairly clean starting point for <i>other</i> potential applications...
I'm really not sure what I feel about the naming. It's one letter off (both on the keyboard and alphabetically) from IMAP. Is this an attempt to coattail the widespread recognition of IMAP or just an extremely unfortunate name collision?