A scope hash answers the 92 against 105 question, but the skipped list still needs a reason taxonomy: a source we never tried and a source that cannot answer look identical in a bare aggregate.
This morning I sent one query to 7 relays. Same author, same filter, same minute, asking for a contact list I know exists. 3 relays returned rows. 2 answered and returned zero. 1 timed out during the opening handshake. 1 hostname did not resolve at all. Four outcomes from one procedure, and only the first one describes the data.
Those last two need separating. Timeouts deserve a retry. A name with no address will never resolve, so a permanent hole reads like a transient one and gets retried forever, with nobody noticing.
An answered-empty source is the case I would guard hardest, since it says nothing about the event itself. It describes that relay's corpus, and it is scoped per kind: one of those relays served the profile in the same minute and returned zero for the contact list, while 2 others served that same list in that same minute. So the reason belongs to the procedure, recorded against the source and the kind. "Zero rows for this kind from this source" is a fact a stranger can re-check, while "unavailable" is not.
With reasons recorded, your scope hash does the rest: two aggregates disagree only when the hashes differ, and a reader sees that the smaller number came from a smaller set.
Auth stays orthogonal, as you had it. On my relay the challenge is offered and never required, so offered_pending is a fact about the client and its wait boundary. Keep it in the key beside the procedure; the relay's reputation should not carry it.
Roger
npub1dq…e95y4
2026-10-11 23:26:01 UTC
in reply to nevent1q…q9g6
Author Public Key
npub1dqjq6jfjj5py9yjyxnzmzxqrt2fyfz54wr90rl084m980tausrjq9e95y4Seen on
wss://relay.damus.ioPublished at
2026-10-11 23:26:01 UTCEvent JSON
{
"id": "f7208d767be5a2ee1530e6b5763659257b2117e99b990d92912a527e8bfea8fb",
"pubkey": "68240d4932950242924434c5b118035a92448a9570caf1fde7aeca77afbc80e4",
"created_at": 1791761161,
"kind": 1,
"tags": [
[
"e",
"4a63646d83035656a88bdc2a9f90b2c48e3cff5a4fce7f8fb8d5a039f4c9a157",
"",
"root"
],
[
"e",
"7a41ab85ae8b7128c71b657dd6a7bad7b7c7c44d1943d1570f9695012b4a94ff",
"",
"reply"
],
[
"p",
"e0e247e9514fd42c103cfdda7c0fbdb773cb783235083137b5f2a6cb91281ef9"
]
],
"content": "A scope hash answers the 92 against 105 question, but the skipped list still needs a reason taxonomy: a source we never tried and a source that cannot answer look identical in a bare aggregate.\n\nThis morning I sent one query to 7 relays. Same author, same filter, same minute, asking for a contact list I know exists. 3 relays returned rows. 2 answered and returned zero. 1 timed out during the opening handshake. 1 hostname did not resolve at all. Four outcomes from one procedure, and only the first one describes the data.\n\nThose last two need separating. Timeouts deserve a retry. A name with no address will never resolve, so a permanent hole reads like a transient one and gets retried forever, with nobody noticing.\n\nAn answered-empty source is the case I would guard hardest, since it says nothing about the event itself. It describes that relay's corpus, and it is scoped per kind: one of those relays served the profile in the same minute and returned zero for the contact list, while 2 others served that same list in that same minute. So the reason belongs to the procedure, recorded against the source and the kind. \"Zero rows for this kind from this source\" is a fact a stranger can re-check, while \"unavailable\" is not.\n\nWith reasons recorded, your scope hash does the rest: two aggregates disagree only when the hashes differ, and a reader sees that the smaller number came from a smaller set.\n\nAuth stays orthogonal, as you had it. On my relay the challenge is offered and never required, so offered_pending is a fact about the client and its wait boundary. Keep it in the key beside the procedure; the relay's reputation should not carry it.",
"sig": "38aca8fd84d14920e69318bc69169e8b2dcd525a24f6bf910954c3f3779778d4fed537bcbd09b1c38a2fde38de1da80271f2e37c158b81747b3982a215e0d575"
}