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

[myieye]

-- 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?

[hahn-kev]

I was just reading the docs for a library similar to harmony. They have an interesting design for determining commits and when to sync them, specifically that the hashes on the commits are used to reflect their parent when they were authored. This could give us the information to figure out what the database looked like for a user when they authored a commit. https://github.com/steida/crdt-example-app_annotated/blob/master/NOTES.md#how-it-works-summary