Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding NIP-07 compatibility #1

Open
joshr4 opened this issue Feb 10, 2023 · 6 comments
Open

Adding NIP-07 compatibility #1

joshr4 opened this issue Feb 10, 2023 · 6 comments

Comments

@joshr4
Copy link

joshr4 commented Feb 10, 2023

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):

  1. User adds their private/public nostr keys
  2. User adds a delegatee private key and any restrictions
  3. User clicks Sign delegation which sends all above info to the /nip26/sign route in app.py where it is signed and returned.
  4. User can then create an event and click 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.

@kdmukai
Copy link
Owner

kdmukai commented Feb 11, 2023

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:

  1. Have some configuration option: if a NIP-07 extension is detected, select whether or not it should be used as the main identity. Probably a nice-to-have for the browser to request the delegator's pubkey (aka the main identity) from the extension in order to display it in the UI.
  2. Same as above.
  3. Pass the delegation token to the extension for the main identity key to sign and return.
  4. Same as above.

@joshr4
Copy link
Author

joshr4 commented Feb 11, 2023

Ok cool, makes sense. I think this may also require a PR to NIP-07 to add a new signDelegation function to window.nostr.

I'll first focus on adding that to NIP-07 and implementing it in nos2x, and then we can call that new function from within nostrtool to generate the delegation token.

@kdmukai
Copy link
Owner

kdmukai commented Feb 12, 2023

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:

  • User has their main identity PK hot in the NIP-07 extension.
  • They go to a new Nostr web client and generate a brand new "hot" PK in the client.
  • User creates a NIP-26 authorization for that "hot" PK and signs it w/the NIP-07 extension.
  • User interacts with the web client using only their delegated "hot" PK.
  • User can then clear their main identity PK from their NIP-07 extension.

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.

@joshr4
Copy link
Author

joshr4 commented Feb 13, 2023

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 nostr-protocol/nips#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 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. This obviously won't work because the event data won't hash to the id value! NIP-07 rejects the event.

@joshr4
Copy link
Author

joshr4 commented Feb 16, 2023

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.

@joshr4
Copy link
Author

joshr4 commented Feb 17, 2023

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 ⚡

Screen.Recording.2023-02-17.at.9.15.46.AM.mov

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants