SwBratcher on Nostr: Nostr Needs: So far I know npub is my public key. nsec is my secret key. I share my ...
Nostr Needs:
So far I know npub is my public key. nsec is my secret key. I share my npub, but if I share my nsec intentionally or unintentionally my account is basically burned. Yes my nsec keeps me secure and does a great service while secure, but once it’s not secured is there no recovery of a secure status for my profile? I would propose a NIP to adjust how the nsec is handled with regard to client logins.
Something like this:
nsec: master private key
nsub: subordinate private key
npub: public key
The nsec is what I secure like a set of bitcoin recovery words and it’s only used to generate and manage my nsub keys.
The nsub keys are derived from the nsec and are managed by the nsec, but are safely entered into clients without fear of the client then leaking my nsec, because if I find that an nsub has misbehaved or had been leaked, I can burn it to the network by managing it through the nsec and my nsec can generate new nsub keys as needed.
With the right NIP functionality added to all clients it could allow unique nsub usage per client and better safeguarding of the nsec. One npub is fine. Just need to eliminate the profile fatality if an nsec is compromised via mishandling or failure of clients to always be secure for me.
Thoughts? LynAlden (npub1a2c…w83a) jack (npub1sg6…f63m) NVK (npub1az9…m8y8) jb55 (npub1xts…kk5s) other devs? I’m not aware enough of the protocol to know its capabilities or efficiencies, so of course I’m coming at this from a UX perspective only.
So far I know npub is my public key. nsec is my secret key. I share my npub, but if I share my nsec intentionally or unintentionally my account is basically burned. Yes my nsec keeps me secure and does a great service while secure, but once it’s not secured is there no recovery of a secure status for my profile? I would propose a NIP to adjust how the nsec is handled with regard to client logins.
Something like this:
nsec: master private key
nsub: subordinate private key
npub: public key
The nsec is what I secure like a set of bitcoin recovery words and it’s only used to generate and manage my nsub keys.
The nsub keys are derived from the nsec and are managed by the nsec, but are safely entered into clients without fear of the client then leaking my nsec, because if I find that an nsub has misbehaved or had been leaked, I can burn it to the network by managing it through the nsec and my nsec can generate new nsub keys as needed.
With the right NIP functionality added to all clients it could allow unique nsub usage per client and better safeguarding of the nsec. One npub is fine. Just need to eliminate the profile fatality if an nsec is compromised via mishandling or failure of clients to always be secure for me.
Thoughts? LynAlden (npub1a2c…w83a) jack (npub1sg6…f63m) NVK (npub1az9…m8y8) jb55 (npub1xts…kk5s) other devs? I’m not aware enough of the protocol to know its capabilities or efficiencies, so of course I’m coming at this from a UX perspective only.