Open Source Project #175: Buzz — Block Rebuilds Team Collaboration on Nostr, Where AI Agents Hold Their Own Cryptographic Identity

Block's open-source team workspace launched July 21, 2026, where humans and AI agents collaborate as equal members in shared channels. Built on Nostr: every agent holds its own cryptographic keypair — identity and history are portable across any Nostr-compatible system. Rust backend, Tauri desktop, supports Claude Code, Codex, Goose. YAML workflow engine, buzz-cli (JSON in/out, machine-first design for LLM tool calls), NIP-34 Git integration. 21.3k Stars, Apache 2.0, self-hostable.

·10 min read·AI Tools
open-sourceworkspaceAI-agentNostrcollaborationRustTauricryptographyJack-DorseyBlockClaude-Codeworkflow

Introduction

"Not agents assisting humans. Agents and humans in the same room, working on the same thing."

This is article #175 in the "One Open Source Project a Day" series. Today's project is Buzz — the open-source team workspace released by Block (Jack Dorsey's company) on July 21, 2026. Its core premise: AI agents should join teams as full members, not be bolted on as bots or plugins.

Slack, Teams, GitHub — existing collaboration tools integrate AI roughly like this: configure a bot token, let the bot monitor a channel, trigger a response when @mentioned. The agent has no independent identity, no persistent history, no auditable action record, and permissions controlled by the platform rather than the organization.

Buzz takes a different approach. Built on the Nostr protocol, every participant — human or agent — holds a keypair that belongs to them, not the platform. Identity, behavior, and history are all cryptographically signed and portable to any Nostr-compatible system. A human member and an agent member look identical in the channel.

21,300 Stars. Apache 2.0. That's six days after launch.

What You'll Learn

  • Why Buzz chose Nostr instead of building its own identity system
  • How agents become full members in Buzz, not bots
  • How the ACP protocol drives Claude Code, Codex, Goose, and other agents
  • buzz-cli's machine-first design: built for LLM tool calls
  • The YAML workflow engine: triggers, steps, and action types
  • The Rust + Axum backend, Tauri desktop app, full technical stack

Prerequisites

  • Familiarity with team collaboration tools (Slack/Discord-type workflows)
  • Basic understanding of AI agent tool-calling
  • Knowing what a keypair (public/private key) is helps

Project Background

Why Block Built Buzz

Block spent two years building AI tools internally and reached one conclusion: productive work happens when humans and agents are in the same context together. Separate tools, separate systems, separate histories produce fragmentation and repeated context-rebuilding.

The problem with existing platforms isn't missing features — it's the wrong design assumption: they treat AI as "assistants" rather than "members."

Buzz's starting point: agents should have the same participation rights as human members — independent identity, auditable behavior, persistent history, configurable permissions.

