Nice! BTW how can I trust timestamp?

You currently can’t, and it’s closely related to computer clock time, which is often inconsistent between peers. In early tests on Game of Life peer A’s clock was ~2 seconds behind peer B’s, so peer A’s actions appeared (even to peer A) to have instantly happened 2 seconds ago.

One idea I’m toying with is use a timestamp of “last_known_action+time_since_that_action”. Pros: delta-based, not based on wall clock time. Cons: much more complex ordering strategy required.

Otherwise, Lamport Clocks are the real solution to this and have been implemented in other scuttlebutt models and seem to work rather well, with the drawback that in a concurrent scenario client “A”’s events will take precedence over client “B”’s events simply by the fact that A comes before B in the alphabet. We’d like something a little “fairer” although in a conflict-free action stream it shouldn’t matter.

Thanks for linking Noms, I really like some of their ideas! I’m aiming to keep this as simple as possible while retaining its core utility — a bit like Redux itself. Timestamps, network transport, and all the rest are going to be configurable or pluggable in future, since these tradeoffs change with each use case.

Btw, the only requirement for the timestamps is that they can be consistently ordered among peers. We can ensure clients only dispatch updates with timestamps after their previous timestamp, but can’t do much about people coming back online after seconds, hours, days and replaying old actions.

Like what you read? Give Tom McKenzie a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.