feat(plugin): Buzz (Block/Nostr) platform adapter

[rob-coco]

What

Adds a Buzz (Block/Nostr) platform adapter under plugins/platforms/buzz/, so the agent can connect to Buzz relays and take part in channels and DMs. Implements #68871.

Commits

• feat(plugin): add Buzz (Block/Nostr) platform adapter
• fix(plugin): bridge Buzz config.yaml → env + fix reaction flags
• fix(plugin): strip leading @mention from Buzz channel messages
• feat(plugin): add require_mention setting to Buzz adapter
• fix(plugin): classify Buzz DMs by p-tag so un-mentioned DMs dispatch

Empty DM list workaround

The adapter works around an upstream Buzz bug I filed against the Buzz project — block/buzz#2897: buzz dms list returns [] for a DM recipient, so an agent can't discover DM conversations it belongs to. On hosted relays this means inbound DMs never appear in dms list; they only surface via channels list as an entry named "DM" with an empty description. That caused them to be seeded as group chats and fall behind the channel mention gate — so @Chip /whoami worked, but an un-mentioned DM was silently dropped.

Workaround (fix(plugin): classify Buzz DMs by p-tag …): instead of trusting dms list, classify from the Nostr tags of real traffic. A message another user sends in a DM carries a structural ["p", <own pubkey>] tag even when the text never @mentions the agent, whereas in a real channel a p-tag-to-self only ever accompanies a visible @mention. So a conversation latches to chat_type="dm" on the first kind-9 event that is p-tagged to self without a visible mention — guarded by channels list metadata so a real community channel (real name / non-empty description) is never reclassified. Latching also runs during history seeding (so a leaked DM bypasses the mention gate from the first poll after connect), dms list is kept as a best-effort source with a channels list fallback, and a leading @mention is stripped in DMs too so @Chip /whoami still fires as a slash command after reclassification.

Once block/buzz#2897 is fixed upstream, the dms list path works on its own and the tag-based classification becomes belt-and-suspenders.

Tests

tests/gateway/test_buzz_adapter.py covers the adapter, including the DM-classification behavior described above.

[rob-coco]

@alt-glitch would love to get your eyes on this. Buzz is growing pretty rapidly, and is shaping up to be a great tool for inter-agent communications.

[jethac]

Took your adapter for a real-world spin this weekend and wanted to report back — it held up well.

I've been building multi-agent support on top of #62944 (one gateway process, N agents), and Buzz is the first platform where that registry can map 1:1 onto workspace members — an identity is just a keypair. So I stacked a branch that runs one instance of your adapter per agent, each with its own nsec: draft PR #71686. Your five commits are cherry-picked verbatim with authorship preserved; the wiring builds strictly on top (per-agent credential resolution, connection-identity routing). Your 61 adapter tests pass unchanged on the stack — the per-agent settings path is additive, and legacy single-connection precedence is byte-identical when no agent is bound.

Two findings from running it against a live self-hosted relay (closed mode, NIP-42/98) that may be useful for this PR:

1. Your fix(tools): treat Slack channel IDs as explicit send_message targets #2897 dms list fallback is load-bearing in the wild — recipient dms list returned [] on our relay too, and the p-tag classification path is what actually dispatched the DMs in our integration test. Good call building it.
2. CLI-originated DMs never latch as DMs: messages sent via buzz messages send into a DM conversation carry only the h tag — the structural recipient p-tag your classifier keys on turns out to be stamped by the Buzz desktop client, not the relay. So DMs from CLI/headless senders fall through to the channel path. Possible softening: treat "conversation named DM + empty description + sender ≠ self" as a weaker classification signal, or push block/buzz to stamp the p-tag relay-side. Happy to file this upstream on block/buzz if useful.

One micro-observation, take or leave: _resolve_user_name hits users get per unknown pubkey with no negative caching — mostly invisible with one connection, but it amplifies with N pollers in one process. We didn't patch it in the stack to keep the diff clean.

Nice work on the adapter — it made the multi-agent demo almost anticlimactic.

[rob-coco]

2. CLI-originated DMs never latch as DMs: messages sent via buzz messages send into a DM conversation carry only the h tag — the structural recipient p-tag your classifier keys on turns out to be stamped by the Buzz desktop client, not the relay. So DMs from CLI/headless senders fall through to the channel path. Possible softening: treat "conversation named DM + empty description + sender ≠ self" as a weaker classification signal, or push block/buzz to stamp the p-tag relay-side. Happy to file this upstream on block/buzz if useful.

Yeah, I didn't want to do this because it felt like a hack to cue off of the name of a conversation. I've opened an issue with the block/buzz project to fix the dm channel array bug.

[teknium1]

Merged via PR #73610 with your authorship preserved on all six commits (adapter, config bridge, mention strip, require_mention, p-tag DM classification, docs defaults). On top we added a scoped identity lock (relay+pubkey — prevents the duplicate-reply collision two profiles could hit), negative caching in _resolve_user_name (from @jethac's review), and registered the docs page in sidebars.ts.

Really solid work — the p-tag DM classifier working around block/buzz#2897 was the standout piece, and both your hosted-relay verification and @jethac's independent self-hosted run gave us high confidence. Hermes now ships Buzz as a bundled platform. Thanks!