One string is address, authorisation and key; the read key derived from it is safe to publish

A vault key is a passphrase and a vault id in one string, and it is three things at once: the address of the vault, the authorisation to write to it, and the key that decrypts it. Lose it and the data is gone; leak it and someone can rewrite your history. From it, one way, comes a read key: same vault, read-only, safe to publish, and the read key is the entire credential, with no account, no login and no access request. That asymmetry is the whole sharing model: every vault linked from sgit.ai is published as a read key, and no vault key has ever been published, a rule enforced by a tripwire in the release pipeline.

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 site runs on the same rule: the public read key in admin/content/vault.json is the only key that belongs in the repository, and the gate refuses the private prefix (CLAUDE.md). The second article adds the other credentials that sit beside the vault key, each made for one job: a write key the server checks as a hash, an append token that writes one message to one lane and nothing else, and a PKI key pair (RSA-OAEP 4096 for encryption, ECDSA P-256 for signing). In the browser the key sits after the # in the URL, which browsers do not send to the server.

Where it comes from

Git for things you cannot put on GitHub The part that is easy to say and hard to build; Ten seconds of proof; Try it (newsroom)
Where the vault keys live One secret, and the keys derived from it (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, 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, Append lanes: one POST from anywhere, readable only by the vault's owner, 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:the-read-key-is-the-sharing-model in graph.json; see it in the graph. Source: admin/content/graph/ideas.json.