Move the encrypted-key store from a single slot to a per-pubkey map so
several saved nsec accounts each keep their own key on the device and the
profile switcher can move between them. Previously bitvid:sessionActor:v1
held one key (last-saved wins), so switching among saved nsec accounts
silently failed.
- sessionActor.js: new bitvid:sessionActors:v2 map keyed by pubkey (follows
the existing bitvid:<thing>:<npub> convention). readStoredSessionActorEntry,
persistSessionActor, clearStoredSessionActor take an optional target pubkey;
legacy v1 slot is kept in sync as the last-saved default and migrated into
the map on first read. IndexedDB mirror keyed per-pubkey. Adds
listStoredSessionActorPubkeys().
- client.js: getStoredSessionActorMetadata / unlockStoredSessionActor accept a
target pubkey; access-denial cleanup forgets only the blocked account.
- nsec provider threads expectPubkey into the unlock so a switch unlocks the
requested account, with the expectPubkey guard as a backstop.
- authSessionCoordinator: look up the target account's stored-key metadata.
NIP-46 multi-account (single slot bitvid:nip46:session:v1) remains as a
follow-up. Tests: tests/session-actor-multi-account.test.mjs (7).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Audit of the nsec (direct private key) login found the client's
registerPrivateKeySigner silently ignored the access-control validator AND
the persist/passphrase options, so:
- Access-control bypass (security): nsec logins skipped the blacklist/whitelist
gate that NIP-07 and NIP-46 logins enforce. registerPrivateKeySigner now runs
the validator BEFORE activating the signer and forgets a since-blocked stored
key on denial.
- "Remember this key" never worked: it persisted nothing (the payload used a
shape persistSessionActor rejects), and there was no way to detect or unlock a
saved key — getStoredSessionActorMetadata and unlockStoredSessionActor were
referenced by the UI/provider but defined nowhere. Implemented both on the
client: persist now writes the canonical { privateKeyEncrypted, encryption }
shape (PBKDF2 250k + AES-GCM, already in place), the login modal can detect a
saved key, and unlock decrypts with the passphrase and re-activates via the
same proven createNsecAdapter path. The nsec provider now passes the
access-control validator to the unlock path too.
- Fixed misleading copy: the provider claimed BIP-39 seed support, but only
hex/nsec are accepted.
Untouched-but-verified: decode/validate (hex64 + nsec1), logout clears the
in-memory key, no key logging.
Tests (tests/nsec-login.test.mjs): a denied validator rejects login and
activates no signer; persist -> unlock round-trips the same pubkey (wrong
passphrase fails); unlock re-checks access control and forgets a blocked key.
The validator-enforcement and persist-shape fixes are both mutation-verified.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
- Move NIP-07 extension login logic from `js/services/authProviders/nip07.js` to `NostrClient.loginWithExtension`.
- Add `validator` support to `NostrClient` login methods (`loginWithExtension`, `connectRemoteSigner`, `useStoredRemoteSigner`, `registerPrivateKeySigner`) to allow pre-session security checks.
- Update `nip07.js`, `nip46.js`, and `nsec.js` providers to inject `accessControl` checks via the new validator hook, ensuring consistent enforcement of whitelists/blacklists before activating the signer.
- This creates a unified "harness" for all signing methods within `NostrClient` while keeping business logic (access control) in the service layer.
Co-authored-by: PR0M3TH3AN <[email protected]>
