Bench: Buzz keypair backup and restore
Last verified: 2026-08-19
The method below is fixed and published. Timers read Not yet measured until the run completes.
Buzz identity is a keypair you hold. That is a data control advantage and an operational risk in the same sentence. This entry breaks a machine on purpose and measures how the restore goes. Desk-drafted from the bench brief. Method is fixed and published below. Numbers land here after the run, and until then every timer on this page reads Not yet measured.
Two-machine restore, Buzz Developer Preview, method fixed 2026-08-19
What is the method?
Two machines, one identity, one deliberate loss event. We record the backup surface, the restore surface, and what happens when a step is skipped.
- Machine A: primary install with an established community and channel history
- Backup: export the private key through whatever surface the app provides
- Loss event: machine A wiped, no cloud restore
- Machine B: clean install, restore identity from the backup
- Failure modes tested: no backup, partial backup, wrong passphrase
Why does this feed data control?
Holding your own key is only control if you can also survive holding it wrong. The Buzz data control cell sits at 7.5 with HIGH confidence on the architecture. This run tests the recovery story that the architecture implies.
Related
- Time to first agent reply, Buzz (Block-hosted)
- Time to first multi-agent room, BAND (Free tier)
- The 24-hour test: what survives in a BAND Free room
- Buzz vs BAND verdict
- How we test
Method fixed 2026-08-19 · DESK REVIEW · PROVISIONAL