The JSON Meta Application Protocol, RFC 8620 (2019) — a generic JSON-over-HTTP method-call protocol with batching, state strings, change and query-change methods for delta sync, push over EventSource or WebSocket, and blob upload and download. Built at Fastmail to replace IMAP, and designed from the start as a base that other data types extend — mail, calendars, contacts, and now files.
JMAP
JMAP is usually filed under email, because RFC 8621 is the mail profile and that is what shipped first. But RFC 8620, the core, is a generic protocol: a client POSTs a batch of method calls as JSON, the server answers each one, and every data type gets the same five methods — get, changes, set, query, queryChanges. The data type is a plug-in. It is a JSON-RPC-shaped protocol over HTTP with a sync model baked in, which is why it keeps coming up when people design new ones.
- State strings and
/changes- Everygetreturns a state;changessince that state returns created, updated and destroyed IDs. Delta sync is a protocol feature, not a per-type invention. - Batching with back-references - Many calls in one request, and a later call can reference the result of an earlier one, so a create-then-read is one round trip.
- Push - Servers advertise an EventSource URL or a WebSocket; clients learn that state changed without polling.
- Blobs - Binary data is uploaded and downloaded separately from the JSON surface and referenced by
blobId. RFC 9404 adds inline blob methods for small cases.
I keep JMAP here because it is the best worked example of a design the Model Context Protocol is converging on from the other direction: method calls over HTTP, a notification channel, and data types that extend a shared base. JMAP solved the synchronization and binary-transfer questions in the base protocol so that every extension inherits them, which is exactly the argument MCP’s working groups are having about whether file operations belong in the core, in an extension, or in each SDK. The file-system extension, JMAP FileNode, is where that pays off.
