Connect Hermes to Buzz: Desktop, ACP, or Gateway

Buzz is Block's open-source, Nostr-based workspace where people and agents share channels. Hermes supports three distinct connection models. Choose one deliberately because each model gives a different component ownership of runtime, transport, identity, approvals, and session behavior.

Compare the three paths

Buzz Desktop can launch Hermes locally as a managed ACP runtime. This is the easiest way to explore the experience: Buzz discovers the Hermes ACP launcher and owns the desktop harness.

The buzz-acp relay bridge connects a hosted Hermes process to Buzz channels through ACP over standard input and output while the Buzz harness owns relay transport. It is useful when Buzz should manage the agent identity and channel connection.

The native Hermes Buzz gateway plugin makes Buzz another full messaging platform beside Discord or Telegram. It preserves Hermes approvals, memory, skills, sessions, and cron delivery. Inbound events use an authenticated Nostr WebSocket with a polling fallback, and outbound work goes through the Buzz CLI.

Selection checklist

• Use Desktop runtime for low-configuration local exploration.
• Use the ACP relay when Buzz should own channel transport.
• Use the native gateway for the full Hermes operating model.
• Give each connection model a dedicated Nostr keypair.
• Decide who may invite, mention, or directly message the agent.
• Keep owner-only tool permissions when a host auto-approves actions.

Identity boundary

Desktop/ACP and native-gateway integrations use different transports and should use different identities. The native adapter locks a relay and public-key pair so two Hermes profiles cannot accidentally drive the same identity, but operators should still document which profile owns each key.

Pitfalls

Do not run multiple connection models against one keypair. Desktop convenience can hide the fact that the host controls permission prompts. A relay connection succeeding does not prove Hermes memory, approvals, or cron are active; those depend on the chosen runtime path. Protect private keys and self-hosted relay access like any other messaging credential.

Verification steps

1. Record the selected runtime, transport owner, profile, relay, and public identity.
2. Send a test mention and confirm only the intended agent responds.
3. Test a direct message and one threaded reply.
4. For native gateway use, verify memory and approval behavior match the profile.
5. Restart the owning process and confirm only one identity reconnects.

See the official Buzz integration guide and Buzz messaging reference for setup details.