Ah I thought it was not actually deleting because you can’t make sure all relays would overwrite?
Discussion
Relays will just keep two events in a deletion context… the original message, and the deletion event.
It’s up to clients to make the event disappear once it gets the deletion event.
Maybe some smarter relays might directly remove the original event. But as far as I know, they’re supposed to be dumb, so… not expecting that.
You can't call it delete if somebody can keep a copy of it.
It's just misleading UI. Not cool.
Oh, you’re right…
Looking at https://github.com/nostr-protocol/nips/blob/master/09.md
The specs says: “Relays SHOULD delete or stop publishing any referenced events that have an identical id as the deletion request. Clients SHOULD hide or otherwise indicate a deletion status for referenced events.”
No deletes on the internet 💯
Just because it’s not possible to be sure something got deleted, doesn’t mean that we shouldn’t be designing systems that are immutable. Users should be able to request their own content be deleted, either with a new message, or setting the expiration. Well behaved relays should respect that, and actually delete instead of just leaving it up to the client which might only get a partial feed and miss the delete message.
There will DEFINATELY be relays and bots which craw the network and archive things. But in the normal flow of the app, most users, will stop seeing and hosting content the original poster wanted to remove. It will take it out of normal circulation on the nostrverse and while not perfect, is important.
Of course, an “archiving relay” actively connected to a relay’s global feed where the original message has been sent would make sure the deleted message stays permanently in its books.
definitely *
:D
F’ing hell 😂 This typo shall be inscribed in relay caches foreva!
now you know how scary this thing can get!! :D
Unless editing becomes the standard - it will be a whole topic... i mean editing 5% of characters - OK
"editing" an entire message to mean something else is more dubious. Perhaps readers should vote whether to accept or deny an edit! :D
I could see a NIP for edits happening 🤔
Probably worth while exploring and keeping the edits as a non-1 kind
been thinking about this for months/years with Twitter - a nice solution would be for clients to indicate an edit took place with a % number inside that icon saying how MUCH was edited :D
Yeah, much like deletes, it’s an entirely separate event that clients are free to process as they wish; the logical UI would be to show the edit history
Let's go! :)
As NIP-33 already defines replaceable events, wouldn't it be easier to just define a new kind for simple notes but that are replaceable?
Would probably also be better for backward compatibility?
That’s not backwards compatible though; that’d mean that we need to stop using kind 1 for these notes.
Plus, for editable notes yo want them to NOT be replaceable otherwise you lose history.
Deletions on the internet are just like exchange withdrawals.
Requests.
Nothing more.
You ask for a deletion, you might get it you might not. Just like 🌽 on an exchange.
It’s ok for the protocol to support sending the request, but calling it a deletion is a lie. 🤷♂️
Technically no, but technically most people who *need* to delete are being harassed by a gang or stalked by an ex or extorted by local popos in a small country w/o the sort of visibility you're talking about.
The need to pull your content out of just popular circulation in those instances can be lifesaving. I've had to do it twice.
I’m sorry to hear that. Nostr does support delete requests, the argument is that that’s all it is, a request: once you put something out there you have no longer control of who made a copy, took a picture, memorized it, etc.
This debate has already been had on Mastodon and the conclusion tends to be that it usually works well enough to implement it, though it’s not 100%
Haha, I love your display name. Very pertinent to this context 🙌
Yes, but since delete requests are in the very baseline of spec I wouldn't call relays who willfully ignore it "Nostr relays", by definition, any more than if they broke protocol with a different JSON blob.
I guess all we can do is name, shame and avoid them.
Maybe, but nothing would prevent anybody, including the victim here, from using those relays in a nostr client without knowing that fact