Wayfinder: notes on boop — signed, publishable, verifiable #227

Destination

boop grows a notes surface where a note is a list — same lists table, same assetDid/listEnvelopes identity, same publish path — carrying prose instead of items. Cloud-native: notes live in Convex, not as files on disk.

Shipped means: a stranger lands on a published note and can confirm who wrote it and that it has not been altered since. Provenance is the product, not the editor.

Notes

Domain: boop — Convex (realtime DB + HTTP actions), React 19 + Vite + TS + Tailwind v4, Originals SDK for DIDs (did:webvh, did:cel) and VCs. Relevant existing machinery: lists (assetDid, vcProof), listEnvelopes (signed CEL event log), items, publications / sites / siteDidLogEntries (signed publishing), subscriptions + list cap, presence / comments / activities.

Skills every session should consult: /grilling and /domain-modeling by default; /prototype for the prototype tickets; /research for research tickets.

Standing preferences for this effort:

• Plan, don't do. These tickets resolve decisions; the build is a separate handoff.
• A note is a list. Reuse the primitive — do not introduce a parallel data model. If a ticket's answer requires a new primitive, that's a signal to re-examine the destination, not to quietly add one.
• Provenance is the wedge. When a decision trades editor polish against verifiability, verifiability wins.
• This audience is not Obsidian's local-first users. They were consciously given up when cloud-native was chosen; do not re-litigate it per ticket.

Decisions so far

• How does CEL handle a large, frequently-mutated text field? — events commit by hash (~720 B each), but the envelope stores every version's content inline forever; a 20 KB note passes Convex's 1 MiB limit after ~50 seals, so old versions must go hash-only. The log can't be compacted.
• Where does a note's prose live in the lists model? — prose only, one markdown body; its own resource in the signed asset from genesis; live body in a separate table; notes are born notes (no converting lists); reuse the existing NoteEditor.
• What does a note's signature commit to, and when does it seal? — sealed on publish only; the latest version's text stays inline in the envelope, older versions keep only a hash with their text in the bucket by sha256; keys moved to their own ticket.
• Does a note consume list quota? — notes are uncapped and don't count toward the 5-list cap; publishing a note is the paid action (new gate in publishList).
• How does a note get published — reuse publications/sites, or note-specific? — reuse publications with the list DID shape, not sites (custodial keys); served at a path on boop.ad, no per-note hostname; strangers see the last sealed version until re-publish; publishing grants the same anyone-can-edit access as lists, so sealing others' edits under the author's key is an open follow-up.
• Where does a note's signing key live so the author can seal from any device?: the author's Turnkey key controls their did:webvh; per-device and agent keys registered there sign actions and seals (verifiers check the key was valid at seal time); 7-day client sessions, no step-up; all existing assets are re-genesised; implementation in Move signing to author-present Turnkey sessions and delegated agent keys #286, which also blocks Sign action records with owner Turnkey keys through one shared path #277.

Not yet specified

• Concurrent / multiplayer prose editing. presence and comments exist for lists, but concurrent prose is a different problem than concurrent item rows. Revisit once sealing granularity is settled.
• Import from an existing Obsidian vault. Whether a migration path exists at all, and what it costs, once the note shape is known.
• Mobile note-writing. A Capacitor app exists; unknown whether notes need it at ship.
• Whether publishing lists also becomes paid, for consistency with notes, and the upgrade message when publishing a note hits the gate.
• Discovery of published notes. SEO, indexing, whether published notes are listed anywhere.

Out of scope

• Local files / local-first sync. Cloud-native was chosen deliberately; notes live in Convex.
• Notes as a separate primitive — own table, own DID lifecycle, own editor stack.
• Graph view, backlinks, wiki-links. This is where "Obsidian replacement" becomes literally true and the surface becomes its own product.
• Plugin ecosystem.
• Winning Obsidian's local-first users. Different audience, consciously not pursued.