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

> 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?

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.