The four rules, published before the registry exists
Publishing the design before the implementation is the same discipline as publishing the method before the findings — cheap to do in this order, impossible to claim afterwards. These are the registry's stated rules, each derived directly from the documented failure, each checkable against whatever eventually ships.
The rules
Only the owner writes to their own record
The keyserver attack existed because anyone could append to anybody's certificate. The rule that separates our append-only channels (safe) from the keyservers (fatal) is ownership of the written object — so it is the registry's first rule, not a policy bolted on later.
Revocation is a signed append, not a deletion
The single most important operation a registry performs is withdrawing a compromised key — and the keyservers could not delete by design. The corpus's supersede-rather-than-delete rule resolves this: a revocation is an appended statement signed by the key being revoked. The record stays append-only; the revocation is verifiable (only the key holder could have signed it); what the key said before revocation stays checkable; and a reader always sees current state by reading to the end.
Records are size-bounded
One poisoned key reached ~150,000 signatures because certificates had no size limit. A bound generous enough to be invisible and small enough to stop flooding is a stated design parameter — with the honest cost that it will one day reject a legitimate record.
Every entry is signed by something you can check
Nothing in the old network distinguished a legitimate signature from garbage. Every entry in the registry carries a signature that resolves against a key the reader can verify — which is what makes untrusted mirrors safe and the registry's contents portable.
Rules 1 and 2 work together rather than against each other: the registry can be append-only and still support withdrawal, provided only the owner may append.
The deliberate choice: third-party attestations
The replacement keyserver stripped all third-party signatures — which stopped the attack and removed the web of trust with it. That trade must be made deliberately, not inherited: attestations are what made the old system valuable and what made it attackable. A registry that permits them needs rules 1 and 3 enforced hard; a registry that forbids them is safe and carries no social trust signal. For agent identity the question is live, because a key alone says nothing about what the agent may do — which is what mandates are for.
Identity and mandate are separate statements
Current systems give an agent your identity and therefore all your permissions (the shared-drives finding). A registry separates two signed, independently revocable statements:
| Statement | Says |
|---|---|
| Identity | This key belongs to this agent |
| Mandate | This agent may do these things, until this date, on whose authority |
Both are checkable by a third party, and the mandate revokes independently of the identity — a materially different position from a bearer token. One caution, carried from the relay-pattern work: a signed mandate constrains what an agent may be authorised to do, not what it does within that authority. It is one control among several — it composes with the AOMM's ceilings and observation, it does not replace them.
What vaults supply, and what they don't
| Vaults supply | Registry logic must supply |
|---|---|
| Distribution — published vaults are static-hostable and mirrorable by anybody | The ownership rule (rule 1) |
| Custody without access — untrusted mirrors are safe by construction | The size bound (rule 3) |
| Versioning — the state of a key at any past date is answerable natively | Signature checking (rule 4) |
This is why the registry is now realistic: it is a product of existing infrastructure rather than a new system — and the part that remains to build is exactly the part these rules pin down.
Fractal stores need declared roots
The structure nests — public and private registries, registries of registries. What nesting requires is that each store declares which trust roots it accepts; without that, the fractal property produces a graph nobody can evaluate. Who may claim to be a root is a privileged decision that needs a stated answer, even a simple one ("set once by the operator"). The private store — one organisation's own agents, mirrored and verifiable — is the smaller trust problem, the clearer buyer, and the build target before any public registry: a private registry is testable; a public one is a commitment.
Open questions (from the brief, unresolved by design)
- Does the registry accept third-party attestations? The central choice — documented failure on one side, no social trust on the other.
- What is the size bound per record?
- How is the binding between an agent and its key verified? The replacement server used email; agents have no equivalent.
- Who may be a trust root?
- What does an agent's identity attest to — which agent, running where, on whose authority, checked how?