title: Logoot CRDT: interleaving of data on concurrent edits to the same spot?
body: <p>I want to implement <a href="https://hal.archives-ouvertes.fr/inria-00432368/document" rel="noreferrer">Logoot</a> for eventually-convergent P2P text editing and I've run into a bit of a problem.</p>
  
  <p>My understanding of Logoot is that the intervals between objects (lines of text in the original paper, but could be characters or words) can be divided infinitely on account of an unbounded identifier. This means that the position of an object is determined not by its neighbors as in WOOT (which would require tombstones) but by a fixed numerical point along the length of the string. Combined with a unique site identifier, this also gives us a total order and enables eventual convergence.</p>
  
  <p>However... doesn't this cause a problem when concurrent edits are made to the same spot? If two disconnected clients start writing new sentences at the same cursor position and then merge, their sentences have a good chance of interleaving.</p>
  
  <p>Below is a whiteboard example of what I'm talking about:</p>
  
  <p><a href="https://i.stack.imgur.com/4v7BX.png" rel="noreferrer"><img src="https://i.stack.imgur.com/4v7BX.png" alt="Whiteboard"></a></p>
  
  <p>As you can see, both site B and site C divide the interval between "I" and "conquered" according to the rules of Logoot, giving us random points between the positions of (20,A) and (25,A). But nothing orders these points relative to each other, causing them to mix when merged. Meanwhile, neighbor-based algorithms can account for this issue since the causality chain of each object is preserved.</p>
  
  <p>The above is a baby example, but in the more general case, imagine if two users wanted to insert a different sentence between two existing sentences. If one of the users happened to be offline, they shouldn't come back to a garbled mess! Clearly, to preserve intent, one sentence should follow the other.</p>
  
  <p>Am I missing something in my reading of the paper, or is this an inherent downside to Logoot?</p>
  
  <p>(Also, why is there a recorded clock value that's seemingly unused in the algorithm? The paper even points out that each object's identifier is necessarily unique without the clock.)</p>