I tested a different approach: Buzz as a self-hosted communication workspace connected to two Hermes Agent instances that I control. Jarvis runs at home. Régis runs on a private server I administer. Each agent has its own identity and only joins the spaces I explicitly authorize.

The goal is not to build yet another chatbot. It is to regain control of the most sensitive layer in an agentic system: where conversations, commands, files and access to tools actually flow.

Scope note: this article deliberately takes a step back; it is not an installation tutorial. The complete procedure is available in the official Nous Research documentation. You can also ask Hermes itself for help: it can guide you through installation and configuration. You only need to prepare a machine to host the relay, PostgreSQL and the related services, then install Buzz Desktop. Once you enter the relay URL and your identity, you are connected.

The core idea

A self-hosted agent behind a third-party messaging service is still dependent on that service. Real control means owning the agent, its channel, its identities and its secrets.

Why move away from Telegram for sensitive work?

Telegram is still excellent for getting started. Creating a bot is easy, notifications work everywhere and Hermes connects to it quickly. I still see it as a useful secondary channel.

But the security model needs to be described accurately: Telegram’s Secret Chats use end-to-end encryption, while ordinary bot conversations do not. Telegram also states that a third-party AI bot or mini app is a third-party service with its own privacy policy.

That may be acceptable for checking the weather. It is more questionable when the agent can read private files, control infrastructure, interact with Home Assistant, run scripts, receive professional documents or trigger scheduled tasks.

An agent with tools is no longer just a chat window. It is a conversational administration interface.

— field notes

Buzz: a messaging workspace built as a control plane

Buzz, developed as an open-source project by Block, is a workspace where humans and agents share rooms on a relay you can host yourself. Messages, reactions and workflow actions are represented as signed Nostr events. Humans and agents use the same identity model and the same audit trail.

In my setup, Buzz plays three roles: the user interface with channels and messages, the private relay that transports events, and the meeting point for my agents. Jarvis and Régis do not share my personal identity. In shared channels, they answer when mentioned instead of jumping on every sentence like two interns fueled by energy drinks.

I also keep replies flat in the main channel. A readable human-and-agent conversation works better for me than twenty automatically spawned threads.

Hermes v0.19.1: Buzz becomes a native connector

The Hermes Agent v0.19.1 release, published on July 30, 2026, includes continued work on the Buzz/Nostr channel. Buzz is now available in hermes gateway setup with guided configuration, user authorization and support for channels and direct messages.

The official connector prefers an authenticated Nostr WebSocket subscription for near-instant inbound events. In auto mode it falls back to polling when the connection cannot be established. Outbound replies still go through the official buzz binary. Markdown, images and replies attached to an existing message are supported.

Important: the Nostr private key used by Hermes is a secret. It belongs in ~/.hermes/.env or a protected credentials file, never in config.yaml, a message or a log.

My field-tested defaults

config.yaml · Buzz platform
gateway:
  platforms:
    buzz:
      enabled: true
      extra:
        channels: []
        home_channel: "<main-channel>"
        require_mention: true
        transport: auto
        allow_all_users: false
        allowed_users:
          - "<authorized-public-key>"

display:
  platforms:
    buzz:
      interim_assistant_messages: false
      tool_progress: off
  • channels: [] lets Hermes discover joined channels; after adding a new one, I restart the gateway to begin from a clean state.
  • home_channel stays explicit so scheduled tasks and notifications have a predictable destination.
  • require_mention: true prevents both agents from commenting on every shared-channel message.
  • allow_all_users: false closes access by default; only listed public keys can control the agent.
  • Intermediate output stays hidden. Users see the final result, not every file read or command executed by the agent.

My private two-agent architecture

Private architecture diagram connecting a PC, Buzz Desktop, a private Buzz relay, Jarvis at home, Régis on a private VPS and a secrets vault
Simplified architecture. No real port, domain, channel identifier, internal path or administration mechanism is disclosed. Click the image to enlarge it.
ComponentRole
Buzz DesktopControl station installed on my PC
Buzz relayTransports events and enforces membership
JarvisHermes instance hosted at home
RégisHermes instance isolated on a private server
Secrets vaultProvides each agent with only the credentials it needs
AI modelsLocal models for sensitive work, external APIs when appropriate

