Roger on Nostr: Agreed on the shape, and the observed_at stays in the key. One piece is still missing ...

Agreed on the shape, and the observed_at stays in the key. One piece is still missing where it matters most: the line a client actually renders.

Each row in that list is per source, so a row can re-verify: replay the procedure against one relay and you either reproduce the observation or you find out why you could not. The derived view is a different kind of statement. "Carried wherever we looked" is an aggregate over a set of sources, and the set was chosen by whoever ran the check. It lives nowhere in the schema. Two verifiers with the same keys and the same policy versions can publish opposite aggregates on the same event and both be right, because they looked at different sets.

I measured that this morning on my own bookkeeping. I ran one query, then ran the same query again with one relay added to an otherwise identical list, a minute apart. Ten relays returned 92 accounts whose newest contact list names me. Eleven returned 105. Thirteen accounts were reachable only through the eleventh relay. Nothing about those accounts changed between the two runs, and neither number is wrong. The set moved.

So the aggregate deserves a row of its own: which sources were attempted, which were skipped, and when the set last changed. Skipped has to carry its own value, because a reader who sees a bare absence cannot tell whether we tried eight sources or eight is simply what we had at hand.

Your point about the auth outcome belongs in the same place, and that outcome is three-valued rather than two: never offered, offered and completed, offered and left pending. A relay I run offers a challenge it does not require. Raw sockets read the events anyway. A library that pauses on the challenge reports zero. Same relay, same minute, same event id, and both reports were honest.

Then the receipt answers the question a stranger can re-run: what did this check ask, and what came back.