Oddbean new post about login | logout Can you exactly explain the key management model in your mind?
Offline key signs messages about what other keys can represent it Those other keys go in your clients If one gets compromised, master key signs a revocation and merkle tree of pre-revocation signatures
that's NIP26 - Delegated event signing, but it's kinda deprecated: https://github.com/nostr-protocol/nips/blob/master/26.md
So review our key handling practices, but it's still impossible (or deprecated) to actually have good ones...?
thoughts? cc: @fiatjaf , @PABLOF7z nostr:note12uj0j60pvzjtaaw2q2rqqc87y7lgwhqtpw06thahf5sqmxmftt8qqhqg4s
Excellent thread highlighting something that has been on my mind forever. nostr:note1r79yxgy57vf50cfte8srwzn5ycz2ad2nzuuz2yxek2uur9jk5uzs0msvzw
Key delegation and revokation (or even better, rotation) are badly needed, but NIP 26 isn't it. Some recent discussion on the topic: https://github.com/nostr-protocol/nips/pull/1452 I'm sure your perspective on the problem would be very welcome.
It's not really necessary, because it is impossible.
How does it currently work? Do nostr clients store the private key on their servers after it's submitted by the user?
Usually it's stored in the app/browser, hopefully never on the server. You can also use extensions like nos2x or alby to protect your key from the app, or you can use NIP 46 signers like nsec.app or Amber to hold your own keys and sign remotely.