One Log, Several Kinds of Trust
Buzz's event pipeline and identity model become useful only when they are judged together. This checkpoint connects signed activity, relay validation, local authorization, and community scope into one bounded collaboration record, then separates the different kinds of trust that record can provide. The result is a practical test for the next layers of Buzz: search, audit, agent participation, and workflows should make the shared substrate more useful without quietly becoming new authorities.
The phrase “signed and searchable” sounds like one guarantee. It is at least six.
A collaboration record has more than one boundary
Take a simple incident message: “We saw this database error during the last release.” In Buzz, the message can be signed by a human or an agent, submitted through an authenticated connection, associated with a channel, stored by the relay, delivered to eligible members, found through search, and later related to an audit entry or workflow. Those outcomes feel like one act to the person who typed the sentence. Architecturally, they are separate properties with different owners and failure conditions.
The first property is authenticity. A valid event signature and identifier give the relay evidence about which key signed the content. This is the foundation for attribution. It does not tell us whether the message is accurate, whether the key belongs to a wise person, or whether the author had authority to speak in the room.
The second is authorization. The relay must establish that the authenticated principal may perform this operation and reach this channel or community. A correctly signed event from an agent that is not a member of a private channel can still be rejected. A key's validity and a room's admission policy are complementary, not interchangeable.
The third is persistence. A normal message can become a durable event in the relay's store. A presence heartbeat or typing indicator can be intentionally ephemeral. Persistence tells us what a later reader can recover from history; it does not decide whether an event was authentic or authorized in the first place.
The fourth is delivery. A stored event is not necessarily delivered to every connected client. Buzz's subscription and fan-out paths are expected to respect channel scope and access. A member who was offline may need historical retrieval; a non-member should not receive a private event merely because a broad filter happened to match its kind.
The fifth is discoverability. Search can make a large history usable, but a search result is a candidate for retrieval, not a new permission. The relay still needs to check whether the requesting identity may see the underlying event. Discoverability therefore depends on the record without replacing its authority.
The sixth is tamper evidence. A hash-chained audit record can make alteration or reordering detectable according to the chain's rules. That is different from proving that the recorded action was justified, that the underlying message was true, or that every relevant event was captured. A perfect chain of incomplete or mistaken decisions remains incomplete or mistaken.
These distinctions explain why Buzz uses a relay as a single source of truth but several projections and control paths around it. The relay owns acceptance and scope. The database owns durable event state. Delivery owns who receives a live event. Search owns a retrieval view. Audit owns a tamper-evident sequence of selected actions.