Connect Share: recover friendships securely across reinstalls and devices

[robinbraemer]

Human need

“Link once” must remain true after reinstalling Minecraft, replacing a computer, or using another launcher. Losing every friend because one local file disappeared destroys trust.

Outcome

Players can securely recover or move their Connect Share identity and confirmed relationships without silently uploading plaintext private keys or granting a new device invisible access.

Acceptance criteria

• Provide an encrypted export/import path that works without a Minekube account.
• Optionally support account-backed encrypted recovery with client-side encryption and an explicit recovery secret.
• Minekube services never receive plaintext libp2p private keys, endpoint tokens, or an unencrypted friend graph.
• New-device enrollment is visible, authenticated, revocable, and rate-limited.
• Device loss and suspected compromise support identity rotation and relationship re-verification.
• Concurrent devices have defined presence, request, admission, and removal semantics without duplicate spam.
• Importing an existing Connect dashboard endpoint remains distinct from social-identity recovery.
• Backups are versioned, integrity-checked, and recover safely from interruption or partial writes.
• UI explains what is backed up, where it is stored, and what losing the recovery secret means.
• TDD covers restore, wrong secret, tampering, rollback, device revocation, simultaneous devices, identity rotation, and offline recovery.

Product metric

Percentage of legitimate device migrations completed without relinking friends, with zero server-side plaintext identity compromise.

Parent: #93

[robinbraemer]

Implemented the offline recovery foundation and player flow in PR #94 at commits 350980f and 1586cb6.

Deterministic evidence:

• authenticated versioned AES-256-GCM archive with PBKDF2-HMAC-SHA256, random salt/nonce, strict allowlist, bounds, paired endpoint validation, and redacted values
• atomic owner-only export plus staged import, durable transaction marker, rollback on injected replacement failure, and next-operation recovery after simulated process loss
• wrong password, one-byte tampering, malformed input, unsupported version, symlinked material, and live-file backup target overlap all fail closed
• nonblocking view model with export password confirmation, authenticated import preview, explicit replacement confirmation, active-share refusal, restart copy, and password-buffer clearing
• same screen and English/German strings compile and pass tests in Fabric 1.20.1, 1.21.1, 1.21.11, and 26.2
• common, fabric-common, and all four Fabric adapter gates passed; each rebuilt artifact contains 31 recovery entries and stays below the 90 MiB gate

The offline backup is deliberately documented as a single-device transfer. A signed rotation protocol is still required to revoke a lost device that remains active and to deterministically suppress simultaneous restored copies without turning Connect into the social relay. Optional Minekube-account recovery also requires a separately threat-modeled enrollment/revocation service with audit and rate limits. Those two criteria remain open and are tracked as gaps rather than claimed complete.

No backup path, content, password, private identity, friend capability, endpoint, or token was emitted as evidence.