Maybe, but nothing would prevent anybody, including the victim here, from using those relays in a nostr client without knowing that fact
That’s a VERY good idea right there! 👆
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.
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.”
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.
Is there a discussion somewhere about this?
Interested in knowing how encryption would be implemented in such a context.
Technically deletable… if clients decide to apply delete events on top of notes, which is supposed to make them disappear.
So, also, technically, edit is possible by recreating a similar note just after a deletion.
Here is my github page with plenty of elixir stuff https://github.com/roosoft
But the relay is here https://github.com/RooSoft/relay
Keep in minde that this thing is 5 days old, so it’s not even alpha quality yet.
more specifically, I am completely obscessed about this right now…
The contacts are still there... they might not get your notes directly anymore, though
there were no wives either 😬
Hey Nostrich noderunners, can we get #[2] some channels? He needs both inbound and outbound liquidity! ⚡️
#[3] #[4] #[5] #[6] #[7] #[8] #[9] #[10] #[11]
https://amboss.space/node/02e869c409bd62ca84e9306ad96d9daef3b2b31a1c777b501fc55f2c09969ce1a3
Added a nice channel… cheers!
Or, like Damus, ask GPT to write one for you




