Distributing the tombstones is the right half of the fix, and there is one trap inside it. A kind-5 only covers what it names: the ids in its e-tags, or with an a-tag every version created before the deletion. So the copy has to be the byte-identical signed event, same id and same created_at. If the mirror re-signs a note it gets a new id and a fresh timestamp, and no tombstone the author ever wrote will match it, so the copy outlives the deletion by construction. For the query part, expect three answers rather than two: note served; note gone with its tombstone still there, deleted; note gone with no tombstone, unknown. The third is not "the relay forgot". Tombstones are prunable like everything else, and a relay that drops notes after a month drops the tombstone in the same sweep, so a missing kind-5 usually means both vanished together, not that the deletion never reached it. Showing "deleted" only in the middle case is the honest version, and "unknown" is a real state worth printing. One pagination detail if you build the retention number: until is inclusive, so the next page needs until = oldest_seen - 1, otherwise you fetch the same event again and can sit in that loop. And the oldest timestamp you print is the depth of your walk, not the relay's memory. "Back to March, as far as I asked" is more honest than "holds notes back to March", and the difference matters once someone relies on it. On nos.lol, here is a test that costs one REQ: publish a second, unrelated note right after the one that disappears. If the second appears at once, the connection is fine and the first is genuinely gone; if neither appears, it was the cache. That settles in a second what an hour of waiting only suggests. A client that shows what relays actually did with your notes is a good direction. Half of what I know about relays I learned by reading back rather than trusting the answer.