I haven't check in on this issue in quite a while, but that doesn't sound like a full implementation of what I mean. Creating the key is only one component. It would need to become a standard across the Nostr ecosystem so that events can also be signed using the Coldcard. Meaning I never type my key into anything ever again. I don't even need to see it. I'd just have a seed phrase. Maybe I'm missing something but I haven't seen that functionality yet. 

 You'd of course sign into apps using a public key, but any actions would require a signing device. I mean to have this as an option, not a requirement. This would be cumbersome for most people, but higher profile and more security conscious people should have the option. Especially if we ever want to have presidents, etc using this stuff. (We should). 

 Purpose signing apps (like bitwarden) that get child keys and to sign. Different apps then just ask Signing app to sign..
Parent key held offline, or even just another separate app. To kill child key if need he.. 

 That isn't the only difference. Having my Proton password compromised doesn't also compromise my bank accounts, social media, etc. That's essentially what would happen if one app mishandled your Nostr key. You'd have your entire stack lost all at once. The whole selling point has been one key for all these different things and that is a broken model from a security perspective.

As I said, people can use different keys for every service, but that doesn't solve the root problem. You've simply limited the reking to one service, just like the password model we have now. Except there are no recovery options.

We need a way to give our private keys to no one. Just like Bitcoin. I shouldn't have to give every wallet my private key to transact, nor should I on Nostr. 

 We're talking about different things.  

If you share a password/nsec, multiple services can be comprimised at once. 

If you type a password/nsec into a shady app (proton, a proton companion or clone, or anything else), it'll be compromised.  

Both points are true.  People shouldn't do either.  

People are already better (but still bad) at not reusing passwords.  Painting an equivalence between passwords and nsecs helps folks grok the problems with nsec reuse.

Painting a distimction between them creates some very difficult differences in our expectations.

"Identity" on the other hand is distinct, and we do need a way for multiple nsecs to sign for one identity, the same way we have ways to allow multiple passwords to authenticate the same human. 

 It is NOT the same thing. Even using the same password across websites is not the same as using the same nsec. You can go and change your passwords if one gets compromised and even recover from a compromised password in most cases. You can do that with an nsec. The two things are not equivalent, even if the same bad practices are used for both cases. If I show you my nsec I can't just go change it. Everything is gone forever. That is a lot more catastrophic than even using the same login for every website. For one, an attacker would need to know every place I have an account and go there separately and do something bad. An attacker with my nsec would instantly have access to anything I have on Nostr forever and there's fuck all I can ever do about it. Those two things are clearly different. The idea that we should be throwing everything onto Nostr right now is bananas, and that's the only point I'm making here. 

 *can't do that with an nsec 

 All fair points, but still, you're only looking at the cases where users type nsecs into untrusted apps, which is IMO orthogonal to whether a legacy solution can or should try to be built out on nostr.

We should teach *users* why nsec security is important, not chill *devs* trying to build out the ecosystem.  I use amethyst; never gave it any of my nsecs.  Why not nostr login on proton too? 

 I think the fundamental issue I have is that an app needs to be trusted. I'm not just focusing on typing the nsec into untrusted apps. Even trusted apps can be dangerous, even if by accident. My only issue here is with saying that X company/service should use Nostr instead. Sorry if I haven't conveyed that well. The Nostr general model IS better, just not from a security perspective yet. Nostr should be treated as alpha testing right now until we have at least Bitcoin like security options. We don't (at least from my research), so I disagree that legacy solutions should instead build on Nostr. That's all I'm saying here. People are treating it like it's ready for every service to build on and it isn't. Many more people will get rekt than on the current legacy model, in my opinion. 

 Also, you gave something your nsec if you're using Amethyst to sign notes. My opinion is that I should have the option to give NOTHING my nsec ever. I don't see how that's possible right now and would discourage building critical services on Nostr until we fix that. I don't think Proton should allow it for security reasons. That's my whole point. 

 Something needs an nsec at some point unless you're doing your cryptography with pen and paper!  I use Amber as a signer (on GrapheneOS with network permissions disabled for that app)

I hear ya though, you're definitely not wrong about nsec security!  And I was bit off about PW/nsec equivalemce 🙄

Just thought as an amethyst/amber user, it was an odd reaction to nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug s suggestion, because I'd love to conceivably install & open proton, click a button, sign an event in amber (or whatever), and get logged into my (maybe just newly created) proton account.  🎉 

 The current security model should be entirely changed before we encourage more people to use more things on Nostr. Otherwise, almost everyone is just going to copypasta the same nsec into everything that asks for it and get rekt at some point. We need a new default. 

 Master / Child key concept would be a game changer 

 Yes, it would. It was suggested before and some high level devs shot it down. I sincerely hope they reconsider. 

 WHY on earth.. That a sad thing.. 

 To hard basket??  

 Like wallets derived from master key? 

 Yup like a master/child keys system 

  ✅ EtherFi Airdrop Is Live!. 

 👉 https://telegra.ph/EtherFi-06-23 Claim your free $ETHFI. 

 Just allow clients to accept hash of the nsec 

 Another viable option. 

 💡🥂 

 I'd also love to see sub keys that can somehow be neutered or destroyed. I imagine signing an event using something like a 2/3 multisig or whatever that essentially destroys the other keys for signing and replaces it with one only the holder of the master key(s) can see. A password reset like behavior. Of course, someone who gets the master key(s) would still become king. No way to fix that without offline protections like we have for Bitcoin. 

 100% this. Its the same reason I don't play with nostr apps, clients etc.. I'd love to have my Nostr nsec on, say, a cold card. Creating sub keys now and again, and being able to trash them and create new in the case ifva hack etc.. 

 Oh yeah totally agree!  One key to rule them all is a huge problem.

