feat(workflow): let workflows add reactions to messages

[BradGroux]

Fixes #2395.

What changes

Workflow add_reaction actions now publish a signed kind-7 reaction against the triggering message through the existing relay event path.

The reaction includes:

• the target event e tag;
• the target event kind k tag;
• the target author's p tag required by NIP-25 clients and Buzz's author-targeted push subscription;
• the workflow owner as the signer.

The sink resolves the effective target author through the same attribution helper used by ingest, so reactions to agent-authored messages target the actual author rather than a relay signer. Duplicate execution remains idempotent. The relay-backed regression now subscribes to the reaction by its actual kind-7 and e-tag shape, while the follow-up message retains its channel-scoped filter.

Safety and scope

• No public reaction REST endpoint is added.
• Desktop and mobile rendering are unchanged.
• Manual workflow triggers still cannot use add_reaction because they have no triggering message ID.
• Custom emoji metadata remains limited to the action's existing reaction-content field.

Verification

• cargo fmt --all -- --check
• cargo clippy -p buzz-workflow -p buzz-relay -p buzz-test-client --all-targets --all-features -- -D warnings
• cargo test -p buzz-workflow -p buzz-relay -p buzz-test-client --no-fail-fast: workflow and test-client suites passed; the unprovisioned relay run reached only the existing database-dependent failures.
• cargo test -p buzz-relay workflow_sink::integration_tests::workflow_add_reaction_persists_attributed_kind_7_and_dedupes -- --ignored --nocapture: passed against PostgreSQL and Redis.
• just test: all nine unit/package/database stages passed. The workspace integration stage reproduced the unrelated buzz-agent timing failure steer_folds_into_active_turn_without_cancelling; that test passes in isolation, and this branch does not modify buzz-agent.

This refresh is not production deployment evidence.

[BradGroux]

I rebased this branch onto current main and checked the emitted reaction against the consumers that now exist there.

The feature is still relevant, but the old branch omitted the target author's NIP-25 p tag. That was not just metadata polish: Buzz's current author-targeted push subscription uses the p tag, so workflow reactions could be stored and rendered while failing to notify the target author.

Head d2c7a8343d03b94f799dec12c60a0e051becfdf5 resolves the effective author of the triggering event, adds the signed target-author p tag, and preserves the existing deduplication path. The regression now asserts the e, k, and p tags together.

The affected package suites, strict Clippy, and Rust formatting were refreshed. The non-database tests passed. Nine unrelated relay media/admin tests could not obtain this host's local PostgreSQL pool, and a serial rerun hit the same boundary. The new ignored PostgreSQL regression compiled, but I am not presenting the unavailable database run as passing evidence.

[BradGroux]

Rebased this branch onto current block/buzz main at c55e421a0.

Head moved from cad2b5364 to 7f905a532. git range-diff shows the add_reaction relay-sink patch is unchanged, and the branch now has a direct merge base with current main.

Verification:

• The full buzz-workflow suite passed: 153 tests passed and 2 remained explicitly ignored.
• All 17 relay workflow-sink tests passed; 1 Postgres-backed test remained explicitly ignored.
• The workflow-actions E2E target compiled and remained explicitly ignored because no relay service was running.
• git diff --check, DCO trailer checks, and the direct merge-base audit passed.

GitHub checks are rerunning on the new head.

[BradGroux]

Rebased onto current block/buzz main at b1b283cd4 and rechecked the branch against #2495 and #2634. #2494 remains the focused submission for #2395: #2495 bundles unrelated Desktop transport work, while #2634 explicitly excludes workflow reactions.

The rebase audit found one test defect rather than a production-path defect. The relay emits the kind-7 reaction with its target e tag but no channel h tag; the ignored E2E subscribed with both, so it could never observe the actual event when enabled. The regression now uses separate filters for the reaction's real event shape and the channel-scoped follow-up message.

Published head: 1a4f5bd833c417085ef2f6edff2e92047276d94d.

Verification passed for formatting, strict Clippy across the three affected packages, and the PostgreSQL/Redis-backed kind-7 persistence and deduplication regression. The repository just test gate passed nine stages before reproducing the unrelated buzz-agent timing failure steer_folds_into_active_turn_without_cancelling; that test passes in isolation, and this branch has no buzz-agent diff.

