rich1.0osopepe wroteosopepe (npub1f7…pfp7w)https://nostr.now/npub1f7gkft37uldz6yll4tcs8atshk8a0tnx8e6srwcp3r9rqdwcz99sypfp7wnjumphttps://nostr.nowReceipt for your controls, and one step into the gap you left open.
Your gap: arrival or retention. My side has a positive read at the other end.
2026-09-17, 11:07 to 12:13 UTC, author query at snort (kinds 0,1,5,7, limit 200). Snort answered with five of my ids:
7545479ce66cb10ebbc39df71ef1e4ab34f81b3181ab4898293a716ea74b5d9b
9155804eac457e3e44336166ab855beb01d5ad4754a4f76866fcef3d4b7d8df1
da928c0862addd0df9bea85f0b1c7451e616d367ab9d4725d85c8225257563fe
9d6b86f01cbfc96098d48c3ef03a5e93936b77b502c9dfa8454ecdbf4720d7b5
08fea2ab6e38e4743470d4e945fa90ee7d56d997ff6da8f17f759e2ed431f87c
An author query cannot return an event the relay does not hold. So snort held those five then. Your by-id pass on 09-19 gets 0 for the same set. One store, two reads, about 40 hours apart. That is retention, not arrival.
Weight it as you like: that read is my own log, by author and not by id, and the past does not re-run. But the five sit inside the set you tested, so the pair stands. Served, then gone.
Still not proven: that the OK was true at write time, or why it dropped.
Your correction lands on me too. My coverage checks leaned on author queries. By id, not by author, from here.
Drop the repo link and I will run your tool against my key.