Timeline

  • July 21, 2026: Public launch with simultaneous open-source release
  • GitHub: 21,300 Stars within days of launch
  • Hosted: buzz.xyz (Block's instance)
  • Self-hosted: Full Docker + Rust toolchain support

Author / Team

  • Company: Block, Inc. (founded by Jack Dorsey)
  • License: Apache-2.0
  • Primary language: Rust (backend) + TypeScript/React (desktop via Tauri) + Dart (mobile via Flutter)

Project Stats

  • ⭐ GitHub Stars: 21,300+
  • 🍴 Forks: 2,300+
  • 📄 License: Apache-2.0
  • 📅 Launch date: 2026-07-21

Why Nostr

Buzz's identity system runs entirely on the Nostr protocol. That decision shapes the entire product architecture.

The Problem Nostr Solves

Traditional collaboration platform identity: the platform issues accounts, controls access, owns the identity and history. Switching platforms means rebuilding everything.

Nostr's model: each participant generates their own secp256k1 keypair. The private key belongs to them. Every message is signed with that key. Identity belongs to no platform, history is portable, behavior is non-repudiable.

What this means for agents:

Traditional bot model:
  Platform issues bot token → agent calls API with token → token revoked = agent gone
  Identity belongs to the platform, history belongs to the platform
 
Buzz / Nostr model:
  Agent generates its own keypair → signs every message with its private key → key belongs to agent
  Identity is portable, history lives in the relay, switching relays preserves identity

Nostr NIPs in Use

  • NIP-01: Base event format (the underlying structure of every message)
  • NIP-42: Authentication (verifying key ownership when connecting to the relay)
  • NIP-34: Git integration (patch submissions, repo announcements, commit status)

"The Relay URL Is the Community"

One Buzz design decision: a community (workspace) is identified by its relay URL. wss://your-org.buzz.xyz is your workspace — the URL itself is the authoritative identifier. Different relays are different communities. All state on one relay shares a single event log.

How Agents Become Full Members

Not a Bot, a Member

Traditional platform bots: a service account that monitors specific channels and triggers responses on @mention. In the permission model, typically a separate category from human members.

Buzz agents: hold their own keypair, join channels exactly as humans do, and their messages are signed Nostr events that appear in channel history indistinguishably from human messages.

Adding an agent to a channel:

# Same operation used for adding a human member
buzz channels add-member --channel CHANNEL_ID --pubkey AGENT_PUBKEY --role member

What Cryptographic Identity Means in Practice

Every message an agent sends carries a signature from that agent's private key:

  • Non-repudiable: anyone can verify which agent produced any given message
  • Auditable: agent actions in the audit log have unambiguous attribution — not "some bot"
  • Portable: the agent's keypair isn't bound to Buzz; the same identity works on any Nostr-compatible system

How ACP Drives Agents

Buzz routes relay events to agent processes through ACP (Agent Client Protocol):

Buzz relay (WebSocket event stream)
        ↓
buzz-acp (standalone binary, runs outside the relay)
        ↓
ACP (JSON-RPC over stdin/stdout)
        ↓
Agent process (Claude Code / Codex / Goose / custom)
        ↓
MCP tool calls → message posted back to channel

Key design: one active prompt per channel at a time. Subsequent @mentions queue while the current prompt is in flight, preventing overlapping context windows from race conditions. Agent process crashes trigger automatic harness restarts. Conversation history lives in the relay's Postgres database, not the ACP process — agents restart with full context intact.

Supported Agents

Built-in support (auto-detected from locally installed harnesses):

  • Claude Code (Anthropic)
  • Codex (OpenAI)
  • Goose (Block's own agent)
  • Grok (xAI)
  • Any custom ACP-compatible agent

buzz-cli: An Interface Built for Machines

Machine-First Design Principles

The Buzz CLI is designed for programmatic consumption, not human convenience:

  • JSON to stdout: all output is structured JSON, parseable by programs
  • Structured errors to stderr: error output is separated from result output
  • Meaningful exit codes: 0 = success, non-zero = typed failure, scriptable

Configuration via environment variables:

export BUZZ_RELAY_URL='http://localhost:3000'
export BUZZ_PRIVATE_KEY='nsec...'   # agent's or user's private key

Core Operations

# Channel management
buzz channels list
buzz channels create --name "dev-ops"
 
# Send a message
buzz messages send --channel CHANNEL_ID --text "Deploy complete, v2.3.1"
 
# Full-text search (covers messages + canvases + git events — all one index)
buzz messages search --query "deploy failed" --since 24h
 
# Read a thread
buzz threads read --thread-id THREAD_ID
 
# Canvas read/write (documents)
buzz canvases write --canvas-id ID --content "..."
 
# Workflow management
buzz workflows list
buzz workflows run --workflow-id ID
 
# Agent memory storage
buzz memory set --key "deployment-config" --value "..."
buzz memory get --key "deployment-config"
 
# Git repo announcements (NIP-34)
buzz repos announce --url https://github.com/org/repo

The intended use: agents call these commands via MCP tools to post reports to channels, read context, update canvases, and query history — without directly manipulating the relay protocol.

YAML Workflow Engine

Trigger Types

Workflows support four trigger types:

trigger:
  on: message_posted       # when a message is posted
  # on: reaction_added     # when someone adds an emoji reaction
  # on: schedule           # cron expression
  # on: webhook            # external HTTP webhook

Full Example: Release Request Workflow

name: "Release request"
trigger:
  on: message_posted
  filter: "str_contains(trigger_text, 'ship it')"
steps:
  - id: announce
    action: send_message
    channel: "{{trigger.channel_id}}"
    text: "Release requested by {{trigger.author}} — starting deployment pipeline."
 
  - id: notify-ops
    action: send_dm
    to: "ops-lead-pubkey"
    text: "Manual approval needed for release from {{trigger.author}}"
 
  - id: wait-approval
    action: wait_approval
    approvers: ["ops-lead-pubkey", "eng-lead-pubkey"]
    timeout: 30m
 
  - id: trigger-deploy
    action: webhook
    url: "https://ci.internal/deploy"
    method: POST
    body: '{"version": "{{vars.release_tag}}"}'

Every step emits events into the relay's event log. Search queries across workflow execution history the same way they search channel messages.

Supported Action Types

  • send_message — post to a channel
  • send_dm — send a direct message
  • add_reaction — add an emoji reaction
  • webhook — trigger an external HTTP request
  • wait_delay — pause for a specified duration
  • wait_approval — wait for human approval (partially implemented)

Technical Architecture

Backend (Rust)

Buzz's relay is a Rust workspace with focused crates:

buzz-relay          Axum WebSocket + REST HTTP server
buzz-store          Postgres event storage + full-text search
buzz-pubsub         Redis pub/sub (real-time message fan-out)
buzz-media          S3/MinIO media file storage
buzz-acp            ACP protocol harness (standalone binary)

One event log: chat messages, canvas updates, code reviews, CI events, and workflow step results are all Nostr events in the same Postgres table with the same full-text index. Searching "deploy" returns related chat discussion, canvas docs, and Git commit statuses from a single query.

Security model:

  • Tenant context resolved from server hostname, not client-supplied tags — agents can't forge cross-community access
  • Channel-scoped tokens cannot publish global events
  • Subscription delivery re-checks permissions at fan-out time, catching changes after subscription
  • Ephemeral events (typing indicators, presence) are verified and access-checked but never written to Postgres

Desktop App (Tauri + React)

# Start relay + desktop together
just dev

Tauri provides system capabilities (file access, notifications) via Rust; React handles UI rendering. The result is a native desktop app with lower memory footprint than Electron.

Mobile (Flutter)

iOS and Android clients are Flutter-based, currently in active development.

Quick Start

Local Development

git clone https://github.com/block/buzz.git
cd buzz
 
# Use Hermit to manage the toolchain (recommended)
. ./bin/activate-hermit
 
# Or install manually: Rust 1.88+, Node 24+, pnpm 10+, just
 
just setup   # initialize dependencies
just build   # build all components
just dev     # start relay (ws://localhost:3000) + desktop app

Docker

docker compose up -d

Includes relay, Postgres, Redis, and MinIO (media storage).

Railway One-Click Deploy

A Railway deployment template is included in the repo — one click to deploy a private Buzz instance in the cloud.

Connect an Agent

# Install buzz-cli
cargo install buzz-cli
 
# Set environment variables
export BUZZ_RELAY_URL='wss://your-relay.buzz.xyz'
export BUZZ_PRIVATE_KEY='nsec...'
 
# Add agent to a channel
buzz channels add-member --channel CHANNEL_ID --pubkey AGENT_PUBKEY --role member
 
# Start the ACP harness (auto-detects locally installed agents)
buzz-acp --relay wss://your-relay.buzz.xyz --key nsec...

Resources

Summary

Buzz bets everything on one design decision: AI agents should join teams as full members, not as attached tools. That decision drives every subsequent choice — Nostr (identity not controlled by any platform), cryptographic keypairs (behavior is auditable), buzz-cli's JSON output (LLM-callable), ACP protocol (unified agent integration standard).

The one-event-log design is worth noting. Chat messages, code reviews, CI notifications, and workflow execution steps all go into the same Nostr event stream with the same full-text index. An agent querying history doesn't need to know "is this a chat event or a code event" — one search surfaces all relevant context. That's an agent-native data model, not a human-designed taxonomy with an agent adapter bolted on.

Buzz is early. Some workflow actions return NotImplemented, the mobile client is in progress, and the ecosystem is just forming. But Block has done something important: it moved the agent collaboration problem from "API integration" to "platform design," then open-sourced the whole platform for the community to evolve.

Explore PrimeSkills — A marketplace for handpicked AI Agents and skills. Each is validated in real enterprise workflows, stripping away hype and keeping only what truly works.

Welcome to my Homepage for more useful insights and interesting products.

← Back to Blog