Plans for JMAP FileNode PATCH / Blob Extensions and delta sync?

Questions
1

Your question

Hi,

Mario suggested that I post some of our more technical questions here, so I hope this is the right place.

We are currently building a hosted environment based on Stalwart. In the first phase we plan to use Stalwart for mail, calendar, contacts and file storage, with Bulwark as the web client.

For a later phase, we are investigating the possibility of building a native file sync client for Windows, macOS and Linux.

Ideally, we would like to keep Stalwart as the central storage platform rather than introducing a second file storage system purely to get efficient desktop synchronization.

The Bulwark team pointed us towards the newer JMAP FileNode and Blob Extensions drafts:

  • draft-ietf-jmap-filenode-14
  • draft-ietf-jmap-blobext-01

From what we understand, these specifications could provide a very interesting foundation for this.

In particular, the FileNode draft describes direct HTTP writes, including PATCH, while the Blob Extensions draft describes delta-based mechanisms such as application/x-rdiff-delta, DeltaRecipe, PatchRecipe and chunkSize.

Our intended use case would eventually be something like this:

A customer has a 10 GB file synchronized locally. They modify approximately 20 MB of that file. Instead of uploading the complete 10 GB file again, the sync client calculates a delta and transfers only the changed data. Stalwart would then apply that delta to construct the new version.

This leads to a few questions:

  1. Does Stalwart plan to implement the newer FileNode direct-write/PATCH functionality and the delta mechanisms from the Blob Extensions draft?
  2. Is any of this already on the Stalwart roadmap?
  3. Would this architecture make sense for a native sync client built around Stalwart, or are we misunderstanding the intended use of these JMAP extensions?
  4. If this functionality is not currently planned, would Stalwart Labs potentially be interested in implementing it if there were commercial interest in it?

We would potentially be open to discussing sponsoring or contributing towards such development if that could help move this functionality upstream.

For us, the ideal long-term architecture would be to keep Stalwart responsible for the central data — including File Storage — and build the native sync client against standard JMAP/FileNode APIs rather than introducing a proprietary block-sync protocol or a separate storage platform.

There is no immediate urgency: our first phase will be web-based. But we would like to make the right architectural choices now and avoid having to migrate customer files to another storage platform later.

I’d be very interested to hear how the Stalwart developers see this.

Thanks!
Joost

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

No documentation or source references mention the Blob Extensions draft (draft-ietf-jmap-blobext) or FileNode’s delta/PATCH mechanisms at all. The current implementation covers only the base JMAP FileNode read/write operations (get, changes, query, create, update, destroy) listed in the permissions reference, plus standard WebDAV PUT/GET/DELETE/MKCOL for file access — nothing about partial-write PATCH, rdiff-style deltas, or chunked blob patching.

This isn’t covered in the current docs. A community member or staff member will follow up.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

FileNode itself is implemented, and it’s in 1.0.0, which is due at the end of this month or early November. Direct HTTP writes and PATCH from section 4 of the FileNode draft aren’t, and nothing from blobext is either, so a delta-sync client couldn’t be built against Stalwart’s JMAP API as it stands today.

You’ve understood the drafts correctly: FileNode carries the tree and metadata, and the blob2 recipes build a new version from an old blob plus a delta, which is the standards-based route to what you describe. Blobext is still at revision 01 and may change a fair amount before it settles. For 10 GB files the protocol is also the smaller half of the job. Blobs are stored whole and content-addressed, and the RFC 9404 Blob/upload we already support, which can stitch ranges of existing blobs together with new data, assembles the result in memory and is capped by maxUploadSize. Cheap deltas on files that size need chunked storage and streaming assembly underneath before the endpoints are worth much.

Sponsorship is a conversation to continue with Mario. A concrete use case like yours does help when deciding what gets built.