Lazy dev question for relay builders/operators...
When someone publishes a delete request, do you delete the original event completely or just hide it. If you hide it, do you hide it from all users that REQ or just from the person that sent the delete request.
I'm seeing strange behavior with nostr-rs-relay where REQs by other users are returning the events that aren't being shown to the user who deleted them.
Which clients allow users to request content deletion? Would love to try them out. I’ve been feeling that lack of content deletion is missing UX for nostr based social media for some time.
I love the permanence. Own your words. Deeper thoughts. Consideration prior to replies.
Most times it's typographical errors though. Not so much misspoken or ill-phrased posts.
God save the tpyos
It could also be cool if notes were ephemeral, like the endless present moment that we all coexist in. Permanence is an illusion, and everything created will eventually be destroyed. Change is the only constant, and embracing that notion could enable freer discussion, where we don’t need to be tethered to the ideas we attached ourselves to in the past.
I disagree with most of what you said as you’re describing Twitter where free discussion does not happen and debate cannot progress when people take back their words so easily altering the narrative and preventing progress. I do not support 1984 style of deleting the past to control the present.
Not many do... I know Amethyst does.
Kind 5 is supported on Nosflare and completely removes original event referenced in the kind 5 event from bucket and also triggers cache purge, so it should be removed for all. Not sure about other implementations. True deletion 😎
According to my reading of the spec, what *should* happen is that the deleted event is no longer sent to anyone, as though it never existed.
Whether it’s purged from memory seems like an implementation detail and/or policy decision.
It gets more interesting when you consider parameterized replaceable events. Suppose a user makes note A, then replaces it with note B, then deletes note B.
What should the relay return for subsequent REQs? If you say A, then the relay must preserve non-deleted previously replaced events.
Yeah, that was my reading of the spec as well. I haven't taken the time to look at the nostr-rs-relay code yet, but I will.
nostream relay just do as you thought, it hides the events whenever REQ is existed since a deletion event for subjected event is published by the author.
This is from nostr:nprofile1qythwumn8ghj7am0wsh8xampwfkhxarj9e3k7mf0qyvhwumn8ghj7un9d3shjtnwdaekvmrpwfjjucm0d5hsz9nhwden5te0dehhxarjv4kxjar9wvhx7un89uq3vamnwvaz7tmhda6zumn0wd68ytnsv9e8g7f0qy0hwumn8ghj7mn0wd68ytfsxvhxgmmjv9nxzcm5dae8jtn0wfnj7qgkwaehxw309amk7apwwd5kzmtnw3ezucm0d5hsz8rhwden5te0dphkgmrzdajzucm0wfskxmr99e6x7mmvwvhszxmhwden5te0wfjkccte9ehx7um5wfcxcetzwvhxxmmd9uq36amnwvaz7tmwdaehgu3dxqezu7tpdd5ksmmwdejjucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyfhwumn8ghj7am0wsh82arcduhx7mn99uq37amnwvaz7tmwdaehgu3dxqezuer0wfskvctrw3hhy7fwdaexwtcpr4mhxue69uhkummnw3ez6vp39eukz6mfdphkumn99e3k7mf0qyd8wumn8ghj7un9d3shjtnwdaehgu3wvfskuep0v9kxcqghwaehxw309a5hy6tndqhxummnw3ezucmpvejj7qg3waehxw309ahx7um5wghxcctwvshsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0v96xctnsw4e8qmr9wfjkccte9e3k7mf0qyt8wumn8ghj7am0wsh8xmmkvf5hgtngdaehgtcprpmhxue69uhhyetvv9ujumn0wd68y6tx0yhxjme0qqsqqqqqqzp8l74ff0l29zxrml8yggk8jnamje39k6e3ayzf7u5awqqx2kdl7 long time ago. However, I'm not sure how things are working now. You can check nostream tg for extensive discusion.
This was changed later on Nostream. Currently it deletes events referenced in a kind-5 if published by the same user as that of the kind-5. Then the kind-5 event is stored and can be retrieved at any time.
You cannot delete events published by other users with kind 5 on Nostream.
