Summary
On Buzz Desktop for Windows, an ordinary restart after a storage-scheme change left an established account at the private-key import screen. Importing a key replaced the existing human identity slot in the single secrets.buzz-desktop credential blob without warning, backup, or undo.
This is a destructive identity operation presented as onboarding.
Evidence
Measured on 2026-07-30:
- Windows Credential Manager contained one Buzz credential,
secrets.buzz-desktop; there was no legacy Buzz/Nostr credential to recover.
%APPDATA%\\xyz.block.buzz.app\\identity.migrated and the credential backing file had the same modification second.
- The established community owner key was no longer in the blob.
- The eight
agent:<pubkey> entries in the same blob survived.
- The replacement
identity derived to the existing Harold courier-agent pubkey, proving that the app did not generate the replacement. The earlier diagnosis that first-launch generation produced a fresh identity was wrong.
- No local recovery source existed (no shadow copy, File History, restore point, browser copy, or owner key among the key-bearing files on the paired Linux host).
The complete corrected incident record is public at https://github.com/Seven-Day-Inc/centrifuge/issues/301#issuecomment-5133776152.
Expected behavior
Once Desktop has durable evidence that an identity existed, failure to resolve that identity must be a fail-closed recovery state, never first-run onboarding. Before replacing a non-empty or previously-present identity, Desktop should:
- State explicitly that the operation replaces the account identity.
- Show both old and proposed public keys where possible.
- Require destructive confirmation.
- Require or offer an encrypted export of the current secret blob before mutation.
- Preserve a recoverable prior copy or provide an undo path.
- Never modify unrelated
agent:<pubkey> entries.
Impact
The only surviving owner key remained on mobile. Desktop lost owner access to the hosted community, and relay-operator intervention or a full community rebuild became necessary.
Summary
On Buzz Desktop for Windows, an ordinary restart after a storage-scheme change left an established account at the private-key import screen. Importing a key replaced the existing human
identityslot in the singlesecrets.buzz-desktopcredential blob without warning, backup, or undo.This is a destructive identity operation presented as onboarding.
Evidence
Measured on 2026-07-30:
secrets.buzz-desktop; there was no legacy Buzz/Nostr credential to recover.%APPDATA%\\xyz.block.buzz.app\\identity.migratedand the credential backing file had the same modification second.agent:<pubkey>entries in the same blob survived.identityderived to the existing Harold courier-agent pubkey, proving that the app did not generate the replacement. The earlier diagnosis that first-launch generation produced a fresh identity was wrong.The complete corrected incident record is public at https://github.com/Seven-Day-Inc/centrifuge/issues/301#issuecomment-5133776152.
Expected behavior
Once Desktop has durable evidence that an identity existed, failure to resolve that identity must be a fail-closed recovery state, never first-run onboarding. Before replacing a non-empty or previously-present identity, Desktop should:
agent:<pubkey>entries.Impact
The only surviving owner key remained on mobile. Desktop lost owner access to the hosted community, and relay-operator intervention or a full community rebuild became necessary.