Graham O'Nero on Nostr: I added the option of creating an account with a username and password early on to ...

I added the option of creating an account with a username and password early on to Nosmero because normies understand that process (actually just did a big refactor of this feature to harden security).

Username-password requires no explanation because that is *The Official Signup Process* for social media sites. Yes, I understand people reuse passwords and usernames and all that, but acting like a "regular" social media site on this point for new accounts, I think, makes onboarding easier. Nosmero accounts created with username-password can export their nsec from localstorage to use in another client once they grok how nostr works.

For anyone curious, here's how it works in Nosmero with the goal of the nsec (or password) never leaving the user's machine:

1. The browser generates the nsec locally (nostr-tools generateSecretKey).

2. The browser encrypts it with the user's password using NIP-49 (scrypt + XChaCha20-Poly1305) → produces an ncryptsec.

3. The browser derives a per-user salt deterministically from the username (SHA-256 of username + a public domain-separator). No "give me the salt for user X" round-trip.

4. The browser PBKDF2-hashes the password with that salt.

5. ONLY the ncryptsec and the PBKDF2 hash get sent to the Nosmero server. The user's nsec and the user's password both stay on their machine.

6. The Nosmero server bcrypt-wraps the incoming hash before storing it. So even if the database is leaked, the stored blob isn't a credential, it's a bcrypt(PBKDF2(password)) which still needs offline brute-forcing.

Login is the same in reverse: client recomputes the deterministic salt + PBKDF2, server bcrypt.compares against the stored blob, returns the ncryptsec, browser decrypts it locally with the password. The local nsec is then used to sign events.