I've come around to this position. For a long time I was a delete purist, but I agree it's important to be able to delete. A term like "tombstone" captures the intention better I think, since it's possible to prove a person said something and also that they retracted it. Relays and clients should respect delete, but also communicate to users what the limits actually are.
I’ve seen so many people say they won’t use Nostr because we don’t support delete. This is really frustrating, because Nostr DOES support delete, it’s right there in the NIP’s! We’ve got delete in nostr:npub1pu3vqm4vzqpxsnhuc684dp2qaq6z69sf65yte4p39spcucv5lzmqswtfch, but most apps don’t expose the functionality to users because they either don’t like the idea of delete or can’t be sure that something is 100% deleted. That misses the point, delete is as much about social signaling as it is about getting rid of the content.
Here’s my argument for how we should think about and support delete in nostr. In case your client doesn’t support long form content, here’s the njump link: https://njump.me/naddr1qq2ksje3g9trxujpxymyxjjlg5ckjmmrtguyxq3qpu3vqm4vzqpxsnhuc684dp2qaq6z69sf65yte4p39spcucv5lzmqxpqqqp65wk06e7u nostr:note1hldm4z430w76dn2ywzwjnafytnvyt7gsg6nhk3l8a3x8utzl88asl06u8m
Discussion
😂 tombstone? And you thought my names were bad lol
I didn't invent the name, it's been suggested before
it's been around for a long time, apache cassandra is the first mention in this wikipedia article, circa 2011 https://en.wikipedia.org/wiki/Tombstone_(data_store)
funny that you think you know about distributed systems and you never heard of tombstones
There is no such thing as “delete purism” unless the data only existed on your local drive. And even then 🤔…
nostr:note134w9drtptqyl75q4mvz5fqf35jc7ak5f4v7379tnwuqvrr3rxx3swrpdyz
Exactly
it is a core principle of signals intelligence that once the message goes over an untrusted channel it is likely captured
but that still doesn't stop people from respecting this anyhow
it's one of the benefits of a network protocol like LN, it isn't broadcast so the chances of a delete request being respected are higher at being successful on such a channel, the majority of channel rebalances are discarded after they are no longer able to be applied
Rabble and co are doing a job in convincing me as well. I like the term retract.
Allow me to challenge.
A unique characteristic about nostr relative to twitter is that the note lives on in one or more relays, and local client databases.
So if a note has been published across various machines, and we are optimizing for user choice, should the nostr user on the receiving end of the note have the option of honoring (or not) deletion requests?
Your ambitions to be a North Korean dictator are kind of cute but in the real world the user decides what choices they have.
I think that’s what occurs, nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 correct me if I’m wrong. nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 I’ve used the delete feature on nostr:npub1pu3vqm4vzqpxsnhuc684dp2qaq6z69sf65yte4p39spcucv5lzmqswtfch and it’s worded in such a way that the relay owners are being asked to delete the note. Based on the current wording, it doesn’t sound like nos is promising (nor would
It make sense that they could promise) the relays will actually delete it.
To that end though, I think it’d be cool if there were a way to let the requestor know which relays didn’t choose to delete as requested. It would help the requestor determine if they want to continue to use that relay or not; keenly if it’s one they pay into.
Yes, if you assume clients don’t store notes long term, then it comes down to relay choice.
What do you think nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240
https://github.com/damus-io/damus/issues/14#issuecomment-1934529926
I added a comment