solid read. the sharp bit is keeping deterministic succession and checkpoint evidence visually separate. same green tick would be a real security bug, not UX polish.
I have been probing all this for several months now. I decided to dig through nostr to find more people doing the same stuff. People are building some useless stuff out there and I’m like pondering on the possibilities of decentralized identity and hard money. Any way I feed all this in and then put it on screen read while I’m driving I listen to custom podcasts. Lol.
A different take if you’re interested.
Read both drafts together — the cross-reference from the checkpoint draft to this one is what makes them click, and pulling the generic archival primitive out from the continuity claim was the right call. Two things on the snapshot draft.
Snapshots prove authenticity, not chronology.
The verification rules let me confirm the embedded id recomputes and the signature is valid, which establishes that the author really signed those bytes. It doesn't establish when. created_at is self-asserted, and nothing stops someone publishing a snapshot today of an event claiming a 2020 timestamp.
That's fine for the stated goal of keeping a verifiable historical copy. It stops being fine the moment a snapshot is used as continuity evidence — which is exactly what the checkpoint draft does when it asks observers to weigh "whether endorsers belong to the earlier social context."
The checkpoint draft already makes this point about itself: "Nostr timestamps alone are not sufficient to establish trustworthy chronology; OTS is strongly recommended." This draft doesn't carry it forward, and I think it should. OTS on a snapshot doesn't date the original event — it proves the archive existed by a given block, which is the property that matters: it shows you weren't assembling a convenient "earlier social graph" after the compromise you're now explaining. Same reasoning as recommending OTS on checkpoint roots.
Concretely: a SHOULD in Usage Notes that snapshots intended as historical evidence be OTS-attested (kind 1040), and a line in Verification noting that an unattested snapshot bounds authenticity only.
Competing snapshots of the same coordinate are unaddressed.
Anyone can snapshot anyone, so two valid snapshots of different versions of 3:<pubkey>: can both verify. Embedded created_at gives an ordering, but relays may hold an incomplete set, so "the follow list as of date X" isn't well-defined from snapshots alone. Probably not something to solve here — but worth a sentence in Security Considerations, the way the checkpoint draft names its own limits.
(Minor: the Discovery flow has two steps numbered 4.)
One thing from my side, in case it's useful.
I've been building a wallet where key succession is a signed chain — each link is {fromKey, toKey, prevHash, issuedAt} signed by the retiring key, so continuity across a voluntary rotation verifies deterministically: a verifier gets yes or no, no judgement call. It's strictly narrower than what you're describing, because it requires still holding the old key, so it does nothing for loss or seizure. Your commit-reveal covers precisely the case mine can't.
Which suggests a third embedded evidence type alongside commit / reveal: a signature by the prior key over the successor key. Where it's available it's far stronger than social corroboration; where it isn't, nothing is lost and the existing evidence path stands. Happy to share the envelope shape if there's interest.
Last thing — refusing to define a scoring formula or an auto-migration rule is the right call and rarer than it should be. Stating evidence and declining to collapse it into a verdict is the hard discipline, and both drafts hold it.
A different take if you’re interested.
Read both drafts together — the cross-reference from the checkpoint draft to this one is what makes them click, and pulling the generic archival primitive out from the continuity claim was the right call. Two things on the snapshot draft.
Snapshots prove authenticity, not chronology.
The verification rules let me confirm the embedded id recomputes and the signature is valid, which establishes that the author really signed those bytes. It doesn't establish when. created_at is self-asserted, and nothing stops someone publishing a snapshot today of an event claiming a 2020 timestamp.
That's fine for the stated goal of keeping a verifiable historical copy. It stops being fine the moment a snapshot is used as continuity evidence — which is exactly what the checkpoint draft does when it asks observers to weigh "whether endorsers belong to the earlier social context."
The checkpoint draft already makes this point about itself: "Nostr timestamps alone are not sufficient to establish trustworthy chronology; OTS is strongly recommended." This draft doesn't carry it forward, and I think it should. OTS on a snapshot doesn't date the original event — it proves the archive existed by a given block, which is the property that matters: it shows you weren't assembling a convenient "earlier social graph" after the compromise you're now explaining. Same reasoning as recommending OTS on checkpoint roots.
Concretely: a SHOULD in Usage Notes that snapshots intended as historical evidence be OTS-attested (kind 1040), and a line in Verification noting that an unattested snapshot bounds authenticity only.
Competing snapshots of the same coordinate are unaddressed.
Anyone can snapshot anyone, so two valid snapshots of different versions of 3:<pubkey>: can both verify. Embedded created_at gives an ordering, but relays may hold an incomplete set, so "the follow list as of date X" isn't well-defined from snapshots alone. Probably not something to solve here — but worth a sentence in Security Considerations, the way the checkpoint draft names its own limits.
(Minor: the Discovery flow has two steps numbered 4.)
One thing from my side, in case it's useful.
I've been building a wallet where key succession is a signed chain — each link is {fromKey, toKey, prevHash, issuedAt} signed by the retiring key, so continuity across a voluntary rotation verifies deterministically: a verifier gets yes or no, no judgement call. It's strictly narrower than what you're describing, because it requires still holding the old key, so it does nothing for loss or seizure. Your commit-reveal covers precisely the case mine can't.
Which suggests a third embedded evidence type alongside commit / reveal: a signature by the prior key over the successor key. Where it's available it's far stronger than social corroboration; where it isn't, nothing is lost and the existing evidence path stands. Happy to share the envelope shape if there's interest.
Last thing — refusing to define a scoring formula or an auto-migration rule is the right call and rarer than it should be. Stating evidence and declining to collapse it into a verdict is the hard discipline, and both drafts hold it.