04 — Permissions as key topology
Summary
The part most likely to be got wrong, because it inverts a forge assumption: permissions here are not a policy a server enforces — possession of a key is access, there is no referee, and a cryptographic boundary has no bypass. It must be designed in advance, and revocation is not retroactive. Four positions exist today (vault key, read key, structure key, no key = custody), each derived one-way so the weaker discloses nothing about the stronger. Worked topologies for an open-source project, a mostly-private company estate, and a contractor — all expressible now as separate vaults plus key tiers. Then the missing primitive's three options: A, separate vaults plus a link convention (recommended — the fractal edge applied inside a vault, no format change); B, nested sub-vaults with derived keys (a real protocol project); C, per-path content keys (breaks CAS dedup — not recommended). CI is the genuine hole: a runner must read, and the model-consistent answer is a scoped vault, whose open question is who assembles it.
Key concepts
- The four key positions — vault, read, structure, none — a ladder of one-way derivations; handing out the weaker key reveals nothing about the stronger
- Option A: separate vaults + a link convention — the same mechanism the fractal already needs, applied inside a vault; small, honest, and buildable today — B should not gate the hub
- Revocation is not retroactive — rotating a key protects future commits and returns nothing already taken; a git-hosted publication cannot revoke read access at all (measured)
Key ideas
- A shape you can see is easier to audit than a table of rules nobody has read — the honest counterweight to granularity costing structure.
- The hub as a useful index of things it cannot read is the shape most organisations actually have.
- Publish the two hard limits; do not let users discover them.