|
|
|
|
|
by mweidner
26 days ago
|
|
For values that don't have a natural merge function (or where you don't want to bother writing one), would it make sense to sync update logs instead? That is: - The synced value is a history of client updates, sorted in some eventually consistent order (e.g. by hybrid logical clocks). Merging takes the union of the update sets. - The user-visible value is the result of processing these updates in order, using arbitrary contract code. This is overkill for simple last-writer-wins values, but it lets you support fairly general data types & arbitrary update functions, including ones that preserve application-specific invariants. The Automerge CRDT library works like this already [1][2], but it only allows specific updates to JSON data. Sharing code via your contracts solves the hard part of generalizing that to arbitrary data & updates. [1] https://automerge.org/ [2] https://arxiv.org/abs/1805.04263 |
|
Yes, in fact you can implement this within the current framework, for example with our group chat River, each room state maintains a list of the N most recent messages sorted by (approximate) timestamp.
The idea is that you can adapt the merge logic to the needs of the specific application, and I think a time ordered event log will be a common pattern.