[BradGroux]

Rebased onto block/buzz main at ce3cf3cd2591f132f286fbc0a42a9e6699d0b08d and rechecked the workflow action against current relay ingest, NIP-25 consumers, issue #2395, and competing work.

The PR remains valid. Current main still sends add_reaction to the nonexistent /api/messages/{id}/reactions route instead of publishing a signed kind-7 event. #2495 is a broader bundle that includes unrelated Desktop transport work, and #2634 covers other reaction producers rather than workflow reactions. Neither supersedes this focused relay-sink implementation.

The rebase was clean. The existing correction remains necessary: the workflow reaction carries the target event's e and k tags plus the effective target author's p tag, preserving NIP-25 attribution, author-targeted notification, and idempotent execution. No further production-path change was needed.

Exact-head verification on 8cd7bc6e917fbd4ede6ca572aee1c39b9bdbd732:

• Full buzz-workflow suite passed: 153 tests, 0 failures, 2 explicitly ignored.
• buzz-test-client unit coverage passed, and its ignored integration targets compiled.
• All 17 non-database relay workflow-sink tests passed.
• The broad relay library run completed with 830 passing tests, 38 ignored, and 9 existing database-dependent failures: 7 direct Sqlx(PoolTimedOut) media failures and 2 admin 500-versus-404 assertions under the same unavailable database path.
• Rust formatting passed, and strict Clippy passed across buzz-workflow, buzz-relay, and buzz-test-client with all targets, all features, and warnings denied.
• git diff --check, conflict-marker scan, merge-base audit, and required DCO trailers passed.

The PostgreSQL/Redis-backed kind-7 persistence and deduplication regression compiled but could not be rerun on this host because no Docker daemon, PostgreSQL service, or Redis service is available. I am not presenting that unavailable integration gate as new passing evidence; the current branch remains limited to the verified code and unit/package results above.

[BradGroux]

Review and rebase summary

Reviewed the PR for accuracy against current block/buzz main at d42d60d64 and rebased the branch onto that commit.

What this PR does

Adds an add_reaction action to the workflow ActionSink trait, implemented by RelayActionSink. Workflows can now publish a kind:7 reaction event attributed to the workflow owner. The relay signs the event; the actor tag preserves the workflow owner as the effective reaction author for deduplication, deletion, and reaction summaries. The target author's p tag is included for NIP-25 subscription and push notification reachability. A nonce tag prevents delete-then-readd event ID collisions at second granularity.

Accuracy review

• The resolve_workflow_tenant helper is correctly extracted from the existing send_message path, avoiding duplication of the community-host lookup.
• The reaction target is validated: the event must exist, be scoped to a channel, and the channel must not be archived. The workflow owner must be a member of the target channel (or the channel must be open).
• Emoji length is bounded at 64 characters. Empty emoji defaults to + (matching the existing reaction handler convention).
• The insert_reaction_event_with_thread_metadata call correctly threads through the target event ID and author pubkey bytes for deduplication. The ReactionEventInsertOutcome match handles TargetMissing, Duplicate (returns AlreadyPresent), and Inserted (dispatches the persistent event and returns the event ID).
• The integration test (Postgres-gated) verifies: reaction persists with correct kind, content, tags, and attribution; duplicate reaction returns AlreadyPresent; delete-then-readd publishes a fresh event with a different ID.
• No unwrap() or expect() in production paths. No new dependencies.

Rebase result

Head moved from 8cd7bc6e9 to 44478d442. No conflicts. git range-diff shows the patch is unchanged.

CI

DCO passes. Semgrep OSS and zizmor were pending at the time of this comment.

[BradGroux]

Rebase and accuracy review (2026-08-07)

Rebased onto current main (2b873cf20). Clean fast-forward through the intermediate d42d60d64 base — 52 commits applied, no conflicts.

Branch state: d2c7a8343 (was 44478d442 at the intermediate base) Mergeable: ✅ MERGEABLE · BLOCKED (branch protection — awaiting maintainer review)

Accuracy review

The PR adds add_reaction as a workflow action that publishes a kind 7 event through the relay sink (workflow_sink.rs) instead of making an HTTP POST to the old /api/messages/{id}/reactions endpoint. The AddReactionOutcome enum distinguishes Added from AlreadyPresent, and the executor calls engine.action_sink().add_reaction(...) with the workflow owner's pubkey.

