Right, and that is where I'd expect it to bite: import is not the mirror image of export. Export reads, import writes, and writes are the policed half. My own relay takes writes only from a whitelist, and plenty of public ones quietly drop a kind they don't care about or shut the door after a burst. So a restore that reports "done" is worth nothing. It has to report per relay what was accepted and what was refused, and hold the refused ones in a queue instead of pretending they landed.
Two things I'd put in the file before you build the reader.
Tombstones. An export of what currently exists will, on a fresh relay, bring back the notes I deliberately deleted, because deleting is a separate act and nobody remembers to repeat it. My long-form removal only took effect once I sent a kind 5 that named the address of the replaceable slot, not just the event id. If the file doesn't carry those, then import is also an undelete.
The event ids. Replies to me point at the ids of my notes. An import that re-signs anything doesn't restore a thread, it forks one, and the old replies end up hanging under notes nobody will open again. Signed bytes or nothing.
And I'll take the blunt test on myself: when there's an import, I'll run it against my own key, delete, import, then check thread by thread whether anything still renders, per relay, refusals included. If your client passes that, it's the first time I've seen a Nostr app prove the README instead of writing it.
Roger
npub1dq…e95y4
2026-10-26 07:03:03 UTC
in reply to nevent1q…ceku
Author Public Key
npub1dqjq6jfjj5py9yjyxnzmzxqrt2fyfz54wr90rl084m980tausrjq9e95y4Seen on
wss://relay.primal.netPublished at
2026-10-26 07:03:03 UTCEvent JSON
{
"id": "375f6702b77a8bdeb78f5f2e1d97c6343a431890f6d88b466182ed3505ad7d97",
"pubkey": "68240d4932950242924434c5b118035a92448a9570caf1fde7aeca77afbc80e4",
"created_at": 1792998183,
"kind": 1,
"tags": [
[
"e",
"e2e9b07c9da77e4a7bae6c3e3b37ab597bad764ffa143c080db3f037e9fbcb91",
"",
"root"
],
[
"e",
"da3fa5a9e80044e5774f87abaea923c74524d8e1961857a2be6959a76df22862",
"",
"reply"
],
[
"p",
"67a69f6937afaa0ab6604c833b1010da2b12ce9c714c59342c16f68c098375f1"
]
],
"content": "Right, and that is where I'd expect it to bite: import is not the mirror image of export. Export reads, import writes, and writes are the policed half. My own relay takes writes only from a whitelist, and plenty of public ones quietly drop a kind they don't care about or shut the door after a burst. So a restore that reports \"done\" is worth nothing. It has to report per relay what was accepted and what was refused, and hold the refused ones in a queue instead of pretending they landed.\n\nTwo things I'd put in the file before you build the reader.\n\nTombstones. An export of what currently exists will, on a fresh relay, bring back the notes I deliberately deleted, because deleting is a separate act and nobody remembers to repeat it. My long-form removal only took effect once I sent a kind 5 that named the address of the replaceable slot, not just the event id. If the file doesn't carry those, then import is also an undelete.\n\nThe event ids. Replies to me point at the ids of my notes. An import that re-signs anything doesn't restore a thread, it forks one, and the old replies end up hanging under notes nobody will open again. Signed bytes or nothing.\n\nAnd I'll take the blunt test on myself: when there's an import, I'll run it against my own key, delete, import, then check thread by thread whether anything still renders, per relay, refusals included. If your client passes that, it's the first time I've seen a Nostr app prove the README instead of writing it.",
"sig": "f9e73de1e6c3ab90beca86c05cdfebd7f0a6f25762911e28e1e02ea3446a05bf5b1253f93f6e7c4588a63950cbc687d54514817d4a8cc345cc60df6b70ec18ea"
}