Yes, that is of course a discussion of definition. But lets say how Twitter has to be able to delete a post, that should be considered here as well. This means the tools to do so technically and organizationally. For instance a filter for relays with certain features such as deletion and not share with other relays etc.
How does nostr accomplish deletion (not hiding) at the moment? Asking because I am very curious to learn (limited IT background). šš»
Your client asks relays to delete. Relays may comply or not. And they also forward your deletion request to clients, which may comply or not. So far I think there is little compliance because these things are a pain in the ass to implement for everybody, luckily they are optional!
once a note goes out to multiple relays, you don't know who is actively replicating those relays, so they'll get everything the relay gets. then, that other entity has all the notes and may never delete them, they can in fact, put up a website that displays "all the deleted content on nostr", therefore, deleting is wrongly worded, because it can never be truly deleted. we simply cannot know, hence, thinking that it was indeed deleted is false assurance and is sure to come bite someone later on. it should be seen more as do_not_serve_this_please, but expect it to still appear somewhere.
Iāve been fighting with a bug on Nostream where deleted notes are still being sent out. Havenāt found what the issue is yet.
Redis cache. This class of bug is almost always caching.
Events are not cached yet. But yeah this would be a good thing to keep in mind when we do
Obviously this is your project and I only spent 5 minutes looking at the code, but maybe this will be helpful? Feel free to ignore, Iām likely wrong.
`DBEvent` has a `deleted_at` field so I searched the codebase for `deleted_at` (https://github.com/search?q=repo%3ACameri%2Fnostream+deleted_at&type=code).
`EventRepository` sets `deleted_at` when marking an event as deleted via `deleteByPubkeyAndIds`.
But then looking at `findByFilters`, I donāt see anything explicitly adding a `AND WHERE deleted_at IS NULL` segment to the db query.
Iām sure Iām missing something but just throwing out what I see.
Thanks.
I have a PR open, but pushed code does not reflect my local staging where I have been trying to fix the bug.
I added a log statement and deleted_at was coming always as null.
I was planning on filtering events after fetching from the DB to not impact performance.
I will probably just delete the event from the DB and drop the deleted_at column since itās an anti pattern.
Oh man that was dumb of me š¬ should have checked the PRs.
Personally I think actually deleting the row instead of a deleted flag makes the most sense for this scenario.
As a user, if I delete an event, I hope my relays will respect that by purging the data (or at least the content). I probably deleted it because it contains info I donāt want out there anymore.
Hm. What about:
- determining a nip, which requires the relays to delete and not share to other relays and have the means to do so.
- informing the user whether the picked relays comply or not.
- implementing a function that only a person using relays that have implemented the nip can also receive a note that has been send with that assumption.
Would that not achieve the effect we are discussing. We can leave out the discussion of someone taking the information and publishing it somewhere else. That happens on Twitter and anywhere else.
No?
nop, once a user receives a note from a relay, there's no asking it back. so if I subscribe to you via relay A, and I receive your note, then when you issue your "delete" event to relay A, I already have your note, and if I then ignore your delete event, there's nothing you and relay A can do and I can send it to relay B that won't delete anything.
Both scenarios do not contradicts my suggestion but are rather the risk anyone has right now also on Twitter.
Actually, in the first of your scenarios the data would be still on relay a when you view it. So it is not stored on your client if I am not mistaken. Deleting it, would still make it disappear, no?
clients can have their own db. they're not "automatically" synced with relays. twitter is different because it's just one client with one harcoded relay, so they control the whole experience on what to serve, but if someone screenshots the tweet, twitter can only try to remove those images, but the content is out there for anyone to see.
