01 — The model, and the fractal
Summary
The model is settled: a forge whose application layer runs in the browser — the client decrypts, the server is object storage plus a small interface and reads nothing; the reference class is a self-hostable forge, with the claim that the server can be storage rather than an application. The fractal is the new part, and its virtue is that it is not a new mechanism: the catalogue lives in a vault and publishing is a folder copy, so a hub is just a vault containing a cover, a catalogue and a loader — and nothing stops a catalogue entry pointing at another hub. Navigating the network is client-side graph navigation; federation needs no federation protocol. A hub can be a useful index of things it cannot read: private vaults are listed, described and requestable — and still opaque.
Key concepts
- A hub is a vault — cover + catalogue + loader; every edge in the network is the same operation the client already performs — open a vault
- The fractal as adoption strategy — a community cannot adopt a platform it must be granted access to; it can adopt a format — a hub costs a bucket and a publish, and forks are unlinkable
- Trust does not compose — hub A listing hub B is not an endorsement; provenance (who listed this, when, what they verified) is a catalogue field, not an emergent property
Key ideas
- The fractal needs exactly three things: a catalogue schema with kind: vault | hub, a cover schema, and a loop guard — no consensus, no registry, no server-side crawl.
- The shape of the estate is disclosed regardless: a hub is a public statement that these vaults exist — the stated exception travels with the claim.
- Stale pointers are the failure mode: an intermediary cannot forge content, but it can serve last week's — surface the head's age.