5 ms·
Something I just thought about: On a Last-Write-Wins CRDTs, can I just set my computer's time to like 100 years in the future, and thus make changes that can n
by xmcqdpt2 3y ago
Something I just thought about:
On a Last-Write-Wins CRDTs, can I just set my computer's time to like 100 years in the future, and thus make changes that can never be reverted by anyone?
- dgellow 3y agoWhat I’ve been doing for a personal project is that clients use a local id for their events, and the server adds a timestamp and its own id as soon as it receives them. So a client time doesn’t have any influence.
- nsonha 3y agoTimestamps are written by server, problem solved.
- xmcqdpt2 3y agoSo say I go offline for a day, make a change at 12:00, someone else makes a conflicting change at 18:00, I reconnect at 19:00, my change will take precedence? That seems wrong. Maybe one should take the larger of the server and client times?
- nsonha 3y agoI know nothing about this topic, but the server also has the version id of the last state (that you fetch) before disconnect. Your update can then be placed on top of that version and not some version far in the future when you reconnect.
- jamil7 3y agoA lot of implementations would favour something like a lamport clock or counter instead of a timestamp for a few different reasons. You can tamper with it, and it will increment predictably. You don't really need to worry about timestamps if you're only interested in the relative order of the events in the CRDT.