[Idea] Record when commits are received (and sent?)

-- As discussed with @hahn-kev this is to document an unfinished discussion about a possible feature --

It's currently impossible to determine what an object looked like on a client at a given time, because we don't track when changes arrive from other clients.

To solve this we'd need to stamp commits with the time that they are received and those timestamps would need to be on the same hybrid logical clock that is used when authoring commits so that they can be accurately compared.

Why might we want to calculate the local state of an object in the past?

• Generally speaking, so it's possible to explain exactly what happened to an object on a user's machine over time
• To show the user a history ordered by when changes were received (by comparing diffs of local state at different points in time e.g. before and after a sync)
• It would make the following API possible SaveObject(object, versionIEdited), because the versionIEdited could be recalculated and compared to object in order to calculate an accurate diff

Other thoughts:

Perhaps stamp both sent and received commits with the same date when a sync happens
(We can always determine which changes we authored based on the client ID)

I think this would be problematic, because we might send changes we received from client A to client B and wouldn't want to overwrite the received timestamp with a sent timestamp.
We could also send our own changes to multiple other clients. A sindle timestamp wouldn't let us record both syncs. So, this wouldn't be equivalent to a Sync log.

Where to save the sync timestamp?

• In CommitMetadata: which is serialized in a single column as JSON. We'd need 2 fields for the hybrid logical clock.
• In a seperate table?

Start by reviewing the sync flow and CommitMetadata serialization described in the issue, then trace how authored and received commits are represented. Determine whether the proposed timestamps belong in CommitMetadata or a separate table, and define how sent and received events would be compared on the hybrid logical clock. Done means the storage model and historical-state behavior are specified well enough to implement and test.