Replying to Avatar Dikaios1517

Great write-up nostr:nprofile1qy0hwumn8ghj7mn0wd68yttjv4kxz7fwv3jhyettwfhhxuewd4jj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3zamnwvaz7tmwdaehgu3wwa5kuef0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qyt8wumn8ghj7mn0wd68yetvd96x2uewdaexwtcpzdmhxue69uhhwmm59e6hg7r09ehkuef0qy88wumn8ghj7mn0wvhxcmmv9uq35amnwvaz7tms09exzmtfvshxv6tpw34xze3wvdhk6tcprdmhxue69uhhyetvv9ujumn0wd68yurvv438xtnrdakj7qgwwaehxw309askgun99eeh2tcqyqlhwrt96wnkf2w9edgr4cfruchvwkv26q6asdhz4qg08pm6w3djgcxx8f0! I was unaware of Nowser, Knox, and Keycast before reading this. Will need to check them out.

One line above wansn't entirely accurate, but it's minor. You said, "This lets you create temporary keys that can sign events on your behalf, without exposing your private key." The bunker strings created for NIP-46 are not keys at all. They don't actually sign anything. ALL signing is done using your actual private key. The bunker string just gives a client the necessary information to communicate with the application that is storing your private key, that way the client can send a request for a signature that the signer app will use your private key to sign, and then send the signed event back to the client.

It's an important distinction, because it is why the device running the signer app has to remain online for NIP-46 signing to work. If the bunker strings were keys in and of themselves that could be used to sign events, then communication with the signer app remotely would not be necessary.

Hmm. I guess I've always misunderstood it incorrectly confusing this with NIP-26 then.

Reply to this note

Please Login to reply.

Discussion

Thanks.

Yeah, I don't think we have any clients supporting NIP-26 in the wild. Key delegation would be cool to have, but if I remember correctly there are some tradeoffs that have kept anyone from seriously pursuing implementing it.

Some recent discussion on those tradeoffs here

https://github.com/nostr-protocol/nips/issues/1810