3 ms·

Does Loro generate conflict ranges when merging branches, thus allowing manual conflict resolution? I’ve heard people suggest using LLMs for years for this - b

Does Loro generate conflict ranges when merging branches, thus allowing manual conflict resolution? I’ve heard people suggest using LLMs for years for this - but CRDTs work because the same computation on two peers is guaranteed to produce the same result. LLMs can’t guarantee that. You could probably use an llm in leu of a human manually merging conflicts - but in that case we still need the crdt to first generate those conflict ranges to pass to the llm. Essentially an llm could solve the UX problem, but the underlying algorithm still needs this feature first to allow that to be used.

mkl 2y ago
It seems that they might, but perhaps not in a good way yet, and they have it as a goal. From https://loro.dev/blog/v1.0#next-steps-for-loro https://loro.dev/blog/v1.0#next-steps-for-loro: > When merging extensive concurrent edits, CRDTs can automatically merge changes, but the result may not always meet expectations. Fortunately, Loro stores the complete editing history. This allows us to offer Git-like manual conflict resolution at the application layer when needed. From https://loro.dev/docs/tutorial/time_travel https://loro.dev/docs/tutorial/time_travel: > once we have a more refined version control API in place. I'm interested to hear your opinion of their partial adoption of Eg-walker: https://loro.dev/blog/v1.0#leveraging-the-potential-of-the-eg-walker https://loro.dev/blog/v1.0#leveraging-the-potential-of-the-e...
dmurray 2y ago
> but CRDTs work because the same computation on two peers is guaranteed to produce the same result. LLMs can’t guarantee that. This doesn't seem like a hard requirement. It's a nice property for some academically interesting peer-to-peer trustless algorithm, but in typical software architectures you won't get a situation where Alice receives Bob's edits and Bob receives Alice's edits without them passing through a centralised server that can reconcile them first. In any case, LLMs can be run deterministically (temperature=0, or use a fixed random seed and a single core where necessary). I don't expect further serious work in the offline text editing space. The next generation will certainly be some form of "guess, then ask an LLM to guess"
- josephg 2y ago
  > in typical software architectures you won't get a situation where Alice receives Bob's edits and Bob receives Alice's edits without them passing through a centralised server that can reconcile them first. Thats the exact situation these algorithms are all designed to handle. If you require a centralised reconciling server, you’re taking a big step back in functionality - and you no longer have an eventually consistent system. But as I say, asking an llm - what exactly? Most of the time concurrent edits are in different regions of a document and you want them to be merged automatically in the obvious way. It’s only when the same text (same line) is edited by two peers that you want to invoke a llm (if at all). If that’s the case you still need the crdt to detect conflicting ranges - you’re just using an llm instead of a human to resolve them. And in that case, CRDTs are still missing the important feature this blog post talked about. You’re just proposing a different UX layer on top of that missing feature. And really, you’ll probably still want human review. LLMs have a tendency to do drive-by edits in situations like this, adding or removing commas in prose, changing formatting in code and so on. I don’t trust LLMs to touch my code or my writing without human review.
satvikpendem 2y ago
Loro is planning on doing so, as the other comment says. Related, is this what you are looking for [0]? The commenter says that their implementation will surface conflicts to the user. [0] https://news.ycombinator.com/item?id=42348381 https://news.ycombinator.com/item?id=42348381

mkl 2y ago

It seems that they might, but perhaps not in a good way yet, and they have it as a goal. From https://loro.dev/blog/v1.0#next-steps-for-loro https://loro.dev/blog/v1.0#next-steps-for-loro: > When merging extensive concurrent edits, CRDTs can automatically merge changes, but the result may not always meet expectations. Fortunately, Loro stores the complete editing history. This allows us to offer Git-like manual conflict resolution at the application layer when needed. From https://loro.dev/docs/tutorial/time_travel https://loro.dev/docs/tutorial/time_travel: > once we have a more refined version control API in place. I'm interested to hear your opinion of their partial adoption of Eg-walker: https://loro.dev/blog/v1.0#leveraging-the-potential-of-the-eg-walker https://loro.dev/blog/v1.0#leveraging-the-potential-of-the-e...

dmurray 2y ago

> but CRDTs work because the same computation on two peers is guaranteed to produce the same result. LLMs can’t guarantee that. This doesn't seem like a hard requirement. It's a nice property for some academically interesting peer-to-peer trustless algorithm, but in typical software architectures you won't get a situation where Alice receives Bob's edits and Bob receives Alice's edits without them passing through a centralised server that can reconcile them first. In any case, LLMs can be run deterministically (temperature=0, or use a fixed random seed and a single core where necessary). I don't expect further serious work in the offline text editing space. The next generation will certainly be some form of "guess, then ask an LLM to guess"

josephg 2y ago
> in typical software architectures you won't get a situation where Alice receives Bob's edits and Bob receives Alice's edits without them passing through a centralised server that can reconcile them first. Thats the exact situation these algorithms are all designed to handle. If you require a centralised reconciling server, you’re taking a big step back in functionality - and you no longer have an eventually consistent system. But as I say, asking an llm - what exactly? Most of the time concurrent edits are in different regions of a document and you want them to be merged automatically in the obvious way. It’s only when the same text (same line) is edited by two peers that you want to invoke a llm (if at all). If that’s the case you still need the crdt to detect conflicting ranges - you’re just using an llm instead of a human to resolve them. And in that case, CRDTs are still missing the important feature this blog post talked about. You’re just proposing a different UX layer on top of that missing feature. And really, you’ll probably still want human review. LLMs have a tendency to do drive-by edits in situations like this, adding or removing commas in prose, changing formatting in code and so on. I don’t trust LLMs to touch my code or my writing without human review.

satvikpendem 2y ago

Loro is planning on doing so, as the other comment says. Related, is this what you are looking for [0]? The commenter says that their implementation will surface conflicts to the user. [0] https://news.ycombinator.com/item?id=42348381 https://news.ycombinator.com/item?id=42348381