SwBratcher on Nostr: Lol. Where? I didn’t feel like it should be the nip repo on GitHub yet, but point ...

Lol. Where? I didn’t feel like it should be the nip repo on GitHub yet, but point me to where and I’ll put it. Or just an attachment? This is the first point of writing about it, but as a NIP it seems like it’ll get the right discussion. What NIP-## should I give it? Are we really just at NIP-100 or is there a numbering/naming convention I’m missing?

quoting note1ssw…mydx

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.