Add delegation to nip 46

[staab]

This PR adds a delegation command to NIP 46, which allows applications that are already authorized to create new sessions with limited permissions. My use case for this is sharing a read-only session with push- or email- notification servers, which can only sign kind 22242 events on behalf of the user, in order to get access to auth-gated relays.

[alexgleason]

Brave of you to reuse the word "delegation" for this. 😂

I think it's a clever idea. I can picture a UI in a client that lets you delegate, which would be convenient for marketing accounts. delegrate itself would be a perm. In the signer database it's still flat, no hierarchy, just maybe a delegated_by column for inventory tracking.

I could picture nak delegate etc.

But is it worth the added complexity? This just saves you from having to go back through the Bunker's interface to add a new connection.

[staab]

Brave of you to reuse the word "delegation" for this. 😂

I know, it made me second guess myself.

But is it worth the added complexity? This just saves you from having to go back through the Bunker's interface to add a new connection.

The alternative would be much more complex. Initially I thought about adding a lock_perms query param to nostrconnect or connect, but that would force the client to go through the connect flow before handing off the bunker url (since if the lock_perms param was on the bunker url, the delegatee could just strip it before doing connect). It would also be worse UX I think, since the user would have to scan the QR code again.

It also overloads connect with multiple behaviors re: the ability to request additional perms. Clients might end up using the locked flow on bunkers that don't support locking, meaning delegatees could escalate permissions. By adding a new method, we can guarantee that delegation/locking functionality is opt-in only.

I'm open to better ideas, but I don't think re-using connect improves anything.

[alexgleason]

But why shouldn't the user go through the Bunker interface to add the new connections? Do you need it to be automatic for what you're building?

[staab]

But why shouldn't the user go through the Bunker interface to add the new connections? Do you need it to be automatic for what you're building?

No particular reason. I don't think it's ideal, but I also don't see why it would be an improvement, since the user has to accept the connection on their bunker anyway.

[vitorpamplona]

I am with @alexgleason. I don't get the need for the extra command. You could just sign the user up with a regular NIP-46 connection.

[staab]

I feel like I addressed that question already, but let me try again:

If you re-use the normal bunker flow, the delegatee can always request more privileges. This could be fine, since users have to approve those updates anyway, but privilege escalation when unnecessary is always a bad thing. Users also may be confused about what app is asking for additional privileges. Locking privileges to what is initially requested solves this, but requires signers to implement it — which they may not do if it's bolted onto the existing flow.

[vitorpamplona]

Yes, I don't think that is worth the added complications of the separate command.

[staab]

But it's... less complicated. Overloading a single command with multiple semantics and security models is what's complicated! I feel like I'm taking crazy pills.

[vitorpamplona]

I would also not overload or change the connect command at all. There is no need to change NIP-46 for this because user approvals already exist. And apps unexpectedly asking for new permissions already trigger the user's red flags.

[staab]

Ok, I see. I disagree, but I think that's a reasonable position.

[greenart7c3]

I think creating a new command for this is better. Some people just blindly accept any permission or configure the signer to sign everything automatically.
You can see this because people still lose their follow lists
Another option would be to have a new tag when sending the connection event with the client pubkey from the main connection
Instead of just the p tag you send p tag and a delegate tag