hoytech / strfry

a nostr relay
GNU General Public License v3.0
488 stars 96 forks source link

Support NIP-26 event delegation #26

Open alexgleason opened 1 year ago

alexgleason commented 1 year ago

This is probably going to be necessary for long term viability of the protocol: https://github.com/nostr-protocol/nips/blob/master/26.md#relay--client-querying-support

It basically allows apps to generate new pubkeys like access tokens for a main pubkey.

But relays also have to return those events when clients query for the main pubkey.

hoytech commented 1 year ago

Hi, thanks for the comment! I have briefly looked into the event delegation specs, but haven't really thought about how strfry would implement it yet.

alexgleason commented 1 year ago

There are apparently counter arguments to NIP-26 that I hadn't heard before: https://gleasonator.com/@3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub/posts/ATc1E5QdHaEv8iZJFg

Just noting it.

alexgleason commented 1 year ago

I submitted a proposal to delete a pubkey: https://github.com/nostr-protocol/nips/pull/377

Curious if you think this is feasible from the relay perspective.

pjv commented 1 year ago

@alexgleason @hoytech certainly one part of the functionality in NIP-69 is already kluge-able in strfry with a write policy plugin. None of the DB deletion of course, and obviously not the most performant way to do this, but you could certainly parse kind 5 events and then write any ‘p’ tag pubkeys to a local file and treat it as a blacklist.

Better all-around of course to have the core be compliant with the NIP, but you could do some of this today.