-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support NIP-26 event delegation #26
Comments
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. |
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. |
I submitted a proposal to delete a pubkey: nostr-protocol/nips#377 Curious if you think this is feasible from the relay perspective. |
@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. |
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.
The text was updated successfully, but these errors were encountered: