Two clients (A, B) hold local copies of one shared text buffer and edit it independently over a laggy link. Each character typed or deleted becomes an operation Insert(pos, char) or Delete(pos) which applies instantly to its own site and is sent to the other after the current network delay.
The problem: by the time A's operation arrives at B, B may already have applied its own concurrent edit, shifting every position after it. Applying A's operation at its original index would now hit the wrong character. Operational Transform fixes this with a transform function T(op1, op2) that adjusts op2's index to account for op1 having already been applied:
Insert vs Insert: if pos1 < pos2 (or equal & site1 wins tie-break): pos2 += 1
Insert vs Delete: if pos1 <= pos2: pos2 += 1
Delete vs Insert: if pos1 < pos2: pos2 -= 1
Delete vs Delete: if pos1 < pos2: pos2 -= 1
if pos1 == pos2: op2 becomes a no-op (already gone)
Each site keeps a log of the local operations the other side has not yet acknowledged. An incoming remote operation is transformed, in order, against every entry in that log before being applied — this is the same two-site algorithm (a simplified Jupiter/ot.js protocol) that underlies collaborative editors like Google Docs and Etherpad.
- Insert / Delete @ A or B — fires one local edit at a random position on that site; it applies immediately there and departs for the other site after the latency delay.
- Network latency — how long an operation spends in flight (visualized as a traveling sphere), controlling how much concurrency the two sites accumulate before syncing.
- Operational Transform ON/OFF — with OT off, incoming operations apply at their original, untransformed index — watch the two documents silently diverge into different text.
Real-world relevance: this exact transform/apply cycle is what keeps two phones editing the same shared note, whiteboard or document consistent even on flaky mobile networks, without a central server rewriting every keystroke.