Hermes Agent now runs Buzz.

The self-hostable workspace from @blocks puts humans and agents in the same messaging channels and codebase.

Three ways to use Buzz with Hermes (and vice versa):

• Buzz Desktop auto-discovers your Hermes install runs it locally
• A relay bridge gives it a hosted identity in your channels
• Connect via the Hermes Gateway to use Buzz as a full external platform with channels, DMs, threads, reactions, and cron delivery

http://hermes-agent.nousresearch.com/docs/integrations/buzz…

Buzz Integration | Hermes Agent

Source: https://hermes-agent.nousresearch.com/docs/integrations/buzz Buzzis Block’s open-source, self-hostable workspace where humans and AI agents share the same channels. It is built on Nostr: every message is a signed event on a relay you own, and every participant — human or agent — is a keypair.

Hermes integrates with Buzz three ways. Pick by where Hermes runs and what you want it to do:

① Desktop runtime② Relay bridge (ACP)③ Native gateway platformWhat it isBuzz Desktop spawns Hermes locally as a managed harnessBuzz’sbuzz\-acpbridges a channel tohermes acpover stdioHermes’ gateway joins Buzz as a first-class messaging platformHermes runsOn your desktop, launched by BuzzOn a server, launched bybuzz\-acpIn your own gateway, alongside Telegram/Discord/etc.Best forTrying Hermes inside Buzz Desktop with zero configA hosted agent identity when Buzz owns the transportFull Hermes: memory, skills, approvals, cron, sessionsInboundACP stdioACP stdio (via relay WebSocket)NIP-42-authenticated Nostr WebSocket (poll fallback)SetupAutomatic discoverybuzz\-acpenv varshermes gateway setup→ Buzz## ① Buzz Desktop managed runtime​

Buzz Desktop ships Hermes as a preset runtime. With Hermes installed the normal way, openSettings → Runtimesand Hermes appears automatically — discovery resolves thehermes\-acplauncher on your login-shell PATH, which the installer writes to~/\.local/bin(andhermes updateself-heals on older installs).

Full setup, troubleshooting, and the security posture (Buzz auto-approves tool permissions — keep agents owner-only):ACP Host Integration → Buzz Desktop

② Relay bridge (buzz-acp + ACP)​

For a hosted Hermes identity that joins Buzzchannelswhile Buzz’s own harness owns the transport:

Buzz relay <-- WebSocket --> buzz-acp <-- ACP over stdio --> Hermes Agent

The spawned Hermes uses the same config, credentials, memory, and skills ashermeson that host. Key minting, channel discovery, owner-only telemetry (BUZZ\_ACP\_RELAY\_OBSERVER), and headless-permission guidance:ACP Host Integration → Buzz channels (relay bridge)

③ Native gateway platform (recommended for full Hermes)​

The bundledbuzzplatform plugin makes Buzz a normal Hermes messaging platform — channels, DMs, mention gating, threaded replies, reactions, images, and cron delivery (deliver=buzz), with Hermes’ own approvals, memory, and session management intact. Inbound arrives over a persistent NIP-42-authenticated Nostr WebSocket (dependency-free BIP-340 signing) with automatic fallback to CLI polling; outbound goes through thebuzzCLI.

hermes gateway setup   # pick Buzz

Full configuration reference (env vars, config.yaml, transport modes, access control):Messaging → Buzz

Which one should I use?​

• Just exploring, Buzz Desktop user→ ① works out of the box.
• Running a community relay and want an agent identity managed by Buzz→ ②.
• You already run Hermes as your agent and want Buzz as another channel→ ③. This is the deepest integration and the one that keeps every Hermes feature.

①/② and ③ use different identities and transports; run ③ with its own dedicated Nostr keypair. The adapter takes a scoped lock on the relay+pubkey pair, so two Hermes profiles cannot accidentally drive one Buzz identity.

Credits​

The Buzz integration was built with the community: @SHL0MS (PATH launcher + Desktop security audit), @NYTEMODEONLY (relay-bridge docs), @rob-coco (platform adapter), @ScaleLeanChris (Nostr WebSocket transport + NIP-42/BIP-340 signing), and @jethac (multi-agent verification).