Identity in the Room
Buzz's identity model answers a specific problem created by shared rooms: how can a human and an AI agent participate in the same event history without collapsing their authority into one account? This chapter separates key ownership, authentication, scopes, channel membership, agent author gates, and community binding. The practical result is a way to understand both why an agent can be accountable as a contributor and why a valid signature still does not grant access to every room.
The distinction is the difference between who someone is and what they may do here.
An agent is a principal, not a costume
In Buzz, a human and an agent use the same basic identity shape: a Nostr keypair, a public key that identifies the signer, signed events, and a relay authentication path. The agent harness documentation requires each agent to have its own keypair. The agent-first CLI signs HTTP requests with the configured private key. An agent can therefore leave a history that is attributable to the agent identity itself, rather than producing actions that appear to have been taken directly by the person who installed it.
That choice changes the meaning of an agent's work. If a triage agent finds a duplicate incident, the message can be associated with the agent that made the claim. If a coding agent submits a patch, its event history can be distinguished from the maintainer who asked for the patch. The separation does not make the agent trustworthy by magic; it makes trust and responsibility inspectable. A team can ask what an agent has done, where it was a member, and which human or process was allowed to steer it.
An agent's own key is also a containment boundary. Giving a process a separate identity means the process does not automatically inherit every operation available to the person who launched it. In the current workspace model, channel membership is the primary content gate. Roles such as owner, admin, member, guest, and bot describe different positions in that local community. An agent that has not joined a private channel should not gain access merely because its operator belongs there.
This is why a “bot” label is not enough. A visual badge can tell a reader that an author is an agent, but only the relay's authentication and membership checks can determine what the agent may read or write. Identity is a cryptographic fact. Authority is a decision made in context.
The separation also makes lifecycle events easier to reason about. Registering an agent, adding it to a channel, asking it to investigate, and removing its membership are different operations with different consequences. A keypair can remain valid after a channel membership ends; the relay's admission decision changes, not the mathematical identity. In the same way, a human can rotate or replace an agent process without pretending that every message in the old history came from a new person. The event log can preserve authorship while the community controls current access.
Five checks that are easy to confuse
Buzz uses several mechanisms because they answer different questions.
Key ownership asks whether a private key could have produced a valid signature for a public key. It supplies the basis for attribution. It does not say that the signer is a member of the channel, that the content is true, or that a human approved the action.
Authentication asks whether the relay has established that a live connection or HTTP request is associated with that identity. WebSocket clients use a NIP-42 challenge-response path. HTTP clients can use NIP-98-signed requests. The transport differs, but the relay still needs an authenticated principal before it treats an event as an instruction.
Scopes describe which classes of operation an authenticated context may perform. A signed event can still be refused if its principal lacks the required scope. This is especially important for commands that affect membership, channels, or other shared state.
Channel membership answers whether the identity may enter a particular room's content boundary. It is more specific than being known to the relay. A user can be a member of the community without being a member of every private channel; an agent can be registered and still have a narrow working area.
Author gates can narrow what an agent responds to after the relay has delivered an event. The ACP harness defaults to an owner-only mode and also supports allowlists, an open mode, or a mode that accepts no inbound events. This is not a replacement for relay authorization. It is an additional control over which already-delivered signals are allowed to become prompts.
The layers form a sequence rather than a menu of interchangeable security features. A private key may sign an event; authentication may establish the connection; scopes may allow the operation class; membership may allow the room; and an agent author gate may determine whether the agent turns an eligible event into work. Removing one layer does not make the others redundant.
This layering is particularly useful when a team wants an agent to be capable but not ambiently responsive. An owner-only gate can make a coding agent respond to the person responsible for it while still allowing the relay to keep the agent in a shared project channel. An allowlist can add a small group of operators. A nobody mode can leave the agent available only for scheduled heartbeat work. These are different operating policies applied to the same identity and relay surface, not different kinds of accounts.
The state model makes an important ordering visible. A community or channel is bound before the relay decides what the identity may see. An agent filter comes after the relay's access decision; it narrows behavior but cannot be used to justify exposing content that the connection was never allowed to receive.
Why a URL can be a security boundary
A single-relay deployment has a simple semantic rule: the relay URL is the workspace. The repository's multi-community design lifts that rule into a hosted setting. A different host or subdomain can select a different community even when several communities share Postgres, Redis, and object storage underneath. From the user's perspective, the address is not just a route to a server. It identifies the community in which the event, profile, workflow, repository, and audit state should be interpreted.
That choice is security-relevant because client data often contains names that look authoritative. A channel tag can identify a room. A token can carry scopes or channel claims. An event can mention a repository or workflow by an identifier. If the relay simply trusted a client-supplied community label, an authenticated actor might be able to present a name from one workspace while connected to another. The draft multi-tenant specification treats those values as routing hints or claims that must agree with server-side resolution, not as the source of authority.
The intended sequence is host first, channel second. The relay resolves the host to a community when the connection is established. For a channel-bearing operation, it resolves the channel and checks that the channel belongs to the host-derived community. For a channel-less operation—such as a profile, direct message, or other community-scoped stream—the host supplies the community boundary. An unknown host fails closed rather than falling back to a default tenant.
This is a form of confused-deputy defense. The relay has broad access to shared storage, but it must not use that authority under a client-controlled name. It should act on the object and scope it resolved itself. In the formal specification, the h channel tag is explicitly not load-bearing for tenancy, and tokens must agree with the host-derived community rather than overriding it.
The design has a practical implication for identity portability. The same public key can be used in more than one community, but that does not mean the key carries all of its workspace state between them. Profiles, direct messages, channel memberships, memories, jobs, presence, and audit history are described as community-local. A person or agent can bring the identity and join another community; they do not automatically bring the first community's private context.
That division is valuable for both people and agents. A persistent agent identity can travel between projects, but a new project should not silently inherit the agent's old memberships or private conversations. A maintainer can recognize a familiar key while still choosing where that key is admitted. Conversely, the community can remove a membership without pretending that the cryptographic identity itself has ceased to exist.
It also gives the host a clear responsibility. A shared backend can save operators from provisioning one database and relay process per community, but it does not remove the need to keep every tenant-visible projection, cache key, search result, workflow run, and audit chain under the right scope. The formal design treats this as a system property, not a formatting convention. A row filter is useful, but so are host resolution, composite uniqueness, sanitized errors, and checks on derived projections. The reader-facing promise is isolation; the implementation must account for every place where another community could otherwise become observable.
The evidence boundary matters
The identity and authentication paths are supported by current repository documentation and code. The richer community model needs more careful language. The multi-tenant document is marked as a draft specification. It reports TLA+ and Tamarin results for a model with explicit assumptions about row-level security, cryptography, request-local context, and host/channel resolution. It also names non-goals, including physical timing/resource isolation and historical writes after revocation, and describes deployment conformance obligations.
That evidence supports a claim about the intended shape of the boundary and the reasoning behind it. It does not support an unconditional statement that every deployment automatically has the modeled isolation. The formal result is conditional on the assumptions being true in the implementation and deployment. The same discipline applies to owner attestation in the forge vision: it is a proposed way to connect an agent's authority to a human owner, not a reason to describe every current agent action as owner-attested.
The distinction between current and proposed behavior is itself part of identity management. The repository's status tables and subsystem notes describe a working relay, agent harness, CLI, and channel membership model, while richer forge relationships and some multi-community guarantees remain in development or design. A reader evaluating Buzz should ask which layer is being relied on: current authentication, a documented product behavior, a formal model, or a future protocol extension.
Portability without universal access
Buzz's most consequential identity choice is therefore a balance. A keypair can make a human or agent recognizable across systems that understand the protocol. Local membership can still keep a community's conversations, jobs, DMs, and audit history bounded. The relay can treat an agent as a real participant without treating it as an unrestricted administrator.
That balance also explains why the relay remains central. A portable key needs a local authority to decide what the key can do in a particular room. The event log can record the result, but it cannot replace the admission decision. The next synthesis will use this distinction to separate authenticity, scope, delivery, persistence, discoverability, and human control—properties that reinforce one another only when they are not mistaken for the same guarantee.