Windows v0.4.26: post-reboot identity recovery allowed an agent key to replace the community owner key

[iampaycheck]

Summary

After an ordinary Windows reboot, Buzz Desktop v0.4.26 opened the private-key onboarding/recovery screen instead of the existing community-owner identity. Importing a key then replaced the desktop identity slot without warning that a different identity had previously occupied it and without making a backup.

The imported key turned out to be one of the desktop-managed agent keys, not the owner's key. The owner's only surviving session was on mobile, but mobile exposed neither an nsec export nor owner/member administration, so that session could not readmit the desktop. We ultimately abandoned and rebuilt the community.

This may be a Windows regression or an uncovered migration state after #1568. I am reporting the observed state separately because #1568's recovery design should have prevented a silent identity swap.

Environment

• Buzz Desktop v0.4.26
• Windows
• Block-hosted *.communities.buzz.xyz community
• Incident observed 2026-07-30 after a routine reboot

Observed evidence

• Windows Credential Manager contained one Buzz target, secrets.buzz-desktop (2,380 bytes), holding the app's JSON secret blob.
• Enumerating all credential targets found no other Buzz/Nostr credential or legacy identity copy.
• The credential file under %APPDATA%\Microsoft\Credentials\... and %APPDATA%\xyz.block.buzz.app\identity.migrated had the same write second: 2026-07-30 11:45:43.
• The blob still contained all eight agent:<pubkey> entries; those agents continued to authenticate and post.
• Only the human identity slot had changed.
• The key in identity derived to hex pubkey 591e37b82ee51e8658779a2edfccbe658127f3ec2da729a9fa765d8de3bd1350, an existing outbound courier agent. It was not an app-generated key.
• The relay's real community owner was a different pubkey and remained the sole member with the owner role.
• No shadow copies, File History, restore points, browser-stored nsec, alternate Windows credential, or server-side owner-key copy survived.
• Mobile remained logged in as the true owner, but exposed no private-key reveal and no member-admin UI.

Likely sequence

1. A post-update/reboot launch failed to resolve the existing owner identity and entered onboarding/recovery.
2. The recovery import accepted an agent nsec.
3. Buzz stored that nsec over the human identity slot and wrote identity.migrated.
4. The original owner key became unavailable on desktop.
5. The surviving mobile owner session could not export the key or admit a replacement desktop identity.

I cannot prove why the original key failed to resolve. An earlier diagnosis that Buzz generated the replacement key was wrong; the derived pubkey proves the replacement was the existing courier agent.

Expected safeguards

• If any durable signal says an identity previously existed, never treat the launch as first-ever and never replace the identity without an explicit old/new pubkey warning.
• Before an identity import overwrites a different stored identity, require confirmation and offer/export an encrypted backup.
• Keep the existing key material until the imported identity has been verified and the user has explicitly committed the replacement.
• Let a surviving mobile owner session export its nsec or perform the owner/member administration needed to admit a replacement device.
• Surface enough startup/recovery diagnostics to distinguish missing, locked, corrupt, and migrated keyring states.

Related local incident record

Seven-Day-Inc/centrifuge#301 contains the timestamped investigation and the correction identifying the replacement as the courier agent.

[iampaycheck]

Closing this combined report as a duplicate of the two narrower reports filed concurrently: #5959 covers the destructive Desktop identity replacement path, and #5960 covers the mobile-only owner recovery/admin dead end.