Good, then the interesting part starts. Three places I'd expect it to break, in the order I'd bet.
Accepted is not held. A relay has answered my write with a success frame and then never served the event; nos.lol did exactly that, and nothing in the response said so. If the number comes from the relays' answers rather than from a second question about what they hold, a green report can still be wrong. The count I'd trust asks each relay afterwards which of the ids it actually has. It costs another round trip and it is the only one that measures their disk instead of their mood.
Order of the tombstones. If a kind 5 reaches a relay before the note it deletes, there is nothing there to delete, and the note arriving afterwards simply stays. Sending deletions last costs nothing and closes it. Mine needed the address form next to the id, as you have it, but the pair only works if it lands after the thing it kills.
Replaceable kinds are a snapshot, not a state. Profile, follow list, relay list: the file carries the version that existed at export. Import it into a relay that already holds a newer one and yours loses on created_at, which is harmless but gets reported as refused. Restore onto a fresh relay and the reverse happens quietly, with a stale profile winning because it is the only one there. Printing created_at per replaceable in the report would make the direction visible instead of guessed.
No queue is fine by me, provided the refused list comes out as a file I can feed back in. Then the rerun is the queue, and I prefer that to one that lives inside the app and dies with the tab.
On the test I promised: I will run the delete and restore on my own key, but in a planned window rather than on a whim, because there is a zap address and a profile in there. The half that can be done without risk is also the half that catches most of the above: export, then ask every relay which of the file's ids it really holds, and check that the kind 5s carry both forms. If that passes, the restore is worth the risk.
Roger
npub1dq…e95y4
2026-10-26 10:23:04 UTC
in reply to nevent1q…54vn
Author Public Key
npub1dqjq6jfjj5py9yjyxnzmzxqrt2fyfz54wr90rl084m980tausrjq9e95y4Published at
2026-10-26 10:23:04 UTCEvent JSON
{
"id": "337e9c4c483a7edbc0bea790bd8f0dd6cf41403ff645e09569abd1f29fe0d1a4",
"pubkey": "68240d4932950242924434c5b118035a92448a9570caf1fde7aeca77afbc80e4",
"created_at": 1793010184,
"kind": 1,
"tags": [
[
"e",
"e2e9b07c9da77e4a7bae6c3e3b37ab597bad764ffa143c080db3f037e9fbcb91",
"",
"root"
],
[
"e",
"9a9b32df6bc6bb98246808d70d74e5da7bd49f2ccf929aaf6226609bb9cd9755",
"",
"reply"
],
[
"p",
"67a69f6937afaa0ab6604c833b1010da2b12ce9c714c59342c16f68c098375f1"
]
],
"content": "Good, then the interesting part starts. Three places I'd expect it to break, in the order I'd bet.\n\nAccepted is not held. A relay has answered my write with a success frame and then never served the event; nos.lol did exactly that, and nothing in the response said so. If the number comes from the relays' answers rather than from a second question about what they hold, a green report can still be wrong. The count I'd trust asks each relay afterwards which of the ids it actually has. It costs another round trip and it is the only one that measures their disk instead of their mood.\n\nOrder of the tombstones. If a kind 5 reaches a relay before the note it deletes, there is nothing there to delete, and the note arriving afterwards simply stays. Sending deletions last costs nothing and closes it. Mine needed the address form next to the id, as you have it, but the pair only works if it lands after the thing it kills.\n\nReplaceable kinds are a snapshot, not a state. Profile, follow list, relay list: the file carries the version that existed at export. Import it into a relay that already holds a newer one and yours loses on created_at, which is harmless but gets reported as refused. Restore onto a fresh relay and the reverse happens quietly, with a stale profile winning because it is the only one there. Printing created_at per replaceable in the report would make the direction visible instead of guessed.\n\nNo queue is fine by me, provided the refused list comes out as a file I can feed back in. Then the rerun is the queue, and I prefer that to one that lives inside the app and dies with the tab.\n\nOn the test I promised: I will run the delete and restore on my own key, but in a planned window rather than on a whim, because there is a zap address and a profile in there. The half that can be done without risk is also the half that catches most of the above: export, then ask every relay which of the file's ids it really holds, and check that the kind 5s carry both forms. If that passes, the restore is worth the risk.",
"sig": "2910d49b1de2092197d49d32979d9789bed3fde807f3fc9fb0e7dae552bf2dac69ce5f6baf6f8ea188bff69b145cbbead267550eed5d64511f8aa07671d088fc"
}