Buzz research notes

Last checked: 2026-07-28.

Inspected commit: 3a4bf51, dated 2026-07-28.

Buzz is an open-source workspace from Block where people and agents share channels, repositories, workflows, search, and an audit trail. Jack Dorsey is Block’s cofounder and Block Head; the repository credits the project to Block, Inc.

It is not primarily a memory library. Its larger bet is that team activity should originate in one signed event system instead of being reconstructed later from chat, source control, CI, tickets, and agent logs.

Short read

What is strong:

humans, agents, workflows, and repositories use the same event and identity model
stored events retain their author signature and original event ID
agents have separate keys, channel memberships, and activity histories
the relay is an explicit canonical source rather than a derived vector index
self-hosting keeps the workspace and its search index under operator control
agent memory is encrypted between an agent and its owner

What remains unresolved:

a valid signature proves which key signed an event, not whether its claim is true
agent memory has no required provenance, confidence, validity, or review state
channel membership is a coarse read-and-write authorization boundary
memory and audit writes are not one transactional chain
external systems still need synchronization and permission mapping
several forge and approval capabilities remain designed or partially wired

Buzz is closer to trustworthy context infrastructure than a normal memory SDK because it controls the source workspace. It still needs explicit truth, memory admission, and retrieval policy.

What Buzz is

The relay is the center of the system:

desktop / mobile / CLI / agents
               |
       signed Nostr events
               |
          Buzz relay
       /       |       \
Postgres     Redis     S3/MinIO
events/FTS   fan-out    media/git

Messages, reactions, workflow steps, approvals, git events, and agent activity use Nostr event envelopes. Each stored event has:

an event ID derived from its canonical content
the author’s public key
an event kind
tags
content
a Schnorr signature

The relay authenticates WebSocket clients with NIP-42 and HTTP requests with NIP-98, verifies signatures, checks access, persists events, fans them out, indexes searchable text, and triggers workflows.

The default deployment is one relay and one community. The current architecture also defines host-bound communities for multi-tenant deployments: the requested domain selects the community before auth, search, media, git, workflow, and event handling.

This is a different starting point from connecting an agent to Slack, GitHub, Jira, and Sentry. Buzz attempts to make the workspace itself machine-readable and agent-native.

Why the event model matters

Most context systems ingest records from products with different identities, schemas, timestamps, permissions, and deletion behavior. During normalization, they can lose:

who performed an action
the original relationship between discussion and code
permission scope
ordering
stable source references
the distinction between a proposed action and an accepted one

Buzz reduces that translation problem when work originates inside Buzz. A channel can contain the discussion, patch, CI result, review, approval, and merge event. Those records share one identity model and can reference each other directly.

This creates a useful provenance substrate. An agent can answer with event IDs and links to the source thread instead of citing a detached summary.

It does not make every event true. A signed message can still be mistaken, stale, malicious, or superseded. The event log preserves evidence; an application still has to decide what the evidence means.

Agent identity and authorization

Humans and agents both use secp256k1 keypairs. An agent is not represented by a shared service account or an untraceable background job.

That gives each agent:

its own signing identity
its own channel membership
its own event history
a separable blast radius

Buzz also defines NIP-OA owner attestations for agent actions. An owner can authorize an agent key under explicit event conditions, allowing a verifier to connect an agent action to the owner who delegated it.

The main workspace authorization rule is channel membership. A principal that belongs to a channel can read and write there; a non-member cannot query or subscribe to its private events.

This is clear and inspectable, but coarse. Membership does not distinguish:

read from write
post messages from run workflows
read ordinary discussion from retrieve sensitive history
draft a change from approve or merge it

API scopes and surface-specific checks exist, but normal authenticated relay sessions receive the known scopes and channel membership remains the main content boundary.

Agent memory

Buzz implements persistent agent memory through its draft NIP-AE specification.

Memory uses encrypted, addressable kind:30174 events. It has two record types:

core: one free-form profile containing the agent’s identity, durable rules, and goals
mem/<slug>: named cold-memory entries read on demand

The agent signs memory records. Their content is encrypted with NIP-44 using the conversation key between the agent and its owner. Both can decrypt the memory, but only the agent key can publish authoritative replacements.

The public event envelope reveals the agent key, owner key, event kind, timestamp, and an HMAC-derived address. It does not reveal the memory slug or plaintext.

Records use last-write head selection. A newer event replaces the current value for the same address. A null value is a tombstone. The CLI exposes:

list
get
hash
set
patch
remove

hash and strict patch application help detect stale edits. The owner can also read an agent’s memory for recovery.

At agent-session creation, the ACP harness fetches and injects core. Cold memories are not semantically retrieved by the platform; the agent uses the CLI to read them when needed.

Memory trust boundaries

NIP-AE is careful about encryption, addressing, head selection, malformed records, concurrent writes, and owner recovery.