Akin to address reuse in BTC in 2010, we worked hard to solve that the manual direct way long before BIP32 made the issue trivially easy to avoid.

There's more value if folks can get intuitively comfortable with handling multiple keys, not necessarily the hard way but most likely that'll be most effective, before tools make it seem like magic. 

 nostr:nevent1qqspcjd9tnkk57r3dfut46htcjscc88udns7j0guvfu6jncm86hnl3cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygqhw9adf5sw9fp9eks2yx2kyjs2ffeufa5htuttzkflepl6gmedtqpsgqqqqqqs638v3r 

 I saw this. Looks cool. I am proposing something more robust where child keys can not only be derived from the master, but can be locked to an app or client, turned on, off, paused, or deleted.  

 I'm sure someone has thought of this before... But, you can just generate new key pairs for different things. Why use just one key pair? 

I have separate keys for my home, car, work tool boxes, etc.  

 nostr:nevent1qqs97qk4s0jyt67cfylhc99n7p5vk5cmtlthcyk08ednv6xp7jfy6jspr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqzyp8t3qcs666wm9wx6e4rjkea8n64nwzl4my0w6ga4l2qt2fwq4wk6qcyqqqqqqgqegnc9 

 I mean, sure, but why not just use multiple keys? You don't need anything more complicated.  

 That defeats the purpose of interconnectivity which is one of Nostr's big selling points. Until then I use Amber for everything I can, but their security hasn't been 3rd party audited, and that's understandable since an audit is ~$15-20k, but it's still important to note as Nostr grows. 

 I guess I'm not understanding how it's difficult to manage a few sets of keys. If you have the keys, how is it different than a more complicated set of child/parent keys.  

 This has always been my big beef with #Nostr.
Wasn't much of an issue when Nostr was just social media. But now it's growing into much more. So, now it's a big problem 

 Nip46 remote signer is close to this solution, although a device with the master key needs to be active to complete the signing. I think nip46 has a better trade-off balance because all clients don't need to support the solution to associate those events to your account.

Both your idea and nip46 have a common flooe: the master key must remain a secret. 

 https://github.com/vnuge/nvault 

 Intestesting project 

 Thank you! Unfortunately it's currently blocked by my noscrypt library, but it will get there eventually! I daily drive the dev version at the moment 

 O cool, its your work! I've been considering looking into the available self hosted server based remote signing options currently available. 

 That was the plan exactly! I like self hosting and I don't like moving my nsec around, like at all. As you can see nip46 is on the roadmap. I just want the nip to evolve a bit more from where it's at. The first iteration will likely only be WS direct server for privacy reasons! 

 Nice. How would you like nip46 to evolve? 

 I understand why relayed signer messages are useful for apps like amber and so on, but I believe it's a huge privacy (and security too) concern. I know we use initialization vectors in nip04 but I'm still not comfortable with the idea of privileged ciphertext data (with known formats) being hoovered by other sniffers. Basically I only want direct-to-signer connections, and at a minimum using nip44. 

I shared my concerns on the nip repo a little while ago and I've settled until I can think of something better
https://github.com/nostr-protocol/nips/issues/1207 

 With certificates/delegates/master-child keys you don't have that problem. Master key can stay in cold storage and you can create 1 certificate/delegate per app or multiple.
 

 If you are going to make a breaking change to the nostr protocol like this you might as well focus on key rotation because normal people don't use cold storage and even cold storage can get hacked. 

 Certificates/delegates imply key rotation, because you rotate the certificate/delegate. For reasons of security and repudiation. Only the master is permanent.

As to what "people do" they'll have to do what we tell them is the right thing to do. 

 Identity trees with optional public links would solve this.

You have a master identity/key which can generate child keys, you use a different child per site/service which you can show only the child identity, or you allow it to follow the tree up to a parent identity.

You only share the private key for the child with the site/service, so if it is leaked the damage is contained. The parent key can also sign messages for the child key, so you could still go in an override anything the child does etc. 

 The solution is for all clients to accept Amber or other signers. Too bad Apple only has one.
nostr:nevent1qqsw0t08tnr6vcsvcx6ps52ejr0gpdhc868t5zhjty3wjn0794vfwxgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsyawyrzrttfmv4cmtx5w2m85702kdct7hv3amfrkhagpdf9cz46mgrqsqqqqqp0h57ep