feat(relay): index reactions under their target author for #p reads - #9285

Why

buzz-app's Activity → Reactions tab (block/buzz-app#2638) finds reactions to your messages with {kinds:[7], "#p":[you]}. A reaction shows up there only if the client that sent it tagged the message author (p, per NIP-25). Today buzz-app and its MCP tool do this. Mobile does it since #9141 (merged); the CLI change is #9121. Agents and third-party clients may never do it. With this PR the relay works out the recipient from the reacted-to message, so the tab works for reactions from every client.

What

• When the relay stores a reaction, it now also indexes the reacted-to message's author as a #p recipient. That author is the message's effective author: the actor (or leading p) for relay-signed messages, otherwise the signer. The relay looks up the target message during ingest; it never reads the author from the reaction.
• #p reads and COUNT return those reactions to the message author, whether the filter has one #p value or several. Nothing is added to the signed event, so clients receive exactly what was sent.
• Derived recipients apply to kind 7 only. Old p index rows for other kinds stay hidden, as they are today (fix: don't notify workflow owners through their attribution tag #8694).
• scripts/maintenance/backfill_reaction_target_mentions.sql repairs reactions stored before this change, under docs/database.md Rule 3:
  • walks stored kind:7 events, so reactions with no reactions.reaction_event_id link are covered
  • batches of 5,000
  • takes the community-deletion lock
  • idempotent, with a validation query
  • Run it once this relay version is fully deployed.
• New counter buzz_relay_reaction_recipient_derived_total{outcome} with outcomes inserted, duplicate and fallback_pubkey.
• NOSTR.md kind 7 now notes the derived recipient. Clients should still tag p, per NIP-25.

Design: relay-derived reaction recipients (slices 1, 2, 4 and the block/buzz docs). The buzz-app side is block/buzz-app#3115. The Activity reactions tab this serves is block/buzz-app#2638.

Testing

• Matcher (unit): #p matches a derived recipient with no p tag. It does not match when there is none or it is a different pubkey. Literal p tags still match, and the #h fallback is unchanged.
• Postgres (via ingest, REQ and COUNT):
  • An untagged reaction is returned to the message author and not to the reactor.
  • A relay-signed message with actor resolves to the actor.
  • A reaction that also tags p produces exactly one index row.
  • COUNT matches REQ.
  • A two-value #p REQ and COUNT return the same reactions as a single-value read.
  • Kind-7-only matching is guarded by its own test.
  • Each test fails without its change. Mutation checks turned the tests red when the derived insert was skipped, when the raw signer was used, when the kind-7 restriction was dropped, and when the multi-value #p recipient load was skipped.
• Backfill against local Postgres: 12,005 seeded reactions covered user-signed, relay-signed (actor / p / neither) and soft-deleted targets.
  • The first run inserted 12,009 rows; the second inserted 0.
  • The validation query returned 0 after both runs.
  • After walking events directly: a reaction with no source-event link was indexed under its target's author, the last valid e tag chose the target, a soft-deleted target was skipped, and a batch size of 1 paged through reactions sharing one timestamp without gaps. Rerun inserted 0; validation returned 0.
  • A quiescing community was untouched.
  • A missing or invalid relay_pubkey_hex exits before writing anything.
• Checks:
  • cargo fmt --check and cargo clippy --workspace --all-targets -D warnings pass.
  • cargo test passes for buzz-core, for buzz-db (unit tests plus the Postgres tests for event, reaction and feed), and for the buzz-relay handlers and subscription modules.
• Not run:
  • 2 cluster_global_* relay Postgres tests. They need a database role with CREATEROLE, which the local buzz role lacks; Docker isn't available here.
  • The relay Postgres suite in parallel. It interferes with itself on one shared database; run serially, everything else passed.
• Not yet done: a human test against a running relay.

Known limits

• Across relay nodes, a live #p + #h subscription on another node does not receive untagged reactions: the Redis fan-out rebuilds the event without the derived recipient. buzz-app subscribes by #h only, so Activity is not affected.

Rollout (docs/database.md Rule 3 order)

1. Deploy the relay write path. New reactions are indexed from then on. There is no flag; the change only adds index rows.
2. Once every older relay is drained, run scripts/maintenance/backfill_reaction_target_mentions.sql, passing relay_pubkey_hex. Its validation query (stored reactions with a live target but no index row for the target's author) must return 0. Re-run the script if it doesn't: it is idempotent.
3. Ship feat(activity): show reactions that omit the viewer's p tag buzz-app#3115. Until it ships, buzz-app still requires the literal p tag.

Rollback: revert the relay. The extra index rows are inert, because the previous binary's re-check drops them.

🤖 Generated with Claude Code