03 — Architecture & flows
Summary
Drawn so it is obvious from the diagram alone that the server cannot read: the browser holds the key and does everything a forge does — derive ids, decrypt, walk trees, diff, render, merge — while only ciphertext and client-computed names cross the boundary. The server's entire read surface is one GET of a name it cannot interpret; it cannot distinguish a public vault from a private one because the bytes are identical. The single-file data path is the whole system in miniature (rendered below as a sequence diagram), with two shipped optimisations — the per-path index turning path resolution into one request, and sparse fetch making the honest performance claim true. Then the fractal walk (visited set, depth bound) and the five user flows, including the key-supply ladder and the vault-key refusal.
Key concepts
- The ciphertext boundary — one GET of a client-computed name is the whole read surface; every response is opaque bytes — the hub cannot tell a file from a folder
- The key-supply ladder — fragment → stored (opt-in) → key service → paste as a chosen fallback, never the default; strip the fragment once read, never store without asking
- Scales with what you look at — sparse by default plus the per-path index — the claim is only honest if the interface actually behaves that way
Key ideas
- Proposing a change needs no credential on the target vault at all — the inverse of the CI problem, and the reason it is the easy case.
- More of the substrate is shipped than the briefing pack assumes: the hub is assembly, not construction.
- Branch and merge already exist client-side; the write is the only step that needs the write key.