Multi-user support: switch identities, multiple sessions, identity picker

[melvincarvalho]

Pre-1.0 placeholder for the multi-user dimensions of SSO. Each branch below probably becomes its own 0.0.x issue once we get there, but capturing the design space now so we don't paint ourselves into a corner with single-user assumptions.

Dimensions

1. One human, multiple Nostr keys. A user has separate keys for different contexts (work, personal, anonymous) and wants to sign in as a specific one. The signer extension may have a default key but support switching.

2. Multiple browser sessions. Different tabs / windows / private browsing — each can be a different identity simultaneously. The SSO page can't assume a single global session.

3. Same key, multiple pods. The user's pubkey is bound to several WebIDs (work pod + personal pod). SSO needs to show a picker before redirecting.

4. Sign in as someone else. A "switch identity" flow that clears the cached resolver-host (0.0.5) and restarts.

5. Family / shared device. Pre-known list of identities surfaced as quick-pick buttons, with a "different person" fallback.

Interactions with the existing roadmap

• 0.0.5 (resolver memory in localStorage) — needs to scope by pubkey, not be global. Otherwise the "last successful host" leaks across identities on the same device.
• 0.0.6 (authenticated session) — token storage has to handle multiple concurrent sessions. Probably a session-keyed-by-pubkey map.
• 0.0.7 (passkey-only fallback) — different identity-discovery mechanism; needs to compose with everything above.

UX questions to settle

• Where does the identity picker live? After signer-extension consent? Before?
• How do we handle a signer that returns a different key than localStorage expected?
• Default identity vs. always-prompt — which is the v1 behavior?
• What's the "logout" semantics — wipe stored state for one identity, or all?

Out of scope (for now)

• Account creation flow (a related but separate UX surface)
• WebAuthn / passkey identities (tracked separately)

Refs

• 0.0.1 in 0.0.1 — one-button SSO end-to-end against solid.social #1 — current single-user PoC assumes one key, one pod, one session
• 0.0.5 in 0.0.5 — remember the user's successful resolver in localStorage #4 — resolver-memory scoping is the first concrete piece that this issue touches