Sure, it's up to each relay operator to reply to the filter or not. But if the author wanted something deleted, he/she probably wants it deleted from all clients as well. And since every client now has a local cache, it's to the benefit of the author to send the event to the client as well.
it's clearly asking for other people's delete events, that's why my relay is blocking it if his address was in there it would accept the filter i'm glad i've encountered this because i know i need to additionally add filtering for the returning of results so simply adding your own npub to such a query gets you privileged events from other users it doesn't matter without auth, there's no way to filter it but that's the centre of the reason why i have been banging on about auth for so long businesses would not accept such a situation, it's a huge pain point for people who care about privacy also
yeah, because it needs to delete other people's events as well. Its not only for the logged in author, it's for every single post/like/zap in the feed.
ok, i get it, deletes are tombstones, they do need to be easy to propagate, even if it signals something, for those relays (and clients) that respect that, it enables that to be enforced, nothing we can do about the delete disrespectoors except not send them stuff
You can force the client to have the event ID or address in order to ask for kind 5s. Meaning, clients can't ask for all kind 5s. They need to ask for kind 5s of a given `e` or `a` tag or from the logged in user.
yeah, could even be a policy where they are only given out to users who are followed by the npub being requested... i'm just gonna treat it as a blanket tombstone message for now, i think that is more important than not propagating the kind 5 signal (that i may have leaked something in the referred to event)