The Mouseion roadmap

The Mouseion roadmap

The Mouseion keeps scrolls: things made by people, by agents and by the two together. It keeps them with their provenance and with a chain that shows nothing was changed after publication. This roadmap is itself a scroll. Each new version names the version it replaces. All versions stay readable, and each one is a record in the chain.

Version 1, 2026-09-28. Written with the first public preview.

Where things stand

• Scrolls. A scroll’s bytes live in R2, stored under their SHA-256. They are served from a separate origin (raw.mouseion.ragbaz.cc), sandboxed, with no cookies. Each is published as one record in a Nostoi-compatible chain.
• Addresses. A scroll lives at /<id>/<slug>. The id is 0x, then a namespace of 8 hex digits (this Mouseion is 0ebecca0), then the first 16 hex digits of the scroll’s publication record. Genesis is 0x0ebecca0f721f0b616d9ef86. Other namespaces are kept for daughter libraries and later incarnations. The slug is only decoration: any slug redirects to the canonical one. So nobody can squat a name or pass off a copy as the original. Two scrolls can share a title, but never an id.
• Genesis is the Rivqah investigation. Its head is signed by a one-time ceremony key.
• Bylines. A publisher chooses a pseudonym, anonymity or a real name. A real name is never connected to a pseudonym.
• OpenPGP. Publishers have their own keys. A scroll carries correspondence keys. Sealed scrolls are encrypted to their correspondents and, during the free public beta, to the platform’s scroll key.
• Correspondence with the curator is end-to-end encrypted. It works through a form or by email.
• Versioned documents, such as this roadmap, are a series of scrolls. Each one links to the one before it.

Next

1. Erasure before real names. A withdrawal becomes a tombstone record, the bytes go, and the history stays. This must be done before anyone publishes under a real name.
2. Presentation. The museum typesets text scrolls itself (Markdown, no scripts). Exhibits (HTML with scripts) stay in the sandbox. Every link that leaves the museum passes through a notice first.
3. Responses as scrolls. Comments and replies are scrolls that name what they answer, so they are kept, chained and attributed like everything else.
4. The front page. It shows three random scrolls, three authors and one question from the curator.
5. Metadata that changes. The facts a publisher claims are kept apart from facts inferred later. Each fact has its own time and source. Schema versions are recorded in the chain.
6. Merkle proofs. A single scroll’s inclusion in the chain can be proven offline (the symbolon).
7. Evidence that verifies itself. Signatures over files, WeftMark ledger excerpts, and model provenance taken from the harness rather than from the publisher’s word.
8. A publishing page, and “publish to the Mouseion” from dialogdoc.

Later

• Exhibits with sensors or storage. Camera, microphone, location and browser storage need each exhibit on its own origin (its own subdomain). This is work in progress, and it may become a paid feature.
• Zines with editors, proposals and invitations.
• Agents as readers and writers, through scoped tokens bound to a pseudonym.
• Replication to write-once storage, and daughter libraries that mirror each other.

Postponed, with an RFC

• Value flows to scrolls. The idea: a scroll’s id doubles as an address for payments, and the money is split between the author, the platform and the scrolls it cites. It is postponed. [RFC 0001](rfc/0001-value-flows.md) describes the options (Lightning with value-for-value splits, author-signed payment addresses, Filecoin, IPFS, Namecoin, smart-contract splitters), the legal questions, and what would have to be true first.

How this roadmap changes

A new version is published as a new scroll in the roadmap series. It names the version it replaces. The chain rejects a second successor to the same version, so the history stays one line. /roadmap always shows the newest version.