In 2019 the global keyserver network was flooded with garbage signatures until importing a poisoned certificate broke your installation. Its own maintainer called it unsalvageable — and the cause was a design goal stated at the outset, not a bug. Anyone proposing a key registry now should be able to show they designed it with that history in hand. This site is that history, and the rules it produces, published before the registry exists.
The design goal that killed the network was append-only — a pattern this project uses in five places, and rightly. A documented catastrophe caused by a pattern you rely on deserves a precise resolution rather than a shrug. Here it is.
| Append-only, owner-writes | Append-only, anyone-writes | |
|---|---|---|
| Who may write to a record | Only its owner | Anybody |
| Can a stranger grow your record? | No | Without limit |
| Is every entry attributable? | Yes — signed by the owner | No — garbage is indistinguishable |
| Can something be withdrawn? | Yes — a signed append supersedes | Never — by design |
| Failure mode | A record grows slowly, in the owner's own hand | Destroyed the network |
Append-only is safe when a writer appends only to objects it owns, and fatal when anyone may append to somebody else's. The rule to carry forward is not "append-only" — it is the writer owns what it writes. The full argument, with sources →
Each one turns around a property the 2019 attack abused. Publishing them now is cheap; claiming them afterwards is impossible. If something ships that breaks one, this site is the evidence.
Turns around: anyone may append to anybody's certificate. This is the rule that carries the append-only pattern through the history intact.
Read → Rule 2Signed by the key being revoked. The record stays append-only, the revocation is self-authenticating, and what a key said before revocation stays checkable.
Read → Rule 3One poisoned key reached ~150,000 signatures because certificates had no limit. A stated parameter — with the honest cost that it will one day reject a legitimate record.
Read → Rule 4Which is what makes untrusted mirrors safe and the registry's contents portable — a reader verifies without trusting whoever served the bytes.
Read →Externally verifiable, and cited. Nothing on the failure page depends on trusting us — which is why it leads.
Two prominent contributors' certificates flooded with bogus signatures. Importing one broke a working installation in hard-to-debug ways; the recommended mitigation became to stop using the network entirely.
A key server could add information to a certificate but could never delete a certificate or anything in it — stated at the outset. Changing a goal of that magnitude means a fresh sheet of paper, not a patch.
The successor strips all third-party signatures and unverified identities. That stops the attack completely, and removes the web of trust with it — a trade to make deliberately rather than inherit.
Current systems give an agent your identity, and therefore all of your permissions. The registry separates two signed statements that revoke independently — a materially different position from a bearer token.
Identity: this key belongs to this agent. Mandate: this agent may do these things, until this date, on whose authority. Both checkable by a third party; the second revocable without touching the first.
Read → ComparisonA token's scope is knowable only to its issuer. A mandate's scope is published, so the party relying on it can see the limits of what it was given — and refuse work outside them.
Read → The cautionIt constrains what an agent may be authorised to do, not what it does within that authority. One control among several — it composes with observation and ceilings, it does not replace them.
Read →The idea is old. What changed is that vaults supply the layer a key server used to have to build for itself: distribution (a published vault is readable from static hosting and mirrorable by anybody), custody without access (untrusted mirrors are safe by construction), and versioning (the state of a key at any past date is answerable natively). What vaults do not supply — the ownership rule, the size bound, signature checking — is the registry logic, and it is exactly the part that failed last time.
A registry with one organisation's agents in it is testable; a global one is a commitment. Steps 2 and 3 — the failure page and the rules — are done, and were done before anything was built.
Read → Honest tensionsSize bounds will one day reject a legitimate record. Fractal trust needs every store to declare its roots. Attestation is valuable and dangerous. Published, not buried.
Read → Open questionsStarting with the central one: does the registry accept third-party attestations at all? A documented failure on one side, no social trust on the other.
Read → The sourceEverything here comes from one document, captured whole with its citations and readable in-page. The raw markdown stays the source of truth.
Read →This site is published by the sgit project, which builds the vault layer the registry would be built on. So this is a participant publishing a design — stated here, upfront. The discipline applies lightly to the history, because those claims are externally verifiable, and heavily to the design, which is why the design is published as checkable rules before the thing exists. And we publish where our own approach loses: vaults do not supply the registry, do not solve attestation, and a mandate constrains authority rather than behaviour.