Append lanes: one POST from anywhere, readable only by the vault's owner

A lane is a write-only channel attached to a vault. A sender holds a token for one lane and the owner's public key, seals its message to that key and sends it with a single POST; the owner decrypts with a private key that never leaves them, and the server keeps only hashes and ciphertext, so compromising it yields hashes and ciphertext. One lane per sender, so one can be revoked without touching the others. It is used for key handover, for logs and observations from sessions that hold no vault key, for what a reader fills in on a web page, and for messages between agents on different platforms with different owners. A little like email, and the token is still a secret: it cannot read, but with the vault id it authorises writes.

Decided by. Nobody yet: a candidate for Dinis to read, comment on and decide (keep, rewrite, merge, cut, article first, later, not doing it).

Note. This is the piece that lets a site with no server take input: the newsroom's newsletter sign-ups and shared reading go through the same encrypted, write-only inbox (no-server-by-design), and the agent desktop design sends outputs and the footprint to a vault the desktop can append to and cannot rewrite. The no-server article notes it is the one part of the vault server that needs a small piece of server logic.

Where it comes from

Where the vault keys live Append lanes, the transport behind most of this (newsroom)

What it answers in the 2018 book

none named

Where it goes

Chapter Privacy by design: SG/Send, sgit, and the value of constraints, part Build it without a server (drafting); topic Building blocks: cloud, serverless, free models, git and CI.

Other ideas proposed for the same chapter: Git for things you cannot put on GitHub: what an encrypted vault is, One string is address, authorisation and key; the read key derived from it is safe to publish, An app in a vault runs against the vault without ever being handed a key, Encryption on the client moves the problem from the data to the keys, and the sovereignty line to whoever holds them, Where the keys live: a password manager for the keys a person holds, a registry vault for the keys agents make, Nobody buys it for the encryption: the features came from the constraint, Client-side encryption reduces the exposure under GDPR; it does not take you out of it.

Node idea:write-only-lanes in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.