Las mentiras que me contaron sobre la edición colaborativa, parte 1: algoritmos para edición offline

• A inicios de 2024, se empezó a investigar un sistema de edición colaborativa para usarlo en el editor de texto principal de Moment. Actualmente, varios algoritmos afirman resolver el problema de la edición online y offline. Sin embargo, en la práctica se descubrió que la experiencia de edición offline no es buena.
• Problemas de la edición offline
  • Algoritmos populares como CRDTs y OT resuelven los conflictos directos de edición de forma poco intuitiva, lo que hace que los usuarios lo perciban como corrupción de datos.
  • La edición offline aumenta la probabilidad de conflictos directos, y estos algoritmos no son adecuados para la edición offline.
• Ejemplo: un conflicto de edición menor
  • Alice y Bob editan un documento mientras están offline. Bob cambia 'Color' por 'Colour', y Alice elimina todo el texto. Cuando luego vuelven a estar online, hay que resolver ese conflicto.
  • Este tipo de conflictos es común y, como resultado, los usuarios perciben que los datos se corrompieron.
• Limitaciones de los algoritmos
  • Proyectos como Yjs, ShareJS y Peritext afirman que soportan edición offline, pero en la práctica ocurren errores con frecuencia.
  • Los algoritmos no pueden conocer la intención del usuario y operan a nivel de caracteres, por lo que ofrecen pocas garantías sobre el resultado.
• Cambio de enfoque hacia un problema de UI/UX
  • El problema no puede resolverse por completo solo con algoritmos, y debe abordarse como un problema de UI/UX.
  • Ya existen interfaces de fusión de documentos como las de git, y hay que investigar cómo hacerlas más accesibles y automatizables.
  • Algunos investigadores se están enfocando en este problema como uno de UI/UX, y un ejemplo de ello es la investigación de Ink & Switch sobre la historia de la colaboración.

[GN⁺]

Opiniones de Hacker News

• El autor de Eg-walker y ShareJS menciona que las herramientas de colaboración en tiempo real son útiles cuando se trabaja en conjunto en línea, pero para la edición offline o las ramas de larga duración se necesitan opciones que permitan agregar marcadores de conflicto y hacer una revisión manual

  • El algoritmo Eg-walker plantea la posibilidad de construir un CRDT que almacene el seguimiento de ediciones por carácter de todos los usuarios y registre el momento en que ocurrió cada cambio para poder detectar y marcar los rangos en conflicto
  • Destaca que este es un problema interesante y que aún no está resuelto, por lo que necesita más atención

• Otro problema de las implementaciones que usan CRDT es la carga de infraestructura

  • Si se usan CRDT, recomienda utilizar algo como Redis o MyRocks y aconseja no respaldarlos en un RDBMS, especialmente Postgres

• Agradece a quien está trabajando en integrar CRDT en software para tomar notas

• Menciona que los algoritmos de fusión mecánica pueden rendir de forma distinta según el tipo de conflicto, y que los CRDT no pueden determinar si el texto fusionado es lo que el usuario pretendía

  • El paper Upwelling explica en detalle la diferencia entre conflictos semánticos y conflictos sintácticos
  • La colaboración seria es un problema de revisión de documentos, especialmente importante en el periodismo y la publicación científica

• Los algoritmos usados en la edición colaborativa de texto (CRDTs y OT) tienen requisitos algebraicos estrictos sobre cómo se ejecutan e interactúan las operaciones de edición

  • El servidor puede procesar operaciones según la lógica de UX, y el cliente puede usar estrategias de rebase/predicción que permitan edición optimista

• Menciona que se han confundido los conceptos de conflicto matemático, causal y entrópico con los conflictos semánticos

  • La clase de CRDTs que preserva conflictos parece la más prometedora, y debería permitir que los usuarios puedan verlos visualmente

• Plantea la posibilidad de usar IA para predecir fusiones

  • Menciona que un LLM podría revisar los conjuntos de cambios del autor, preguntar si las ediciones se superponen o no, decidir el orden de los cambios y lograr un 90% de buenos resultados

• Señala que los CRDTs son un excelente modelo formal para estructuras de datos distribuidas, pero que hay un problema con la idea de que todos los conflictos deban resolverse automáticamente

  • Se necesita un modelo que represente los conflictos de forma estructural y permita resolverlos de manera compartida y colaborativa
  • Desarrolló un modelo de representación estructural de conflictos llamado "Lazy Merging", que presenta un modelo conceptual simple mediante un enfoque matemático

• Menciona que el hecho de que varias entidades tengan autoridad sobre los datos al mismo tiempo es un problema imposible de resolver

  • Es una lección aprendida en sistemas distribuidos, y se hace evidente en la edición distribuida de documentos

• Menciona que en 2009 hubo mucha discusión sobre algoritmos con los que Git fusiona cambios automáticamente, y que Torvalds era escéptico sobre los límites de la fusión automática

  • La edición offline es un problema de UI/UX y está relacionado con el problema de la computación de repetir soluciones antiguas
  • En la edición de texto, la fusión colaborativa offline debería ser el centro del proceso, y menciona que es difícil salir de máximos locales como MacWrite