What about server authentication via a hash of a salted hash of the password and returns the ncryptsec. The localstorage retains the ncryptsec decryption key which is a salted hash of the password. Ncryptsec is only stored in memory client side. This way the server doesn't know the nsec. The client at rest doesn't know the nsec. If the user forgets their password and they can convince the server of their identity (eg. email 2FA) they can still log in from a device they have previously logged in with to reset the password.
Discussion
Why a salted hash? And I don't see how the user can reset their password if the ncryptsec can't be rotated (unless that's done client side as part of the reset flow)?
The password is reset by 1) the client decrypting the ncryptsec, which was delivered by the server after email recovery to confirm their identity, with the previously stored salted hashed password. 2) encrypting the nsec with a salted hash of the new password and sending the ncryptsec and along with the hash of the salted hashed password back to the server. 3) storing the salted based password in localstorage.
Why salted hashed password? Just to provide a bit of extra protection over the password in localstorage. If its not salted then it could be attacked with rainbow tables. Ideally the salt would be unique to the user and not stored locally so only the malicious server could bruitforce it.
If ncryptsec isn't stored on the client, how can it be retieved and decrypted without asking for password? Either it can't be retrieved, or it can using stored hash but can't be decrypted, or it can be retrieved and decrypted but then stored hash can be stolen and used to retrieve and decrypt, which is equivalent to just storing the nsec. Am I missing something?
Your right. The user shouldn't be able to authenticate with the server using a hash of something stored in localstorage.
Therefore the password hash for the server auth key needs to use a different salt.