JMAP FileNode

JMAP FileNode is the closest thing on a standards track to what the agent world is now building: a JSON method-call protocol over HTTP in which files are a data type. A FileNode has a name, a parent, a blob reference, a size, a media type and timestamps. Folders are nodes without a blob. Everything else — listing, creating, renaming, deleting, finding out what changed, being told when it changed — is inherited from JMAP and the blob extension, RFC 9404.

• Metadata and bytes are separate - Upload the blob first, get a blobId, then FileNode/set creates the node that references it. Download is by blob, with ranges. The two never travel in the same message.
• Delta sync for free - FileNode/changes and FileNode/queryChanges come from the base protocol’s state model, so a client never re-lists a folder to find out what moved.
• Push notifications - JMAP’s EventSource or WebSocket push covers file nodes like any other type.
• Explicitly a WebDAV replacement - The author, Bron Gondwana of Fastmail, positions it as doing for files what JMAP did for mail: the same job as WebDAV, CalDAV and CardDAV, without the XML and the extra HTTP verbs.

When the Model Context Protocol chartered a Filesystems Working Group in September 2026 to make resources writable — create, update, delete, stat, optimistic concurrency, change notification — it described this document without citing it. FileNode is the IETF answering the same question for a JSON-RPC-style protocol, and it had already settled the two hardest parts: keep bytes out of the method channel, and make change tracking a property of the protocol rather than of each type. I would put this at the top of the reading list for anyone building a file surface for agents, and I will be watching whether the two efforts ever acknowledge each other.