100%

I've discussed this with fiatjaf, and he argues that nip-26 delegation token revocation can't be guaranteed;

I still think it should happen:

* nIp-26 delegate key to a new pubkey

* if pubkey abuses, delegator creates an opentimestamped event revoking and blasts the revocation to all known relays

* if delegatee continues to abuse delegator has timestamped proof that abuse was not authorized by the delegator

Reply to this note

Please Login to reply.

Discussion

furthermore, we need nip-26 to be extended to allow scoping the token further

right now we can only limit created_at and kind

we should have the capability of scoping `content` (https://github.com/nostr-protocol/nips/pull/222) and `tags`

Well, I didn't say NIP-26 is ideal. :) Delegation that is only valid for a limited period of time might be better; OTS+random beacons can likely help that.