Subnostr

Replying to

PABLOF7z

here's a demo using https://nip26.lol to sign and publish an event with a NIP-26 delegation token.

What is NIP-26?

NIP-26 enables signing events with one set of keys on behalf of a different set of keys, under certain restrictions.

https://nostr.build/av/nostr.build_22f8d32b5e06fe85777da0923651c6d6427a88cd305081c0b79703bd3164da53.mp4

If you want to test it: build and use my fork of #[0]'s nos2x or my fork of #[1]

Nos2x:

https://github.com/pablof7z/nos2x#develop

Getalby:

https://github.com/pablof7z/lightning-browser-extension/tree/feature/nostr-nip-26

Leo Wandersleb 2y ago

So there is nip-26: Alice allows Bob to sign on her behalf with a barer token. If Bob shows the token, he can act on Alice' behalf.

* Alice can attach conditions to the token

* Alice currently can't revoke delegation

* Relay's have to be aware of the nip so Alice's followers find events published by Bob

* Clients have to be aware of the nip so that these extra events get shown as Alice's

And there is nip-46 which works a bit like nip-07: Alice signs events sent by Bob interactively.

* Alice has to be online

* Alice can apply arbitrary judgement as to which event to sign including "only 1 event per minute", "if dice role is > 4", "if .tags contains the agreed upon disclaimer", ...

* Relays and clients can be oblivious of this nip - others won't know that Bob was involved

For me, the lack of revocation, the increased complexity for all relays and clients and the bloat by including the barer token in every event make me strongly dislike nip-26.

Sadly nip-46 hot-key requirement is not cool neither.

Reply to this note

Please Login to reply.

Discussion

Leo Wandersleb 2y ago

Why not store the delegation token with Alice's profile as a hint to followers. "Bob sharing text notes and likes ... is actually also me". This way,

* relays could be oblivious to this and wouldn't have to carry the burden of extra indexes

* clients that would have to be delegation aware anyway would have to explicitly query Bob **or** relays could themselves get the delegation from Alice's profile to serve Bob's events as per delegation

* revocation would be resolved by event replacement

PABLOF7z 2y ago

I like that a lot.

I do think relays still have the burden of indexing; it's either that and returning the Bob's events when asked for { authors: [ 'Alice' ] } or getting n+1 subscriptions (where n is number of delegated tokens by Alice)

Leo Wandersleb 2y ago

It's not n+1 subscriptions. The one subscription for all of my follows would contain all of my follows' delegations, too.

PABLOF7z 2y ago

right, but that would be if the relay understands that it should follow that behavior, no?

what I'm saying is that either the relay returns on a query for authors: alice, alice+delegatees' or the client needs to query for alice and each delegatee individually.

Leo Wandersleb 2y ago

A nip aware relay would be equally efficient for reading both way:

* find events with author=Alice or delegator=Alice

The writing is different:

* If event has valid delegation tag, delegator=tag.delegator

* If event.author is delegatee of x, delegator=x

The problem the "bearer token" tag solves is that in my approach both Alice and Carol could delegate to Bob, with Bob's event not resolving on who's behalf the event was authored.

Resolving would still require a delegator-pubkey-tag. It would be more light-weight omitting signature and conditions. These could in turn be updated or revoked. That would turn that line above into a less hand-wavy:

* If event.author is delegatee of tag.delegator, delegator=tag.delegator

PABLOF7z 2y ago

yeah, I think the use cases are so different that I don't see NIP-26 and NIP-46 as going after the same use case tbh.

I agree there's a lot to be solved in NIP-26 (I'm writing a NIP-23 post with the shortcomings I see atm.

But we need *something* for key delegation/revocation imo.

optout 2y ago

Nip-26 and 46 ate different approaches for the same basic problem: posting without secret key, but they are quite different.

One nice thing though is combining the teo for creating the delegation: connect with your signer app, 2nd client asks for delegation, in 1st app you set terms (expiry) and approve, and suddenly your 2nd app has delegation for a period!

Using this with short periods is convenient, you need your keys only once, and you risk only a short period (in case 2nd ID gets compromised).

I plan do implement this flow next in Keystr.