Proposal: buzz-archive — own your room history (working implementation, MIT)

*A local, verifiable archiver for Buzz communities. Working implementation, MIT, offered
for adoption as a community plugin — or as a spec for native export if Block would
rather ship it first-party.*

## The problem

Everything that happens in a Buzz room lives on the community relay — and only there.

- There is no local copy, no export command, and no published retention policy.
- The local app stores only replaceable persona state; agent logs are diagnostics.
- Every event is beautifully signed — and then nothing user-facing ever uses those
signatures. Search can tell you which agent did what and who asked it to, but only
as trust in the server's scrollback. There is no way to answer "prove my agent
actually said this."

Users are accumulating months of agent collaboration they don't hold and can't back up.
Most haven't noticed yet. They will, and the ones running real work through Buzz will
notice angrily. Teams treating agent output as work product (we run a writers' room —
every decision in our film's story canon was made in a Buzz channel) need the record to
outlive any single service.

## The proposal

A small, read-only archiver daemon that any community member can run:

1. Joins the community as a dedicated low-privilege member identity ("Archivist").
2. Subscribes to an explicit allowlist of channels and event kinds.
3. Appends every event **verbatim, signature intact** to local monthly JSONL files —
one signed event per line, append-only, never rewritten.
4. Verifies every event on write (id recomputation + BIP-340 signature check);
failures are quarantined, never mixed into the archive.
5. Keeps an honest gap ledger: an outage produces a gap record that is closed only
when a complete backfill provably covered the interval — `open`, `reconciled`, or
`unverifiable`, never silently "fine."
6. Ships with an evidence resolver: `resolve ` → the full signed event plus
an independent verification verdict.

Companion pieces, same repo: a pull-based backup script (rsync to a second machine,
incremental re-verification, doubles as a liveness monitor for the archiver) and a
deterministic session-map generator (per-session Mermaid flowchart where every node
carries its event id — a human-readable audit trail over the raw archive).

## Design principles

- **Read-only by construction.** The transport layer has an outbound allowlist
(`REQ`/`CLOSE`/`AUTH` only); a test proves an `EVENT` frame cannot be emitted. The
recorder can never contaminate the record.
- **Plain files, no lock-in.** JSONL on disk. Everything above it (maps, search,
memory) is derived and rebuildable. Grep works.
- **Evidence over trust.** The archive is only worth keeping because every line is
independently verifiable. Signatures are checked on capture, on backup transfer,
and on resolution.
- **Explicit scope.** Channel allowlist; discovery of new channels is report-only.
An archiver should never quietly widen what it collects.

## Status

Production-tested against a live hosted community (macOS launchd deployment, Python,
stdlib + `websockets` only). Test suite includes the official BIP-340 vectors,
crash-tail recovery, backfill-truthfulness cases, and the transport read-only proof.
All of it is MIT, available now:
**https://github.com/notboringentertainment/buzz-archive**

## What we'd ask from the Buzz team

Building this required reverse-engineering three undocumented behaviors, which is the
fragile part and the reason to talk rather than just ship a repo:

1. **Auth**: relay access requires the standard NIP-42 AUTH event *plus* the
proprietary `auth` membership tag. Works, but undocumented — a documented
auth path for read-only clients would make this plugin (and any third-party
tooling) robust across releases.
2. **Relay conventions**: the relay ACKs client `CLOSE` with a late `CLOSED` frame and
rejects reuse of closed subscription ids — fine once known, surprising until then.
3. **Kinds**: channel chat/reactions/deletions/canvas kinds are discoverable but
unlisted. A short "event kinds" doc page would do it.

None of this asks for code — every item is documentation the team already has in its
heads.

And one question worth answering publicly either way: **what is the hosted relay's
retention policy?** If the answer is "indefinite," users deserve to be able to rely on
it. If it's anything else, they deserve to know — and this plugin becomes essential
rather than nice-to-have.

## Why Block might want this to exist

Independent coverage is already converging on attribution as Buzz's moat: [AI Labs'
review](https://www.youtube.com/watch?v=a8tLTd4q-fU) calls knowing which agent did
what, and who set it off, "the real unsolved problem" in multi-agent work — and Buzz
"the only serious answer anybody has shipped." The same review flags the adoption
worries this proposal addresses: the record lives only on a server its operator can
read, and the retention policy is unpublished. An attribution story is only as strong
as the record underneath it. A verifiable, user-held archive is what upgrades "scroll
back and search" into proof.

"Your agents' work belongs to you" is a better pitch than discovering the opposite.
Buzz already did the hard part — signing everything at the protocol layer. This is the
missing last mile that turns those signatures into something users can hold: an archive
they own, on their disk, that proves itself. It costs the hosted service nothing and
answers the data-ownership objection before enterprise users raise it.

Start by reviewing the linked buzz-archive implementation and its tests, especially the BIP-340 vectors, backfill-truthfulness cases, and transport read-only proof. Document the NIP-42 plus proprietary auth path, relay CLOSE behavior, event kinds, and hosted relay retention policy; done means these behaviors and the retention answer are published for users and plugin authors.

Written by the indexing model from the issue text.