nips
nips copied to clipboard
nostr-protocol
REMOVE command
Proposal for a REMOVE command, so that moderation tools can be relay-implementation agnostic.
Prior discussion: https://github.com/nostr-protocol/nips/issues/1118
why introduce a new command? why not just a kind that implies a relay-admin's action? we'll definitely want more relay admin-commands, introducing a new verb for each seems unnecessary
e.g. kind: xxx, e-tagging event id 1,2,3 and 4 deletes them from the db when sent by an authorized pubkey.
why introduce a new command? why not just a kind that implies a relay-admin's action? we'll definitely want more relay admin-commands, introducing a new verb for each seems unnecessary
I agree with this. Check my solution here: https://docs.soapbox.pub/ditto/nsec/#event-deletions
yeah, I was going to propose using kind 5 actually and then thought there could be push back on overloading the functionality of kind 5, but I think this makes sense
It feels to me like "I have a hammer therefore everything is a nail". We have an event structure, therefore everything must be an event.
Little about this activity requires what an event gives: persistence, sharing with others, time-stamping, signing, etc.... except maybe signing and only if AUTH isn't used.
Everything has to fit into an event-shaped hole. And to me, the proliferation of unnecessary events is clutter.
But yes, if protocol extension is not possible, then this can be done via events. Just not my preference.
But if we are going to do this with an event, let's make it an ephemeral event not a kind 5 which propagates and tells others on other relays about a deletion which in this case would be invalid (signed by the wrong author).
Many relays in production today already have keys to control themselves (sending invoices via DM, publishing a signed DNS record, etc). Alex's idea would fit in nicely. We can make a NIP-46/47-like protocol to control the relay via events.
And because these events are public, people can check what the relay owner is deleting/censoring by just querying the key.
It feels to me like "I have a hammer therefore everything is a nail". We have an event structure, therefore everything must be an event.
Look at kind 5 events as they are. It's an event the user submits to the relay asking the relay to delete their event. It's not a different verb. The only difference between a user deleting an event and an admin deleting an event is who is doing it. It's simpler and more consistent to use a pattern similar to what already exists.
And because these events are public, people can check what the relay owner is deleting/censoring by just querying the key.
Agree with this. Admin deletions should be transparent. Then it can easily be viewed in a relay-admin UI. Win-win.
There is really no harm overloading kind 5's either. Queries for kind 5's will always contain either ids or authors.
It feels to me like "I have a hammer therefore everything is a nail". We have an event structure, therefore everything must be an event.
Look at kind 5 events as they are. It's an event the user submits to the relay asking the relay to delete their event. It's not a different verb. The only difference between a user deleting an event and an admin deleting an event is who is doing it. It's simpler and more consistent to use a pattern similar to what already exists.
And because these events are public, people can check what the relay owner is deleting/censoring by just querying the key.
Agree with this. Admin deletions should be transparent. Then it can easily be viewed in a relay-admin UI. Win-win.
There is really no harm overloading kind 5's either. Queries for kind 5's will always contain either ids or authors.
Agreed with everything @alexgleason said here.
Look at kind 5 events as they are. It's an event the user submits to the relay asking the relay to delete their event. It's not a different verb. The only difference between a user deleting an event and an admin deleting an event is who is doing it. It's simpler and more consistent to use a pattern similar to what already exists.
This isn't true at all. A kind-5 event is a proper event, spread between all parties on the network, to remove an event from everywhere, signed by the original event author authorizing such an action.
A relay admin cannot delete other people's events with a kind-5 event, and such an event has no force in any other jurisdiction, such an event clutters things, and such an event being persistent and copied to other jurisdictions appears to be abuse, an attack, and people might sanction such an admin who is trying to delete other people's events illegitimately.
Furthermore, this STILL is a "we must use events for everything" false belief that nobody seems to be reexamining. It's akin to the situation that once port 80 was used for www, all the other unix ports were no longer used, everything had to be forced over port 80. I don't know why humans behave this way.
I'm fully in favor of relays having pubkey identities. But that doesn't allow someone to delete someone else's event with a kind-5.
Let me make the distinction a bit clearer. Events are transmissible things that flow around the nostr network, notes transmitted through relays. What I'm proposing is not something that should flow around the network. So it doesn't make sense to me to shoehorn it into an event, despite prior art by various people who did similar things.
In fact I really don't want people seeing that I removed their event from my relay. I'm supposed to create a digitally signed event that proves I did it? Fuck that.
I'm just going to go around nostr and delete events from my relay using a different protocol. And you guys can do whatever, I don't really care. I just thought we could share tooling, but I guess we can't.
I understand your concerns and how ["REMOVE"] can be clearer, but to me it seems less practical and harder to get compatibility across implementations, thinking above how many other commands we would have to add in order to get a full admin dashboard for a relay, like ["BLOCKIP"] or ["INCREASEPRICE"], I don't know (silly examples, but you get the point).
I think it is implied in the suggestions above that events that are to be treated as "commands" should probably not be kept or at least not returned in queries or forwarded to other relays, they can just be received by one specific relay, acted upon, then deleted.
It's fine. I closed the PR. But this issue is non-negotiable on my end. I will not be digitally signing such commands which might leak in the case of a bug. I'll just add undocumented non-standard private extensions.