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 

 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. 

 > Losing keys.. 

So, you prefer to give your keys to a company that can do anything as if they were you... That is not safer or more private. The company can and is tracking you everywhere. 

> Metadata

DMs on Nostr don't leak metadata anymore. Just use the new one. It has been live for over a year. 

> IP address

Proton doesn't protect you against IP leakage. Every time you connect to any server, your IP leaks, including Proton's.
 

 I don't give any keys to any comoany, first of all. About the rest, this depends on many things 😉 

 You can't create a wallet without creating a proton account, which is controlled by them. You have to give them ability to control your id. 

 nostr:nevent1qqs08p8h2xkhfp2ts04q4sm32nq4657enhesy6l0l4e6hdu3h4ty82gpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygztqvqpecc5m3pv75h8sg60ms0d8e4ge92ka70f5wmauequeg76wypsgqqqqqqs3tr2kv 

 See, you agree. Nostr is way better. 

 I don't agree that Nostr is better. I'm a big fan of splitting your social media activity from other stuff. Don't use the same key for thousand things.  

 You don't need to use the same key. Just the same protocol that you control the key you want to use. 

 For that Nostr needs a better key management like Master / Child keys.  

 Sure, that will help. But managing multiple keys is not hard. A regular password manager solves most of the way. There is no need to link keys together with a Master / Child crypto scheme. 

 But currently if Iwant to take my I D across different nostr clients. I have to use same nsec don't I?  

 Only if you want your follows to see what your are doing with the other ID. For instance, I have another ID for DMs and another ID for my health data. 

If you are on Android, you can use Amber to sign for any other app. If you are on the Web, you can use browser extensions to sign.  

 Master/child, or "delegates" as some call them, or "certificates" as they're called in the real world, are needed for hot/cold storage and for repudiation. 

 nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug why don't you stay in your lane and write some myLabel.setText code or something. 

 Why don't you stay in your lane and go play tic tac toe or something. 

 nostr:nevent1qqsw0t08tnr6vcsvcx6ps52ejr0gpdhc868t5zhjty3wjn0794vfwxgpyfmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kueflvakx7cnpds7kzmrvqgsyawyrzrttfmv4cmtx5w2m85702kdct7hv3amfrkhagpdf9cz46mgrqsqqqqqpkzkqm8 

 Use orbit and hire your ass in tor 

 I use InviziblePro 😉 

 I use #grapheneOS 
what does Quebes offer that  GOS doesn't? Thanks  

 QubesOS is for desktops and I think it's the best "OS" when it comes to privacy and security.
 

 "Best" daily driver anyway. Tails is awesome too, but for a very different usecase. 

 Yes, Tails is a great tool and I use it too. But as you said it has a different usecase. If it would be easy to spin up a RAM based QubesOS VM maybe I would drop Tails.