fix: don't render Marmot reactions/deletions as chat bubbles

WhiteNoise threads its kind:445 payloads across three inner kinds:
kind:9 for chat, kind:7 for emoji reactions, kind:5 for unreacts. The
Amethyst ingest pipeline was routing every inner event into the group
chatroom feed, so a kind:7 reaction rendered as a chat bubble whose
only content was the emoji, quoting the liked message via the target
`e` tag. That looked identical to a threaded reply. The actual kind:9
reply from `wn messages send --reply-to` never arrived, which made the
two look swapped in the UI.

Three changes to untangle this:

- MarmotGroupList.addMessage/restoreMessage now skip inner events with
  kind:5 and kind:7 before they enter `MarmotGroupChatroom.messages`.
  The reaction is still consumed by LocalCache so it attaches to the
  target note's reaction row, and the deletion still revokes that
  reaction — they just don't appear as standalone bubbles.
- LocalCache.computeReplyTo learned to derive thread parents for
  `ChatEvent` (kind:9) from plain NIP-10 `e` tags in addition to the
  existing NIP-18 `q` tag path. WhiteNoise emits `e`-tagged replies;
  without this the reply bubble had no quote context in the feed.
- tools/marmot-interop/marmot-interop.sh: `wn messages send` exposes
  its `reply_to` field through clap v4, which renames snake_case to
  kebab-case by default. The script was passing `--reply_to`, which
  clap rejected; the `|| true` + redirected stderr hid the error and
  no reply was ever published. Use `--reply-to`.

https://claude.ai/code/session_01K3g1uWLhByoEdBS77zdF32
This commit is contained in:
Claude
2026-04-22 22:07:15 +00:00
parent 6c214b8c13
commit c4e7e0d9b4
3 changed files with 44 additions and 1 deletions
+5 -1
View File
@@ -776,7 +776,11 @@ test_09_reply_react_unreact() {
fi
step "B replies to the anchor"
wn_b messages send "$gid" "replying via wn" --reply_to "$msg_id" >/dev/null 2>&1 || true
# clap v4 converts snake_case fields to kebab-case flags by default, so the
# `reply_to: Option<String>` field on `wn messages send` exposes as
# `--reply-to`. Passing `--reply_to` is silently rejected (the script's
# `|| true` hides the error) and the reply is never actually published.
wn_b messages send "$gid" "replying via wn" --reply-to "$msg_id" >/dev/null 2>&1 || true
sleep 3
if confirm "Does Amethyst show 'replying via wn' as a threaded reply to the anchor?"; then
record_result "09 reply/react" pass