I'm pretty sure this has been done with some custom code on a SeedSigner...

Ask nostr:nprofile1qqs09jtvjlmyrxjn37zv70a89csegcz7rpyqjmnw29cveedhv7vagqqpz4mhxue69uhk2er9dchxummnw3ezumrpdejqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpzpmhxue69uhkummnw3ezuamfdejs92xe5k?

Prolly others as well...

#asknostr

Reply to this note

Please Login to reply.

Discussion

Thanks homie šŸ«‚šŸ™

I love the idea too...

Ultimately, I think nostr may need a good mechanism for migrating your identity to a new keypair; but meanwhile, having the nsec airgapped would be comforting.😃

It seems as though it should be possible. Bitcoin keys in a HWW can sign a message that you broadcast out. Yes it goes into the timechain which is consensus-based so every user basically has ā€œthe same oneā€ whereas Nostr is much more like a patchwork of overlapping communications. But I don’t think that’s a problem.

Maybe the new ā€œparentā€ key signs a message saying ā€œI’d like to take control of this other nsecā€ and then the existing key takes that message and signs it, saying ā€œI irrevocably give this new parent nsec privilege to sign for me and use me to sign for it, and only the parent key has the power to terminate this arrangementā€

I’m not certain how it would work from there (not being a cryptographer or developer). Perhaps relays would need to learn to respect the message, or something gets added to the npub so it hashes differently, idk. (Again, beyond my technical accumen).

How is the delegation and ā€œrecognitionā€ of the parent-child relationship actually handled in nsecbunker already, such that relays and clients know what to do with their signed events? (I’m thinking ELI5 level overview; and perhaps nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft can point us in the right direction if you’re not sure, Duncan).