RFCs

Alpha — published as written. A working document, not a specification. Nothing in it is settled and any of it can change without notice. It is published because the reasoning is part of the work, not only its result.

alpha RFC 0001 · 2026-09-28

• Status: alpha, and postponed. It will not be built before the conditions in §7 hold.
• Published at: https://mouseion.ragbaz.cc/rfc/0001
• Date: 2026-09-28
• Linked from: the roadmap, under “Postponed, with an RFC”.

Alpha — published as written. This is a working document, not a specification. Nothing in it is settled and any of it can change without notice; the sections that are still being argued about are the most likely to be rewritten. It is published because the reasoning is part of the work, not only its result: a design you cannot argue with is a design you cannot check.

1. The idea

A scroll’s id is a hex string, the first 64 bits of its publication record digest. The idea is that the id could also be an address that receives money. Whatever it receives would be split fairly:

• a share to the author;
• a share to the platform;
• and possibly a share spilling over to the scrolls it cites, so value flows back along lineage the way citations flow back in scholarship.

It fits the Mouseion well. Provenance and lineage are already in the chain, so “who made this and what was it made from” is a question the museum can answer. The hard part is the money.

2. Is it feasible?

Technically, yes, in several ways. Socially and legally, it is the hardest thing on this roadmap. Three facts shape every design:

1. A 64-bit id is not a payment address. Blockchain addresses are derived from public keys (or scripts) and carry checksums. You cannot receive money at an arbitrary hex string; nobody holds its key. So “the id is the address” really means one of two things. Either the id maps to an address (a lookup), or an address is derived from a key someone holds (custody). The design choice is who holds that key.
2. Whoever holds the keys holds the money, and the liability. If the platform derives per-scroll addresses from its own wallet, it has custody of other people’s funds. In the EU that makes it a crypto-asset service provider under MiCA, with AML obligations under the Transfer of Funds Regulation. That means KYC of recipients, which collides head-on with pseudonymous and anonymous bylines.
3. Pseudonymity is invariant 4. A real name is never connected to a pseudonym. Public payment rails are public ledgers: an author who is paid at a public address, and who later cashes out through an exchange that knows their name, has linked their pseudonym to their name forever. Whatever we build must not make the museum the instrument of that link.

3. Alternatives

4. What I would like to have

In order, each step useful without the next:

1. Support the platform first, by conventional means (option G). It is honest, simple and legal, and it asks nothing of authors.
2. Author-signed payment pointers (option A) as scroll metadata, payment with { method, address, signed_by }. The museum shows it as the author’s own claim, with the fingerprint that signed it. It carries a clear warning: a public ledger can link a pseudonym to a person. The museum never touches the money.
3. Declared splits (option B) with a small, open schema, value: { splits: [{ recipient, share, reason }] }. A recipient can be “the author”, “the platform”, or “the scroll <id>”. A split to a cited scroll resolves to that scroll’s own payment pointer at payment time, so no one holds money on behalf of a scroll whose author has not set one. Readers’ wallets do the paying. That is value for value, with lineage built in.
4. Recorded, not processed. Changes to payment metadata are chain events, like every other metadata change. So a hijacked account that swaps an address is visible, and the signature on the pointer fails to match the author’s key.
5. Optional IPFS pinning (option E), for survival, unrelated to money.

What I would not do: platform custody (C), a token of our own, or anything that pays out to pseudonyms through us.

5. The id as an address, revisited

The appealing part of the original idea, that the id is the address, can be kept as a lookup. /<id>/pay (or /.well-known/lnurlp/<id>) would resolve to the scroll’s declared splits and return a payment request that the reader’s wallet understands. For the reader it feels like paying the scroll; in fact the money goes directly to the people behind it. No one holds a key for the id, and no one needs to.

6. Risks and legal questions (not legal advice)

• MiCA and AML/KYC (EU): custody or transfer on behalf of others is a regulated service. Options A and B avoid it by design. C needs a licence or a partner.
• Sanctions: a platform that routes money must screen recipients; one that only displays addresses is in a much lighter position. Check with counsel all the same.
• Tax: income is the recipient’s matter, but the platform’s own share is revenue.
• Fraud and impostors: a copied scroll could carry the copier’s address. Signing with the author’s key, together with ids that cannot be squatted, is the defence. The museum shows which key signed the payment metadata, and whether that key belongs to the byline.
• Pseudonymity leaks: covered in §2. The museum must say so plainly wherever a payment address is shown.
• Perverse incentives: paying for citations invites citation farming. Spill-over should be the author’s explicit choice, per citation, and capped.

7. Conditions to resume

• Erasure and tombstones (m-erasure) are done, and real names are live.
• Metadata versioning (doc 01) can hold payment and value claims with their own clocks.
• Responses and citations between scrolls are in the chain (m-responses), so “the scrolls it cites” is data, not guesswork.
• A legal read on options A and B in the EU (Sweden).
• Someone wants it: at least a few authors ask for it.

8. Decision

Postponed. When it resumes, it starts with platform support (G). Then come signed payment pointers (A) and declared value-for-value splits (B), and the museum never holds anyone’s money.