Inline-Kommentare auf einer Textstelle (Quote-Anker)

[usekaneo]

Kommentare (kind 1111) hängen an der Seite (group, slug), nicht an einer Stelle im Text. Ein Kommentar zu einem markierten Absatz — in einem Wiki der Normalfall — ist nicht möglich.

Aufgabe: Anker auf einer Auswahl (Quote plus Positionsangabe, robust gegen spätere Edits — Zitattext statt reiner Offsets), Markierung im gerenderten Text, Anzeige in der rechten Spalte. Braucht eine Selection-API im Editor, also CodeMirror — die Voraussetzung ist inzwischen erfüllt.

Quelle: docs/02-data-model-events.md („Open: inline comments on a text selection")

---

_{Task: p42mxl4vw0e8a1l5scrcihnz}

[usekaneo]

CON-18

[usekaneo]

**** commented:

Technical refinement

Status: ready to design, but the anchoring is the hard part, not the commenting. The productive entry point is the editor (CodeMirror gives exact source offsets); rendering the mark back into the read view is the part that needs care.

What exists today

• Comments are NIP-22 1111 anchored to (h, d) only (src/domain/comment.ts), published by publishComment (src/nostr/publish-comment.ts) with K/k/e and p tags. The thread renders as bands under the page (src/ui/Comments.tsx), in PageView below the article (src/routes/PageView.tsx:191).
• Replies use e for the parent comment. So e is taken and must not double as an anchor tag.
• The editor is CodeMirror 6 (src/ui/MarkdownEditor.tsx), which has EditorSelection and state.sliceDoc(from, to) — the prerequisite the ticket mentions is met.
• The read view renders with react-markdown + remark-gfm + rehype-sanitize; no source positions are carried into the DOM today.
• docs/02 lists inline comments as Open; docs/06 already has a right rail (the TableOfContents in AppShell).

Anchor model

1. Store text, not offsets. An anchor is { quote, prefix, suffix, revId }: the exact selected text, a few characters of context on each side, and the revision the selection was made against. Offsets may be stored as a hint but never as the truth — the next edit invalidates them.
2. Tags (all new, in kinds.ts): quote, quote-prefix, quote-suffix, anchor-rev. Reusing e for the anchor is not possible, because e already carries the parent comment on a reply.
3. Resolution (src/domain/anchor.ts, pure and tested): given the head content, find all occurrences of quote, prefer the one whose surrounding text matches prefix/suffix, fall back to the occurrence nearest the stored offset hint, and return null when the quote is gone. null is a valid, displayable state ('the quoted text is no longer in the page'), not an error.
4. Comment type grows an optional anchor. A page-level comment (today's behaviour) simply has none; replies inherit the thread, not the anchor.

Producing an anchor (editor)

5. In MarkdownEditor, expose the current selection as { from, to, text } via a callback/ref (the shim already imports EditorSelection). PageEditor adds a 'Comment on selection' action in the formatting toolbar, enabled only for a non-empty selection and when signed in.
6. The action opens the comment composer (reuse the Comments composer rather than a second one), pre-filled with the quote, and calls publishComment with the anchor tags; revId is the base revision the editor was opened on, so the UI can later say which version the quote came from.

Marking in the read view

7. Block-level marker (first iteration, recommended). Resolve each anchor to a range in the head and mark the block (heading, paragraph, list item) that contains it: a small gutter badge with the comment count. Cheap, safe with sanitisation, and enough to make 'there is a comment on this paragraph' visible. It requires mapping a text range to a rendered block — doable with a remark plugin that tracks positions.
8. Inline highlight (follow-up). A remark plugin can walk the AST text nodes (they carry position.start.offset/end.offset), split nodes at the anchor boundaries and emit a custom marker element, which a components override in src/ui/Markdown.tsx renders as a clickable <mark data-comment-id=…>. This uses source offsets directly and avoids DOMsource mapping entirely. The cost is a plugin with real tests around multi-node quotes (a quote spanning emphasis, a link or a code span).
9. Right rail. Put anchored comments in the app's right rail next to the TableOfContents (a section or a second tab), showing quote, author and text, clicking scrolls to the marker and opens the thread; clicking a marker focuses the rail entry. Keep page-level comments where they are, below the article. Do not duplicate a comment in both places without a clear rule.

Subtasks

• kinds.ts anchor tags + Comment.anchor + parseComment/publishComment support
• src/domain/anchor.ts: resolve quote/prefix/suffix against head content (pure, well tested)
• MarkdownEditor selection accessor + PageEditor 'Comment on selection' action
• Block-level markers via a remark positions pass (first iteration)
• Right-rail inline-comments section, linked to markers
• Orphaned anchors rendered honestly (quote shown, no highlight)
• Docs: docs/02 closes 'Open: inline comments', docs/06 right-rail entry

Acceptance criteria

• A selection in the editor can be commented on; the comment stores quote and context, never only offsets.
• A quote that still appears in the page is highlighted (or at least marked at block level) and reachable from the right rail.
• A quote removed by a later edit shows as orphaned with the original quote, and the app never highlights the wrong occurrence silently.
• Replies to an anchored comment stay in its thread; page-level comments are unchanged.
• No rendered foreign HTML; the marker element is ours and survives rehype-sanitize.

Risks / open decisions

• Anchor drift is the core risk; the prefix/suffix plus a 'made against revision X' note must make a wrong match unlikely and detectable.
• Quotes spanning inline markup are the tricky case for the remark plugin; scope the first iteration to quotes within a single text node and mark the rest as block-level.
• Comments are still anchored to (h,d), not to a revision; the anchor's revId is provenance, not identity. Do not turn it into a hard reference.
• Right-rail capacity on narrow screens: the rail already hides responsively; a mobile fallback (a badge that scrolls to the comment) is required.

Depends on / relates to

docs/02 (comments), CON-11 (tombstoned pages must not show stale markers), CON-8 (cached comments resolve anchors the same way).