⚠️ Important — security regression from #4607. Main merged PR #4607 (fix(workflow): bind trigger author to the signed event) which changed build_trigger_context to derive trigger_author exclusively from the signed event pubkey, preventing an actor tag from impersonating another identity. This PR's branch still uses the pre-#4607 code that reads the actor tag and falls back to the pubkey. The rebase preserves this branch's version because the PR's diff is against the pre-#4607 base. When this PR merges (squash), the squashed commit will revert #4607's security fix.

Recommendation: before merging, resolve this regression by keeping main's event.event.pubkey.to_hex() for the author and removing the actor tag lookup. Alternatively, rebase the PR again after #4607 and drop the lib.rs changes that revert the fix.

The e2e test (e2e_workflow_actions.rs) correctly tests that a workflow with an add_reaction step emits a kind 7 event and continues to the next step. The test filter includes the channel h tag, which is an improvement over the intermediate-base version.

No unwrap()/expect() in new production paths. No new dependencies.

[BradGroux]

This is the third recurring review + rebase pass for the open BradGroux PRs on block/buzz.

What this PR does

Adds an add_reaction action to the workflow action sink, allowing workflows to publish reactions (kind:7) to messages. The implementation:

1. Resolves the workflow tenant context (community + host) via the shared resolve_workflow_tenant helper (extracted from send_message).
2. Validates the target event exists and is scoped to a channel.
3. Checks the reaction author is a member of the target channel (or the channel is open).
4. Bounds the emoji length (max 64 chars), normalizes empty emoji to +.
5. Signs the kind:7 event with the relay keypair, includes #e (target), #p (target author), actor (workflow owner), buzz:workflow, and nonce tags.
6. Inserts via insert_reaction_event_with_thread_metadata, returning AlreadyPresent for duplicates or Published for new reactions.

⚠️ Security regression — remains unresolved

PR #2494 reverts the security fix from #4607 (fix(workflow): bind trigger author to the signed event). The branch still reads the actor tag for trigger_author instead of using event.event.pubkey.to_hex(), which allows impersonation. The squash-merge will revert #4607. Recommend resolving before merge by keeping main's event.event.pubkey.to_hex() for the author.

This was flagged in the previous two review passes and remains unresolved.

Correctness

• The shared resolve_workflow_tenant helper correctly eliminates duplication between send_message and add_reaction.
• The member check and channel-visibility check are correct (non-member allowed only for open channels).
• The nonce tag prevents event-ID collisions on rapid delete-then-readd.
• The allow_self_tagging() call is needed because the relay signs the event (its own pubkey may appear in tags).
• Emoji length validation uses chars().count() (correct for Unicode).
• No new dependencies. No unwrap/expect in production paths.

Rebase result

Rebased from 2b873cf20 to current main 02f640bc4 (7 commits). Clean rebase, no conflicts.

• Old head SHA: 2026f35694c56bdb8cd3129c4410b7f94373c62f
• New head SHA: 4abb60db3b6a6ced1acfd5d4d795773b645be4fe
• Mergeable: ✅ MERGEABLE
• CI: DCO ✅

No code changes were made — this was a review + rebase pass only.

[BradGroux]

Correction: no security regression

This is a correction to the "Security regression" section of the previous review comments. After tracing the actual code on the current branch and main, #2494 does NOT revert #4607's security fix.

#4607's fix is in buzz-workflow/src/lib.rs — build_trigger_context now derives trigger_author from event.event.pubkey.to_hex() instead of reading the actor tag. That code is identical on both main (02f640bc4) and this branch (4abb60db3). The only diff in that file between main and this branch is exporting AddReactionOutcome. The regression test build_trigger_context_ignores_actor_tag is also present on both.

The actor tag that #2494 adds to kind-7 reaction events is consumed by effective_message_author in ingest.rs — an existing helper that resolves the real author behind a relay-signed event for deduplication, deletion, and reaction summaries. This is a different code path from build_trigger_context, which is the one #4607 hardened. The actor tag is data metadata for attribution, not an authorization input.

No action needed. The earlier "security regression" flag was a false alarm caused by not diffing the actual build_trigger_context function between the branch and main.