Accounting for dodgy clocks?

[shish]

If a client's clock is out of sync with the server, it'll show things out of sync

Is this a problem in practice? Every phone / laptop / PC these days comes with NTP enabled by default, which should get us to +/-20ms even in the worst case, and more commonly +/-5ms

The client could start the session by calling /clock.json to see the server's current time, and then adding an offset to local calculations if it is off by more than a second or so (if it's off by less than a second, then I would imagine the HTTP network lag is a bigger factor than NTP lag, so we should trust NTP)

[shish]

Testing on real hardware - freshly-sync'ed devices are +/-10ms, but they only sync once per day, and after a day of drifting they can be out by ~200ms D:

[shish]

This got done for player2, I'd like to pull it out into a separate library and use for browser2 too

[shish]

I've created the hyperapp-synced-interval library which will call a given callback function every second, synced with the server clock, and used it in player2 and browser2