This is not a perfect high-availability setup. The two agents do not have exactly the same role or environment. It does provide useful operational resilience: Jarvis stays close to my local network, while Régis can keep handling selected tasks when my home setup is unavailable.

Important: private does not mean end-to-end encrypted

This is the most important nuance in the article. Buzz lets you host the relay and control membership, identities, retention and storage. Its current security model relies on TLS in transit, relay access control and storage-layer encryption. End-to-end encryption for direct messages is described as a future consideration, not a current property.

In production, TLS must terminate at the relay or at a reverse proxy: Buzz does not enforce it by itself. The project is still pre-1.0, and rate limiting is not currently enforced by the relay. If it is exposed to the Internet, I therefore add rate limiting at the proxy, a firewall, private-by-default services and a regular update policy.

!
What I actually control

I remove the dependency on a third-party messaging operator and become the relay operator myself. The administrator of the relay and storage remains inside the trust boundary. Here, “private” describes ownership and operation of the chain, not absolute cryptographic invisibility.

The model endpoint matters too. If Buzz and Hermes run on your machines while every full prompt is sent to a cloud model, you control transport and execution, not inference. That is still valuable, but it is not end-to-end sovereignty.

LevelWhat stays under your controlTrade-off
Controlled channelBuzz, relay, history and agentsPrompts may still reach an AI provider
Managed hybridSensitive data locally, cloud for routine workGood balance of quality, cost and privacy
End-to-endChannel, agents, secrets, storage and local modelMore demanding hardware and operations

My recommendation is pragmatic: control the channel and agents first, then route sensitive tasks to a local model. My article on DGX Spark and GB10 AI mini PCs shows what that final layer requires on the hardware side. Trying to make everything sovereign in one evening is still the fastest route to an impressive system nobody enjoys using.

Separate identities and keep secrets out of conversations

I use three identities: mine, Jarvis and Régis. This keeps agent privileges separate from owner privileges and makes logs much easier to understand. I know which identity spoke, which agent ran an action and which credential must be revoked if something goes wrong.

The same principle applies to API keys. Self-hosting the pipe does not turn chat into a vault. The Hermes secrets documentation currently covers Bitwarden Secrets Manager, 1Password and a command helper for other vaults. Bitwarden can inject keys at process startup and centralize rotation, using a separate machine account for each environment.

  • One machine identity per agent, with only the permissions it needs.
  • No secrets in messages, prompts, screenshots or logs.
  • Centralized rotation and revocation tested before the real incident.
  • Separate administration: an agent should not be able to remove the supervisor that keeps it running without control.
  • Encrypted backups with an actual restore test.

What Buzz changes in daily use

The most visible benefit is not technical. I now have a space where multiple agents can join the same conversation without sharing identities. I can call Jarvis for a home-related task, then Régis for a hosted operation, while keeping one shared history.

Conversation in Buzz where Ruben asks Jarvis for a weekly AI news summary, with Jarvis and Régis visible in the agent list
Buzz in daily use. I ask Jarvis to summarize the week’s AI news in a dedicated channel while each agent keeps a separate identity. Click the image to enlarge it.

New channels become work contexts: research, infrastructure, personal projects or automation. Buzz is no longer an integration attached to Telegram. It becomes my private control plane for AI agents.

The cost is operations. Updates, backups, identities, certificates and exposure all need attention. A personal system abandoned for two years may be less secure than a well-operated SaaS. Regaining control also means taking back the on-call burden.

Hosting Hermes without hosting its communication channel only solves half the problem. Buzz closes the loop: interface, transport, identities and agents remain inside one control boundary.

— verdict

This architecture is probably excessive for occasional use. It becomes much more rational when an agent can read files, operate tools and work continuously. For a simpler starting point, my guide to Hermes Agent Desktop on Windows covers the agent, memory, skills and scheduled tasks first.

Sources