The Append Lane Is Already Shipped And Account-Less: Four Tiers And Five Corrections
Summary
The vault-to-vault message transport as it actually exists, and the corrections it forces on work already written. The finding that changes the most: posting to an append lane requires only a token in the request body — no account and no access token — and returns a blind acknowledgement, which is precisely the narrow account-less ingress the enrolment architecture treated as the thing that had to be built. The capability model is four tiers rather than one credential, with the server storing only hashes of the first three. Five earlier claims are corrected, and the shipped-versus-proposed boundary is preserved exactly, because two halves of the mechanism are in different states.
Key concepts
- Four tiers, hashes on the server — append token, enumeration key, write key, and a private key never sent
- Registered anchors — the recipient decides which senders are accepted, using a credential they do not have
- Shipped versus proposed — the lane is verified; the client sealing layer and the address derivation are not
- The composition gap — every piece documented, and nothing saying they combine
Key ideas
- The blind acknowledgement enforces the write-only property in the response itself, which is a stronger form of the pattern than a permission model alone.
- A total compromise of the server yields hashes rather than capabilities — the catastrophic failure principle implemented rather than asserted.
- If it is not code-verified, label it proposed: a page that says not yet is better than one an agent trusts and acts on.
- Documenting capabilities separately and never documenting that they combine is how a working feature becomes invisible.
On this site
Became the shipped page, and revised the enrolment page from a build into a configuration.