07 — Roadmap & open questions
Summary
The build order runs from the two audits (step 0, blocking) through the public read-only forge view, the private-vault view (the step that makes it a forge rather than a gallery), the ciphertext panel, hub-as-vault, fractal navigation, and structure-key views, to issues, change proposals, discovery and scoped CI. Four absences are stated rather than deferred — cross-vault search without keys, CI, server-enforced granular permissions, content-triggered notifications — each with its reason. Open questions are split into blocking (the sub-vault decision, the web audit, storage economics), important (catalogue schema, discoverability, abuse handling on unreadable content, operational commitments), and answered since the briefing pack was written — including the measurement that content-addressed ids do not survive a rekey, so a private fork of a public template leaks nothing and no protocol change is needed.
Key concepts
- The four absences — naming them is what makes the pack credible — the same discipline as this site's where-our-approach-loses page
- Answered by measurement — two vaults holding the same document share zero object ids; a rekey turns over 100% — settling an open protocol question, and making template-diffing by identifier impossible
- Do not call components “plugins” — that word already means a capability grant in this product, and the runtime ships a deny-by-default permission model on that basis
Key ideas
- Publishing a vault is publishing a repository: once the key is out, clones cannot be recalled — the difference is that the host still cannot read it.
- Step 5, fractal navigation, is the one that turns a product into an ecosystem.
- Abuse handling on unreadable content needs a stated policy before launch: the unit of action is the vault, not the file.