Some Data Has a Writer
Every write verb Delta had before this one moves a file: upload and commit land bytes, mkdir and symlink make entries, keep sets a file aside, DELETE removes one. That is the right vocabulary for a folder of photos. It is the wrong vocabulary for data that has an owner: an app with a canonical writer that validates what it is given, takes its own locks, compares a revision before it writes, and records history.
The soul vault's store is the first such owner. A note written there goes through compare-and-swap (the writer names the revision it read; a stale one is refused), a write gate judged per Mac, and a commit that records who wrote it. If another Mac simply uploaded the note's file into the store's folder, every one of those guarantees would be bypassed by a file appearing underneath the writer. So the other Mac must not write the file. It must ask the owner to write.
Before Coop 1110-41, that asking was assembled from file verbs: a request file delivered by a transfer job, then applied by the owner through api. It worked, and took 0.34 s for one write. The call verb replaced it.
The Call, End to End
- The app asks its own Mac's Delta on loopback:
POST /v1/peer/<mac>/call/<share>/<op>, a JSON body, and four headers: the local token,X-Delta-App,X-Delta-Request-Id, and optionallyX-Delta-Timeout. - This Mac's engine checks the request id and the time limit before anything leaves; a missing id or a limit that is not a number of seconds is
bad_requestright there. - The engine carries it to the owner's gateway as
POST /v1/call/<share>/<op>over the chosen route, with Delta's own authentication. The body is held toMAX_JSON_BODY(4 MiB). - The owner's gateway checks who may (
_require_write), reads the body, and hands it to the share'scall(). - The child's answer goes back as JSON with
Cache-Control: no-store. Delta keeps neither the request nor the answer.
When the owner is this Mac, step 3 disappears: the engine runs the share's call in place, with no network at all. Measured on the live fleet (2026-11-10, Soul Vault's store on the Pippa-role Mac, three calling Macs on Thunderbolt): a note written from another Mac took 72 to 83 ms from the app's call to its answer, 58 to 72 ms of it inside the owner's handler, which is the store's own commit. A stale revision the store refused took 1.1 ms in the handler and 7 to 16 ms for the caller.
The Root Class Refuses; the Child Opts In
DataShare.call raises Forbidden, like every write on the root class. A share that owns a canonical writer overrides two methods: writable() returns true, and call() does the work. Overriding only call is not enough, because the authorization check asks writable() first. And the file verbs stay refused on such a share, with a message that says why: it "takes no file writes: its owner writes through a call". Soul Vault's StoreShare is exactly that shape, with three operations (write, create_soul, delete_soul); its read-only cousin for the household's Mac returns writable() == False and refuses every call.
Who May, and What the Child Is Told
_require_write is the same check every write passes. The share must be writable; the calling Mac, as Delta verified it (the tailnet roster on the tailnet, the issued ticket on the LAN), must be this Mac or allowed by the share's writers; and the calling app, from X-Delta-App, must be in the share's apps. Then the child receives caller, app and request_id as arguments.
The caller argument is the verified Mac, never a name the request body carries. A request may still describe itself (Soul Vault's request documents name their own caller and request id), and that is the child's to compare, never to trust: Soul Vault refuses a request whose stated caller differs from the Mac Delta verified, or whose own request id differs from the id of the call that carried it. Be honest about what the app name is worth, too: X-Delta-App is what the calling process says it is, on a Mac whose local token it holds. It separates apps that cooperate. A writer that must tell two apps on one Mac apart needs more than that header.
The Request Id Is the Caller's Name for One Call
X-Delta-Request-Id is required: letters, digits, . _ : -, starting with a letter or digit, at most 128 characters. The owner keeps each outcome by it and answers a repeated id with the first result instead of writing again. That one rule is what makes asking again safe after a lost answer, which is the whole subject of the next lesson. The gateway's access log names it too (call=<id>), beside the Mac and the app, so one call can be followed across both Macs.