Subnostr

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.

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.

Reply to this note

Please Login to reply.

Discussion

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.