id: design: ID notes, message board, and multiplayer editing v1 #5677

Summary

ID's notes (zettelkasten layer, #2048), its chat (#2051), and its boards (#2054) should form one connected knowledge surface instead of three silos: a note can be shared into a board as a post, discussed there, edited multiplayer-style, forked by anyone who can see it, and navigated as a graph — equally by humans, scripts, and agents. This design expands that connective tissue into a full feature set: note↔board flow, native graph navigation, multiplayer editing, the edit/fork graph with per-object talk pages and changelogs, an approval flow, personalized search ranking, and user sovereignty over edits.

Relates: #2048 (extends its zettelkasten/notes layer), #2051 (ID chat — conversations referenced here include chat/board threads), #2054 (boards — the message-board surface notes are shared into).

Feature set (expanded)

1. Notes ↔ message board

• Share a note into the board: search your notes, pick one, and post it to a board with the note embedded in the post (live reference, not a pasted copy — state what happens when the note later changes: post reflects current note, the version at post time, or both views available).
• Replies reference the note: replies in the thread are anchored to the note (and optionally to a passage/section of it), so the discussion is structurally about the note, not just adjacent to it.
• Backlinks / jump-through: from the note, see every board conversation (and chat thread, per id: design: ID chat v1 #2051) that references it, and jump to the full conversation; from a post, jump to the note. Two-way, always.
• Cross-board and cross-server behavior: what happens when the note and the board live on different servers/peers (compose with selective sharing grants).

2. Native graph navigation

• The note↔post↔reply↔edit relationships form a queryable graph, native to ID — not a UI-only feature.
• Parity for scripts, agents, and humans: the same graph traversals (references, backlinks, conversation-for-note, edit-history-for-object) are available via CLI, scripting/API, and agent surfaces with identical semantics.
• Graph operations in v1: neighbors, backlinks, threads-for-object, history-for-object, and path queries if cheap — each with pagination and result-shaping consistent with the ID query design.

3. Multiplayer editing

• Edit sessions (Google-Docs-like): multiple people editing one note/object concurrently, with live presence (who is in the session, where they are editing) and conflict-free merged results (CRDT-class semantics; the design names the merge model and its limits).
• Terminal form: a limited but real multiplayer session from the terminal — see co-editors, follow changes, make edits — not a view-only afterthought.
• Join/view permissions: sessions can be open to anyone who can see the object, restricted to a named set, view-only for some and edit for others; session host controls and how they compose with object ownership.
• Session lifecycle: start, invite/link, idle/end, and what persists after (the session itself becomes part of the object's history).
• Offline/async editing: edits made outside a live session merge by the same rules when reconnecting.

4. The edit/fork graph

• Every object has an edit/fork graph: who edited what, which versions diverged from which, and how forks relate — viewable as a divergence view (side-by-side lineage, what changed where).
• Mark-most-correct: a community/owner mechanism to mark one lineage/version as the currently most-correct — a signal layered on the graph, not a deletion of alternatives.
• Talk page per object: wiki-style discussion page attached to every object (distinct from its content), for debating edits, correctness, and merges.
• Changelog per object: a complete, inspectable changelog — every edit, fork, mark, and approval, attributed and timestamped.
• Merge proposals: a fork can propose merging back; the graph records proposal, discussion (on the talk page), and outcome.

5. Draft → approval flow

• Edits can land as drafts requiring owner/admin approval before becoming the object's effective version — per-object or per-collection setting.
• Approval UX/model: who approves (owner, named admins), approval queues, approve/reject/request-changes, and what happens to the draft author's copy in each case (a rejected draft remains the author's fork — it is not deleted).
• Objects/collections that don't enable approval stay friction-free: edits are immediate. The flow is opt-in governance, not a global gate.

6. Personalized search ranking

• A searcher's own edit ranks first in their own results: when you search, your own version/fork of an object surfaces first for you — your view of the world leads, without changing anyone else's ranking.
• Ranking inputs beyond that (most-correct marks, recency, graph proximity) are stated and ordered; ranking is per-searcher and explainable ("shown first because it's your edit").

7. User sovereignty (foundational rule)

• Anyone can fork/edit any object they can see. No permission needed to make your own version; visibility is the only gate.
• Every such edit is recorded attributably: "user N edited this page to look like this" — provenance is part of the object graph, never anonymous or overwritten.
• Effective authority is social, not enforced: the relevant community may track a fork into effective authority (adopt it, mark it most-correct, approve it) — or ignore it as graffiti. Both outcomes are first-class; the system records, the community decides.
• Consequences stated plainly: owners cannot prevent forks of visible objects, only decline to adopt them; hiding requires not sharing visibility in the first place (compose with selective sharing). Spam/graffiti controls (ranking demotion, per-user filters) operate on visibility/ranking, never by erasing attribution/history.

Non-goals (v1)

• A rich WYSIWYG editor — terminal and API parity come first; rich rendering is a later layer.
• Global/single canonical truth across communities — authority is per-community by design (see sovereignty).
• Deleting history: takedown/erasure policy for illegal content is a separate design and must be reconciled with the changelog's append-only promise explicitly, not silently.

Acceptance for this design

A follow-on reader can break this into the decomposition tickets below without re-deciding: the note↔board reference model, the merge model, the sovereignty rule, or the approval flow's shape.

Decomposition sketch

1. Design: note→board sharing (embedded live reference, version semantics, reply anchoring, backlinks/jump-through, cross-server case).
2. Design: native graph model & navigation API (traversals, parity across CLI/script/agent, pagination).
3. Design: multiplayer edit sessions (merge model, presence, terminal form, join/view permissions, session lifecycle).
4. Design: edit/fork graph (divergence view, mark-most-correct, merge proposals).
5. Design: per-object talk page + changelog (data model, attribution, append-only rules).
6. Design: draft → owner/admin approval flow (queues, outcomes, rejected-draft-as-fork).
7. Design: personalized search ranking (own-edit-first, explainability, graffiti demotion without erasure).

Open questions

• Embedded note in a post: live reference, pinned version, or both — and what does a reply anchor to when the note changes under it?
• Merge model for multiplayer editing: which CRDT/OT approach fits ID's data model and offline-first assumptions?
• Terminal multiplayer: how much presence/awareness is feasible and useful in a TUI session?
• Mark-most-correct: who may mark (owner, board admins, community vote), and can marks conflict across communities — if so, how are they displayed?
• Approval flow defaults: opt-in per object, per collection, or per board — and who can flip the setting?
• Search ranking: how strongly does own-edit-first outweigh most-correct marks from the community?
• Graffiti/spam at scale: what ranking/filter tools do readers get, given history itself cannot be erased?
• How do chat threads (id: design: ID chat v1 #2051) and board threads (id: design: ID boards v1 #2054) unify as "conversations referencing a note," or do they stay distinct types?