Open joshr4 opened 1 year ago
Yes, though to be clear there are (at least) two separate NIP-07 use cases possible:
Use Case A: (as you describe above) Sign a NIP-26 delegation token with the main identity key safely kept within the extension.
Use Case B: Load the delegatee PK into the extension and store its already-authorized delegation tag(s) in order to sign delegated events using the extension (in this scenario the main identity key would no longer be kept in the extension).
Limiting ourselves to just Use Case A for now:
As I mentioned in the NIP-07 issue discussion, I'm less sure NIP-07 needs to support the Use Case A here.
Certainly I could see a flow:
So basically a kind of imperfect way to bootstrap their way to keeping their main identity key more offline.
Hmm. Gahh, I keep see-sawing! This does seem like the most likely scenario for people to migrate off their main identity PKs.
Yeah I think saving a hot delegated key in each client sounds like they way to go. The user can then use the NIP-07 extension to sign the delegation, like the flow you describe above.
Leveraging events and a dedicated identity manager client, as described in https://github.com/nostr-protocol/nips/issues/247, also sounds like a great approach. I like the idea of using events to communicate between the relevant components, and it would help keep things more composable I suppose.
One thing I'd like to try is to create a "temp" event within nostrtool that has the hash of the unsigned delegation token as its This obviously won't work because the event data won't hash to the id
. This event can then be given to the NIP-07 extension to sign, resulting in the signed event having the 64-byte sig of the event id
(which is the hash of the delegation token). It sounds a bit hacky and not the way NIP-07 is meant to be used, but i'm thinking it may result in a usable signature that can be used within the delegation tag.id
value! NIP-07 rejects the event.
Looks like this is blocked because NIP-07 doesn't yet support signing events with delegation tags, and also doesn't support signing delegation tokens.
In the meantime, I will fork nos2x and implement these two missing functions.
I've got this all working locally (haven't tested the actual delegation tag yet), going to clean up some things and open some PRs ⚡
I'd like to take a stab at adding NIP-07 to this tool.
First, I'd like to plan out the work and make sure i've got a good understanding of what's needed. I'm still learning the nostr protocol, so please point out any mistakes or flaws that I may have made below!
The current flow for this tool is as follows (simplified and left some things out):
Sign delegation
which sends all above info to the/nip26/sign
route inapp.py
where it is signed and returned.Sign event w/delegatee
which sends the delegatee's private key and the delegation tag (and the rest of the event data) to the/event/sign
route where it is signed by the delegatee's private key.It looks like we would need to modify step 3 so that the the delegation token is generated/signed by the extension, which would enable the user to skip step 1 and leave their private key safely within the NIP-07 extension.