Repo v3 rev is required to be current time?

[snarfed]

Hi again! Rereading the repo v3 docs, this jumped out at me:

Recommend using current timestamp as TID; rev values in the "future" (beyond a fudge factor) should be ignored and not processed.

If PDSes, BGSes, and AppViews "should ignore" rev values in the future, it sounds like a requirement that rev is the current time when a commit is constructed, modulo clock skew/fudge factor, or maybe in the past, but not in the future or otherwise arbitrary. Should that req't be made more explicit?

[bnewbold]

It's a bit subtle. They aren't required to be the current time, though we imagine they usually will be, because that is simplest.

The semantics needed are:

• rev for a repository (DID) always increases
• downstream services should remember the rev for each DID and reject any commits which have a rev lower than the last seen
• if an account migrates in a messy way (old PDS caught on fire), new PDS needs to chose a working rev somehow

It is allowed to start from zero and increment one for each commit. However, you can only do this once ever for a repo: if the PDS burns down and you try to start from zero again, the BGS will ignore you.

If you chose MAX INT or something near it, that would prevent any future commits (because they would roll over or not be possible). This would sort of destroy the identity/repository from the perspective of the network. The "no future timestamps" (beyond a couple minutes for clock drift and bursts of commits) is indented to prevent this kind of broken-ness.

Choosing a rev as the current timestamp at the PDS resolves a bunch of these issues. But we didn't want to go all the way and encode or require them to be timestamps, because folks might depend on those semantics and things would get weird (we already have a lot of timestamps in the system, and basically none are reliable/trustworthy).

Maybe the PDS just takes a timestamp when the account is created/migrated and then increments? Up to the PDS implementation (for now).

[snarfed]

Understood! Client-provided timestamps definitely make things entertaining, even if you assume mostly naive/benevolent clients and not Aphyr style threat model of strobing the system clock or some other mischief.

[snarfed]

The first time I read the last paragraph of https://atproto.com/specs/event-stream#sequence-numbers :

In some catastrophic failure modes, or large changes in infrastructure, it is possible that a server would both data from the backfill window, and need to reset the sequence number back to 1. In this case, if a client re-connects with a higher number, the server would send back a FutureCursor error to the client. The client needs to decide what strategy to follow in these scenarios. We suggest that clients treat out-of-order or duplicate sequence numbers as an error, not process the message, and drop the connection. Most clients should not reset sequence state without human operator intervention, though this may be a reasonable behavior for some ephemeral clients not requiring reliable delivery of every event in the stream.

...I over-interpreted it as, if you want to reset a sequence number, just do it, and return FutureCursor to subscription requests with the old next cursor, and those subscribers should reset their internal cursors - and probably discard their corresponding commits for your repo - to match.

The second time I read it, I realized I'd entirely missed the "We suggest..." sentence that said basically the opposite. Fair enough!