[hecturchi]

In https://github.com/ipfs/go-ds-crdt, every node in the Merkle DAG has a "Priority" field. When adding a new head, this is set to (maximum of the priorities of the children)+1.

Thus, this priority represents the current depth (or height) of the DAG at each node. It is sort of a timestamp and you could use a timestamp, or whatever helps you sort. In the case of concurrent writes, the write with highest priority wins. If we have concurrent writes of same priority, then things are sorted by CID.

The idea here is that in general, a node that is lagging behind or not syncing would have a dag with less depth, therefore its writes would have less priority when they conflict with writes from others that have built deeper DAGs. But this is after all an implementation choice, and the fact that a DAG is deeper does not mean that the last write on a key happened "later".

[samsquire]

Thank you for answering this.

I thought of using user indexes by order of connection or user last active time but if you're not worried of the security implications of wall clock and time skew.

Hyperhyperspace project has a previous field on the CRDT operations and can issue undo events to reverse operations.

I suspect you could have a time validator service that is a node that issues revocations if times are in the future. It wouldn't be on the read or write path and it's more to validate that times aren't in the future.

[samsquire]

I thought of using Myers algorithm for seamless merging of concurrent updates as this would allow similar strings to remain.

[samsquire]

I was interested so I implemented diff3 at HTTPS://GitHub.com/samsquire/text-diff

It doesn't handle conflicts at this time. If the text can be automerged it shall be.