Thanks for the article! I love lamport clocks, and the lightweight methods are cool.

I read through the article a couple of times, and was unsure about something: When the browser resets, it does not appear to copy down the current state and clock value from the server, right? I'm basing that on this from the article:

  The browser resets, all the state is dropped.
  browser: settings: none, clock: 0
  backend: settings: foo, clock: 2

I don't think that lamport clocks can be compared if they are not representing any concept of causality or knowledge, right? This implementation appears to be two separate integers (one for the client and one for the server), with no guarantee as to their ability to communicate with each other. One bug you discovered was that the server might have a value 2, and the client might have a value 2, but they would disagree on the state that value "2" referred to. A bug indeed! Your fix was to handle the case where the client and server tied. However, I was left wondering: What about the case where the knowledge of the client is higher than the server, but the server still should not trust it? What if, in your example step 4, the client had made 3 changes without the ability to sync with the server? It would be this:

  The user changes the settings three times, but this time the state is not propagated to the backend (e.g. due to network hiccups).
  browser: settings: none, clock: 3
  backend: settings: foo, clock: 2

In that case, by the time the client talks to the server, the server would think that the client had "won", but the fact that the client had a clock value of "3" would be meaningless, right? Wouldn't you still want the server to win in this case?