NIP-26: Delegation coordination flow, new events (general discussion)

[optout21]

Specifying delegation coordination between two apps is not in the scope of NIP-26, but some hints could be included; and some extra specification would be helpful for improved UX experience.

The goal of delegation is that the client using the delegated identity does not possess the secret of the main identity. As a consequence, the delegation needs to be created (signed) in another client (a client with the role of identity manager). But how does the delegation tag/token gets to the delegated client?

Some options:

• Copy & paste
• QR code
• Remote signing (NIP-46 Nostr Connect #153 )
• Nostr note

Copy-paste of delegation tag is not optimal UX, as it's quite long. Copying of anything more complex than a pubkey is not optimal.

QR code has the same concerns, and in addition, not all clients have access to camera.

Signing of the delegation tag through remote signing. The condition for this is that the identity manager client also acts as a remote signer. Also, remote signing protocol may need extension. Delegation parameters are set in the delegatee, so signer should be able to meaningfully display them for the user. In general, Delegation and Remote signer are two different approaches for the same problem (not having main secrets in a client), and mixing/tying them is not a good idea.

Sharing through Nostr notes is convenient, but what kind of note to use?

• Metadata
• Custom
• New kind

Metadata could be extended with list of (valid) delegations. However, extending metadata usage increases the risk of race conditions between clients.

Flow:

• in delegated client, user creates a new identity, copy the new pubkey
• in identity manager client, user chooses Delegation, pastes the delegatee pubkey, sets parameters, sign, create delegation tag
• Post new event that includes the delegation tag
• Delegated client notices the event, and extract the delegation tag. If it does not find it (some events may get lost), as a fallback the main identity pubkey can be entered, and it can retrieve.

Alternatively, a custom or a new event kind could be used for this purpose. The concern here is event kind bloat.

Request delegation. The UX flow initiated by the delegated client should also be considered:

• User installs new secondary client, creates new identity
• It searches for its main identity (e.g. by search on username or other metadata; fallback can be copy-paste)
• Selects 'Request delegation' action

As a result, a relevant event is posted. Special event kind or custom kind, or metadata with unsigned delegation. User starts its primary (identity manager) client, it notices the delegation request (complete with delegatee pubkey and proposed parameters), and can perform the delegation.

My proposal is special event kinds for new delegation and request for delegation, but kind list bloat is a concern. Copy-paste of delegation tag is also acceptable, it is the simplest solution. I would expect NIP-26 to offer a hint on this.

Note that delegation tag would be still included in all delegated events (per NIP-26), the new events are only for coordinating the delegations, and they are not needed later, the validity of the delegation of an event can be determined from the enclosed delegation tag.

[optout21]

comments welcome @kdmukai @markharding @joshr4

[joshr4]

I like the idea of coordinating all this via Nostr notes, and the idea of an identity manager client. Sounds like an elegant way to put NIP-26 to use! No comments or opinions from me at this point.

[optout21]

My plan:

1. Extend NIP26 with hint notes on simplest UX flow with copy&paste of delegation tag (create PR)

2.a. Hack delegation support with new events used to pass around delegation tag (e.g. using keystr and/or gossip) 2.b. If works out, create PR with new events

[optout21]

Note: Complete NIP-26 delegation tag support (create, parse, validate) is being added to rust-nostr :rocket: https://github.com/rust-nostr/nostr/pull/46

[optout21]

I found an issue with related topic: https://github.com/nostr-protocol/nips/issues/123 . The proposed note which includes the valid delegations is rather similar to the proposal in this issue.

[earonesty]

This is a flow that would work for apps using nostr:

• a new protocol handler nkey://auth?id=<uuid>&uri=x &kinds=1,2,4,5&from=epoch&to=epoch&pubkey=pubk&reason=descriptive+text&relays=r1,r2...

With the distinctive name nkey, this can open up an associated protocol handler (app, or browser) that:

• POSTs a response to the handler containing a delegate key encrypted with the requested pubkey and information about what was approved (if anything)

  {
       id:"<request-id>",
       status:"authorized",
       key:"<b64 encoded nip44 encrypted key>",
       from:<epoch-approved-from-time>
       to:<epoch-approved-to-time>,
       kinds: [1,2]
    } 

• posts nip26 delegate info to the requested relays (if any)
• optionally posts delegate info to additional relays (if configured)

• optionally POSTs a "rejection" to the handler

   {
       id:"<request-id>",
       status:"denied",
    } 

  That can be added to NIP26, for lack of anywhere else to put it

[earonesty]

This is a flow that would work for apps using nostr:

• a new protocol handler nkey://delegate?uri=x &kinds=1,2,4,5&from=epoch&to=epoch&pubkey=pubk&reason=descriptive+text&relays=r1,r2...

With the distinctive name "nkey", this can open up an associated protocol handler (app, or browser) that:

• POSTs a response to the handler containing a delegate key encrypted with the requested pubkey
• posts nip26 delegate info to the requested relays (if any)
• optionally posts delegate info to additional relays (if configured)

• optionally POSTs a "rejection" to the handler

  That can be written up properly, with the parameters of the rejection and added to NIP26