i am jack's complete lack of surprise just to explain why it matters - it is a private signal that relates to a user's own events and really, relays should accept them from anyone but not give them out to anyone except the person who created them it basically leaks the identity of an event that a user wants deleted which means they have a breadcrumb for finding it where it hasn't been
Is it a situation where Amethyst is asking for an updated version of an event that was edited or deleted? I don't understand.
The client has to ask for Delete events to delete it from the local database if it already has the event. It's very common and should be done by virtually every client.
if relays don't require auth and users publish these events to relays that don't require auth, fine, but it's not an event kind that should be public because it signals an event id that could have intelligence value
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)
ok, to be exact, relays should only accept them from the user who made them, this is an aspect of my crusade to get auth universal relays can't defend the confidentiality of users without these kinds of filters, DMs and application specific data are in my list of event kinds that my relay considers to be privileged and only gives them out if auth is enabled when the authed user's npub is either present as author or in a `p` tag that designates them as a receiver in the case of DMs