The Register Was Designed In June: Published Keypairs Are Fixtures, Not Identities
Summary
The register the memo asks for was designed on 5 June (v0.32.4): clues not storage, entries as nodes with relationships as the value, two-level trust in which self-declaration grants nothing, the register as a vault holding no private data, connectors to any identity provider, and resolution as the caller's job — so today's work is operationalisation, not design. The correction that matters: a keypair whose private half is published is not a weak identity but no identity, permanently — a fixture, whose whole purpose is to exercise the plumbing, marked by a required private_key_published flag read before any signature, never reachable from the real trust graph, and retired only by republishing under a fresh key. Personas ship as signed agent cards; the notary is a workflow identity with keyless signing; and push protection will block the published key, which makes the recorded bypass part of the demonstration.
Key concepts
- The fixture class — adopted into the MVP pack as change C3 — the flag before the signature
- Evidence to the asserter's record — the 2019 rule applied to vouching — the same rule the MVP pack chose independently
- A fixture voids two rules — revocation and signature-substance — which is what makes fixtures the rules' first test
- Retrieval is not persistence — fetching a key works only while the key is public; the 19 August question stays open
Key ideas
- Whether the private half is published is the most consequential evidence an entry can carry.
- A fixture's append lane is a public inbox — anything sent to it is readable by anybody.
- The notary must be an agent you run: the two-populations thesis as an implementation constraint.
- Publishing a key inside vault ciphertext evades secret scanning rather than satisfying it.
On this site
Folded into the registry MVP pack as change-control entries C2, C3 and C4; the tabletop's inject I5 runs its central warning as an exercise card.