The point of a delete isn’t exactly to make sure that we can algorithmically prove the content is gone forever for everyone. The point is to actually indicate the person who created it now wants it retracted. Requesting delete is a social signal to say that the creator no longer wants to endorse authorship of this content and retracts it. Most of the time we should honor that social request by removing the content from our servers, databases, and clients. That way new people won’t find the content and thing the author stands by it. Maybe you’re deleting a typo, or a drunken post, or some revenge porn, but being able to say, oops take that down, is important.
The confusion comes when nerds get pedantic and argue that you can’t actually delete anything or be absolutely sure it’s gone. It’s true, but that’s also true of a conversation you have in person, the people there remember what you said. But you can apologize after and say “it is forgotten.” Which doesn’t mean it’s actually forgotten or deleted from people’s memories. More, there is an agreement that it’s been retracted. Someone could have recorded that inappropriate conversation and refuse to honor the retraction, but being able to signal that it’s “deleted” is very important.
What’s more, most clients and relays should honor a user’s request over their own content. If we believe in individual autonomy and self sovereignty then we should respect when users want to retract something they’ve published.
There are edge cases where we have content reports and reposts which include the original content. I think the solution is to simply include a reference to the content rather than embedding it. There are also cases clients retain a cache of the content, and would then need to honor the delete request. In some cases that might be hard but it was easy to implement in nos and I suspect it’s easy if you’re not using an immutable db.
Perhaps folks who are concerned about the completeness of “delete” should update their UI to say “retract” or something similar. But then in your FAQ explain that retraction request’s are a kind of delete but because it’s a distributed system there is no way to ensure it is deleted everywhere.
“Remove” would be OK; then a reminder message can say that it’s only removed from current client. One thing about bad memory is that you actually forget and forgive, that is in that case a blessing.
I kind of like how nostr can forget if the events aren’t kept on relays or backed up. As relays come and go, old events get lost. Only those people want to preseve survive. Most really old tweets just caused people problems.
I think this is really healthy.
Old tweets are like Juha nail, do you know the story? (It’s a traditional Arabic story, you find it and read it in English anyways).
*you can find it. (I really need an edit button!)
I think edit can keep the history of previous versions but we tend to be more conversational here than on twitter so there is less chance if something going viral and then being completely changed. Even if that did happen it would be easy to document and hold the person accountable. Reciepts matter.
The editing can be limited by a certain amount of time. Like within 1 hour from publishing or even a little less.
This is why I don't actually delete renderable events, I just mark the message with strikethrough, put a DELETED message on it, and show the deleted reason (if that was given). This way users can get that social signal of "I retract this", but also users don't feel like they just missed out on something that suddenly was censored before their eyes and come bitching to the developer about censorship.
As it turns out, not actually deleting non-renderable events is a nightmare, so I actually delete those in the client local database.
Oddbean new post about login | logout