It intentionally leaves richer memory semantics out of scope. A memory value does not have to contain:

source event IDs
source URLs
observed time
claim type
confidence
permission scope
accepted or proposed status
conflict or supersession links
retention policy

The specification explicitly treats memory poisoning and admission control as implementation problems.

This creates a sharp distinction:

NIP-AE can prove that the agent key wrote an encrypted memory record.
It cannot prove that the memory is correct, source-backed, allowed, or still current.

There is another boundary between personal agent memory and channel access. Engrams belong to an agent-owner pair inside a community, not to a project channel. The platform needs a policy preventing an agent from recalling owner-private memory into a channel where other members can see it.

Core memory is especially sensitive because it is injected into the agent context. A malicious or incorrect durable instruction can influence later tool use. Encryption prevents third-party reading; it does not prevent the agent from storing bad instructions.

The ACP harness handles an unavailable or unreadable core cautiously: it does not treat a fetch error as empty memory and does not invite the agent to overwrite it. The session still starts without the core section, so a memory outage can change agent behavior even when it avoids data loss.

Search and context assembly

Buzz currently uses Postgres full-text search over stored event content and tags. Search can be constrained by community, channel, author, kind, and time-related operators.

This is useful for exact team history:

find the thread where a decision was made
find prior incident discussion
connect a branch channel to its patch and review
inspect actions from one agent identity

It is not a complete context-ranking system. Full-text search alone does not decide:

which source should win a conflict
whether a decision has expired
whether an event is relevant to the current task
how much context fits in the model window
which retrieved claims require citations

Buzz has an advantage because the search result can return the original signed event. Retrieval and context packing still need task-level evaluation.

Audit is useful but separate

Buzz has two related integrity mechanisms:

Nostr signatures bind stored events to author keys.
buzz-audit maintains a SHA-256 hash chain over audit entries.

The security documentation accurately describes the audit chain as tamper-evident, not tamper-resistant. It is keyless, so a database attacker can rewrite entries and recompute the chain.

The event pipeline also writes audit entries asynchronously after the primary event insert. Audit failure does not fail event submission.

That operational choice keeps chat and workflow writes available, but it means the audit log is not a transactional completeness proof. A trustworthy deployment should monitor audit failures, reconcile stored events against audit entries, and test recovery after partial writes.

Ephemeral event kinds such as presence are deliberately not stored or audited.

What is technically strong

Source context is native

Buzz does not first flatten team activity into chunks. The original event remains queryable, signed, and connected to its channel and author.

Agents are principals

Giving each agent a key and membership record is stronger than hiding multiple agents behind one integration token. Actions remain attributable and access can be removed per agent.

Community boundaries are explicit

The domain selects the workspace before data access. The multi-tenant conformance document traces that boundary through events, search, Redis, media, workflows, git, agent memory, and audit.

The system is self-hostable

The documented production shape uses the relay with Postgres, Redis, object storage, and optional Caddy. Teams can operate the canonical event store instead of sending all workspace history to a memory vendor.

Maturity is labeled

The repository distinguishes working features from infrastructure being wired and ideas that are still designed. It is also explicit that the project is pre-1.0.

What still needs proof

The most useful tests for this guide are:

Give an agent access to one private and one public channel, then test whether recalled engrams leak into the public channel.
Remove channel membership while an agent session is active and verify search, subscriptions, cached context, and tool calls immediately lose access.
Create conflicting signed decisions and test whether the agent cites both instead of choosing the newest message blindly.
Fail the audit writer after event persistence and confirm reconciliation detects the missing audit entry.
Replace or tombstone an engram while two agent sessions edit it and inspect conflict reporting.
Connect an external GitHub or Slack source and test edit, deletion, and permission propagation.
Compare task results from full-text event search against a permission-filtered hybrid retrieval layer.
Insert prompt injection into a channel message and an engram, then trace which one reaches the agent’s tool loop.

Where it fits

Buzz is a plausible fit for:

teams willing to work inside an agent-native collaboration workspace
projects that want self-hosted chat, git, workflows, and agents
signed, inspectable histories of human and agent actions
project memory where the original discussion and code event should stay connected
experiments with portable agent identities and owner attestations

It is a weaker fit when:

a company must keep Slack, GitHub, Jira, Linear, and existing IAM as canonical
fine-grained enterprise authorization is required immediately
regulatory controls depend on a transactional, tamper-resistant audit system
semantic retrieval and claim-level provenance are expected out of the box
teams cannot operate a pre-1.0 multi-service platform

Current position

Buzz is one of the more relevant projects for trustworthy agent context because it addresses the workspace, not only the memory store.

Its strongest idea is simple: make human work, agent work, workflow state, and project history share a signed source model before retrieval happens.

That improves identity, source integrity, and traceability. It does not remove the need for truth policy, memory admission, fine-grained authorization, contradiction handling, context ranking, and evals.