Most team chat tools treat an AI agent as a bot account. It joins a channel, receives a message, calls an API and posts a reply. That works for small automations, but it becomes awkward when several agents are researching, writing code, reviewing patches and coordinating with people over a long-running project.

Block's Buzz starts from a different model: a human and an agent should be participants in the same workspace, each with an identity and an auditable history.

On November 14, 2026, the main repository appeared at position 8 on a third-party daily GitHub Trending snapshot. The companion desktop application repository was also among the faster-growing projects in a separate tracker, which measured 56% growth over seven days. Desktop v0.5.30 was published that day.

What Buzz brings together

Buzz is an open-source, self-hostable collaboration workspace with channels, threads, direct messages, media, Git integration, workflows and agents. The desktop app lives in the separate block/buzz-app repository; the main repository contains the relay and server, with a Flutter mobile client in its own directory.

The core product idea is that an agent is not a shared bot that impersonates a human. It has its own cryptographic identity and can participate in channels alongside the team. That gives the workspace a consistent way to record who sent a message, started a workflow or performed an action.

Buzz channel thread screenshot from the official repository

Source: official Buzz repository screenshots.

Buzz agent collaboration screenshot from the official repository

Source: official Buzz repository screenshots.

Why Nostr is part of the architecture

Buzz uses the Nostr event model. A message, reaction, workflow step or other action is represented as a signed event. The main repository is Apache-2.0 licensed; because the desktop client is separate, review its license and dependency notices before redistributing a combined build. The relay verifies signatures, persists events, distributes updates to connected clients, indexes content for search and triggers automation.

This is not a blockchain. The architecture document explicitly describes a relay as the single source of truth. Clients connect to that relay over WebSockets. The project does not currently describe a peer-to-peer event exchange or multi-relay replication model for a workspace.

The repository breaks the backend into several Rust crates:

  • buzz-core contains event types, verification and kind registration.
  • buzz-db handles PostgreSQL-backed events, channels, tokens, workflows and audit data.
  • buzz-auth implements authentication, scopes and rate limiting.
  • buzz-pubsub uses Redis for presence and live updates.
  • buzz-search provides PostgreSQL full-text search.
  • buzz-audit maintains a hash-chain audit log.
  • buzz-workflow runs YAML-defined automation.
  • buzz-acp bridges relay mentions to agent harnesses through ACP and JSON-RPC.

The relay coordinates identity, history, Git events and automation.

Run the relay locally

The official quick start requires Docker and Hermit. If you prefer not to use Hermit, the README lists Rust 1.88 or later, Node 24 or later, pnpm 10 or later and just as the relevant tools.

git clone https://github.com/block/buzz.git cd buzz . ./bin/activate-hermit just setup && just build . ./bin/activate-hermit just relay 

just setup bootstraps the local environment, starts the required Docker services and runs migrations. The development relay is available at:

ws://localhost:3000 

For a production-style single-node or VPS deployment, the project points to the Compose bundle under deploy/compose/. Do not use the root development docker-compose.yml as if it were the production deployment recipe.

To try the desktop client, follow the separate Buzz app repository. The main README also links to the Flutter mobile setup.

A realistic workflow

Imagine a team maintaining an open-source library. It creates a channel for a release, adds the maintainers and grants a release agent access to that channel. The agent can summarize issues, prepare a patch or report test results. A human reviews the change and approves the next step.

The benefit is attribution: a maintainer can see which actor performed an action. A channel can also keep project context, decisions and agent activity together instead of scattering them across terminal logs, bot DMs and pull-request comments.

What the community is debating

The Hacker News launch thread reached 378 points and 339 comments in the snapshot we reviewed. Supporters liked the self-hosted model and agent identities; critics questioned whether teams need a new chat, Git and identity system at once, or whether Nostr adds enough over a tool such as Zulip.

Those objections matter. Replacing Slack and GitHub is a bigger decision than adding an agent to an existing workflow. The project itself says it is unfinished.

Where Buzz fits, and where it does not

Buzz is interesting for teams that want to experiment with agent-native collaboration, self-hosting and signed activity records. It may suit open-source communities, internal developer platforms and teams that already run their own infrastructure.

It is not yet an obvious drop-in replacement for Slack, GitHub or GitLab. Its single-relay architecture creates a clear operational boundary, but it also means the relay is central to the workspace. The Nostr event model has a learning curve. A team must also think carefully about what permissions an agent receives, which channels it can read and what actions it may initiate.

Option Best reason to choose it
Buzz Human-agent collaboration built around signed events and a self-hosted relay
Slack or Discord plus GitHub Existing integrations, familiar workflows and incremental adoption
Zulip or Matrix Self-hosted communication without adopting Buzz's integrated Git and agent model
Linear or Plane Project tracking, not a full agent-native communication relay

Desktop v0.5.30 is a small maintenance release, not a new architecture announcement. It is still useful evidence that the client is being updated alongside the server. Read the release notes and architecture document before a team deployment.

For a community walkthrough of the identity model, see the video below.

Sources and further reading

Would you adopt a workspace where agents have their own identities, or would you rather keep agents inside the chat and Git tools your team already uses?

AI disclosure: This article was prepared with AI assistance; technical claims and commands were checked against the linked primary sources.

About the author: GitHub · LinkedIn · YouTube