id: design: Chat next steps — conversation↔object linking, talk pages, terminal participation #5682

Extends #2051 (ID chat v1) and #2036 (ID messaging/relay protocol). This is an EXPANSION design: chat v1 exists; these are the next steps that connect chat to everything else in ID — objects, boards, notes — so discussion lives with the thing being discussed.

Problem

Standalone chat silos conversation away from the objects it is about. In ID, the interesting conversations are about notes, boards, files, programs, and other objects — and they happen from every client, including a terminal. v1 chat (#2051) over the protocol in #2036 does not yet define: how a conversation anchors to an object, how someone in a terminal takes part in an object's discussion, or what a "talk page" for an object is. This design does.

Feature set — full expansion

1. Conversation ↔ object linking

• Any conversation/thread can be anchored to an object: a note, a board, a post, a file, a program, another chat message, or any addressable ID object. Anchoring is a first-class link in the data model, not a pasted URL.
• Link types: about (thread discusses the object), anchored-to-part (thread attaches to a range/section/block/region of the object — a paragraph of a note, a cell, a timestamp in media, a post on a board), derived-from (thread forked/spun out of another conversation about an object), resolved-into (discussion produced an edit/decision on the object — link both ways).
• Bidirectional navigation: from the object, see its conversations; from the conversation, jump to the exact anchor in the object.
• Anchor survival: what happens to anchors when the object is edited (anchor re-location by content fingerprint, drift warnings, orphaned-anchor state), versioned, or deleted (tombstoned anchor, conversation preserved).
• Permissions: a conversation about an object inherits or restricts read access how? A thread anchored to a private object must never leak the object's content (or its existence, per policy) to non-readers; define thread visibility = intersection/owner-choice rules and the UI warnings that enforce them.
• Cross-object threads: one conversation anchored to several objects (comparing two notes; a board post + the note behind it).

2. Talk-page semantics per object

• Every object gets a discussion surface — its talk page (the notes/board design theme carried across ID: discussion is a property of objects, not a separate app). This section defines the semantics once, for all object types, linking the knowledge-layer (id: design: Zettelkasten layer — multiplayer docs/wiki on ID #2048) and boards designs rather than re-inventing per-type discussion.
• Talk page model: one canonical discussion space per object (with threads inside it), living alongside the object, sharing its identity and its read-authority unless explicitly overridden.
• Relationship to chat: a talk page is a chat conversation (same protocol, id: design: ID messaging/relay protocol v1 #2036; same client machinery, id: design: ID chat v1 #2051) with a permanent object anchor — not a second messaging system. Chat clients open talk pages; object views embed them.
• Talk-page lifecycle: created lazily on first discussion or eagerly per object (decide, with storage/privacy implications); archived with the object; follows object ownership transfers; moderation follows the object's moderation context (link boards moderation / id(world): F14.6 builder and moderator authority through session frames (F12.3 remainder) #835 where applicable).
• Talk-page conventions: threads per topic, resolution markers (a thread can be marked resolved, and resolution can link the resulting object edit — see resolved-into above), pinning, and slow/announcement modes for high-traffic objects.
• Notifications: object owner/watchers notified of talk activity with per-object mute/watch levels.

3. Terminal-viable participation in object discussions

• Full participation from a terminal is a requirement, not a degraded fallback: read talk pages and anchored threads, post/reply, resolve threads, follow anchors to objects (rendered textually), and get notified — all from a TUI/CLI client.
• Rendering rules for the terminal: object anchors render as readable references + textual previews; rich embeds/playable objects degrade to described fallbacks (link boards' fallback model); threads render as indented/plain-text trees without loss of structure.
• Authoring in terminal: quoting an object part creates an anchor (select-by-reference: object ID + range/section identifier, resolvable without a GUI); editor integration ($EDITOR composition), and offline compose/queue over id: design: ID messaging/relay protocol v1 #2036's store-and-forward paths.
• Accessibility overlap: the terminal model doubles as the screen-reader-friendly model — semantic structure (thread, anchor, resolution state) must survive text rendering intact.

4. Supporting design points

• Search: discussions searchable by object, by anchor target, and by content — always respecting both conversation and object permissions.
• Presence/typing/read-receipts on talk pages: same rules as id: design: ID chat v1 #2051 chat, plus object-context presence ("3 people viewing this note" vs. "in its talk page").
• Migration/compat: existing v1 conversations gain anchors retroactively (paste-a-link → recognised anchor upgrade); no v1 conversation is orphaned by the new model.
• Protocol impact on id: design: ID messaging/relay protocol v1 #2036: anchor/talk metadata as message/envelope extensions — list what id: design: ID messaging/relay protocol v1 #2036 must carry (anchor records, thread-object bindings, resolution state) and what stays application-layer.

Decomposition sketch

Follow-on design tickets to be filed from this issue:

1. Anchor data model: link types, part-anchors (ranges/blocks/regions), anchor survival under edit/delete.
2. Talk-page semantics: per-object discussion surface, lifecycle, permissions vs. object read-authority.
3. Chat ↔ talk-page unification on id: design: ID messaging/relay protocol v1 #2036/id: design: ID chat v1 #2051: protocol extensions, retroactive anchoring of v1 chats.
4. Terminal participation design: TUI/CLI flows, textual anchor rendering, offline compose.
5. Thread resolution & discussion→edit loop (resolved-into links, change proposals from threads).
6. Notifications, watch/mute, presence for object discussions; search across anchored conversations.

Open questions

• Talk pages: lazily created on first post, or present (empty) on every object from creation — and what does an empty talk page cost at ID's object scale?
• Thread visibility when participants have differing access to the anchored object: intersection, object-owner-decides, or thread-owner-decides with warnings?
• Anchor drift: how hard do we try to re-locate anchors after heavy edits before declaring them orphaned?
• Can a talk page itself be anchored/discussed (talk pages all the way down), and where do we cut recursion?
• Terminal clients: is a dedicated TUI in scope, or is the deliverable a CLI + protocol guarantee that a TUI can be built against?
• Moderation of talk pages: object owner's rights vs. server moderation (id(world): F14.6 builder and moderator authority through session frames (F12.3 remainder) #835) — who can close/lock a talk page?

Program note: expansion-style design — a later pass breaks this into the follow-on design tickets above, then implementation tickets. Relatives: #2051, #2036; discussion theme links the knowledge layer (#2048) and boards designs.