hub.sgit.ai: The Fractal Forge
A forge whose application layer is the browser: the client holds the key, the server stores ciphertext and reads nothing. A hub is itself a vault — a cover, a catalogue and a loader — which means a hub can list other hubs and the network is fractal by composition rather than by new protocol; anyone can run one, because “run a hub” means “publish a folder”. The pack opens with two findings about the shipped CLI: the sub-vault primitive every brief builds permissions on does not exist, and a third access tier — the structure key, which decrypts a vault's shape but not its content — is shipped, tested and unused.
fbebe0c: the raw sources under src/ are byte-identical to that commit's tree — verify with a diff against it. Each document below has a reader page with the same apparatus as the site's documents.The documents
| Document | Role |
|---|---|
| 00 — The executable dev brief | The brief the hub-builder runs from: Step 0 before architecture, the six rules, the step table, what is not theirs to decide |
| 01 — The model, and the fractal | The settled forge model, and the 18 Aug addition: a hub is a vault, so the network is fractal by composition |
| 02 — Capability audit | The CLI-side inventory (done — facts), the two findings, and the web-side audit template that gates architecture |
| 03 — Architecture & flows | The ciphertext boundary, the single-file data path, the fractal walk, and the five user flows |
| 04 — Permissions as key topology | Possession is access: the four key positions, worked topologies, the missing-primitive options, and CI by scope |
| 05 — Commercialisation | What you can charge for when you cannot read: the inversion, four honest revenue lines, what must never be monetised |
| 06 — Interface mockups | The one screen that matters (the live ciphertext panel), the hub index's four row states, key handling, fork = rekey |
| 07 — Roadmap & open questions | Build order 0–10, the four absences stated plainly, blocking / important / answered questions, what each team owes |
Why it is on this site
This pack is the site's arguments in the builder's seat. Finding 1 — every brief assumed a sub-vault primitive that no code implements — is the hope gap caught by an audit before it shipped: enumerate what exists before you architect on it. The four key positions (vault, read, structure, none) are capability attenuation in practice — each weaker key derives one-way from the stronger. The CI section is this site's over-privileged-agent problem verbatim: a runner must read to build, and the only model-consistent answer is a scoped key — least authority for a non-human identity, with the honest open question of who assembles the scope. And “revocation is not retroactive” is the operational face of the registry rules' supersede-not-delete: rotation protects the future and returns nothing already taken.