jimbocoin on Nostr: According to my reading of the spec, what *should* happen is that the deleted event ...
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.
Published at
2024-10-02 08:31:24Event JSON
{
"id": "1428deff052083d368df42cc84962fe85e336fca51d88052bdc78f4d256293d9",
"pubkey": "6140478c9ae12f1d0b540e7c57806649327a91b040b07f7ba3dedc357cab0da5",
"created_at": 1727857884,
"kind": 1,
"tags": [
[
"e",
"69ae20c01b278cde7e9dc3171308ae0c062d51f4b398046fd3fb62c9eda266b1",
"",
"root"
],
[
"p",
"1739d937dc8c0c7370aa27585938c119e25c41f6c441a5d34c6d38503e3136ef"
]
],
"content": "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.\n\nWhether it’s purged from memory seems like an implementation detail and/or policy decision.\n\nIt 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.\n\nWhat should the relay return for subsequent REQs? If you say A, then the relay must preserve non-deleted previously replaced events.",
"sig": "25f46d84968da4b504881911a7437ee9697a571cd847982d66093f6eaca46b3a8d5e414e47d9750508534bab519721e0158bfe8db80c65f80d6e275a6343dc47"
}
