As mentiras que me contaram sobre edição colaborativa, parte 1: algoritmos para edição offline

• No início de 2024, comecei a investigar um sistema de edição colaborativa para usar no editor de texto principal da Moment. Atualmente, vários algoritmos afirmam resolver o problema da edição online e offline. Porém, na prática, descobri que a experiência de edição offline é ruim.
• Problemas da edição offline
  • Algoritmos populares como CRDTs e OT resolvem conflitos diretos de edição de forma pouco intuitiva, fazendo com que os usuários percebam isso como corrupção de dados.
  • A edição offline aumenta a probabilidade de conflitos diretos, e esses algoritmos não são adequados para edição offline.
• Exemplo: um conflito trivial de edição
  • Alice e Bob editam um documento enquanto estão offline. Bob muda 'Color' para 'Colour', e Alice apaga todo o texto. Depois, quando ficam online, esse conflito precisa ser resolvido.
  • Esses conflitos são comuns e, como resultado, os usuários percebem que os dados foram corrompidos.
• Limitações dos algoritmos
  • Projetos como Yjs, ShareJS e Peritext afirmam oferecer suporte à edição offline, mas na prática ocorrem erros frequentes.
  • Os algoritmos não conseguem conhecer a intenção do usuário e operam no nível de caractere, o que oferece poucas garantias sobre o resultado.
• Mudança para um problema de UI/UX
  • Só algoritmos não conseguem resolver completamente o problema; é preciso abordá-lo como um problema de UI/UX.
  • Já existem UIs de mesclagem de documentos como a do git, e é preciso pesquisar formas de torná-las mais acessíveis e automatizadas.
  • Alguns pesquisadores já focam esse problema como uma questão de UI/UX, e o estudo da história da colaboração da Ink & Switch é um exemplo disso.

[GN⁺]

Opinião do Hacker News

• O autor de Eg-walker e ShareJS menciona que ferramentas de colaboração em tempo real são úteis ao trabalhar junto online, mas que para edição offline ou branches de longa duração é preciso haver uma opção de adicionar marcadores de conflito e fazer revisão manual

  • O algoritmo Eg-walker propõe a possibilidade de construir um CRDT capaz de armazenar o rastreamento de edições por caractere de todos os usuários e registrar quando cada alteração ocorreu, para detectar e marcar intervalos de conflito
  • Destaca que esse é um problema interessante e ainda não resolvido, portanto precisa de mais atenção

• Outro problema em implementações que usam CRDT é a carga de infraestrutura

  • Ao usar CRDT, recomenda-se usar algo como Redis ou MyRocks, e evitar fazer backup em um RDBMS, especialmente Postgres

• Agradece a quem está trabalhando na integração de CRDT em software de anotações

• Algoritmos de merge mecânico podem ter desempenho diferente em vários tipos de conflito, e observa-se que CRDT não consegue determinar se o texto mesclado corresponde à intenção do usuário

  • O artigo Upwelling explica em detalhes a diferença entre conflitos semânticos e conflitos sintáticos
  • Colaboração séria é um problema de revisão de documentos, especialmente importante no jornalismo e na publicação científica

• Os algoritmos usados em edição colaborativa de texto, como CRDTs e OT, têm exigências algébricas rigorosas sobre a execução e a interação das operações de edição

  • O servidor pode processar operações de acordo com a lógica de UX, e os clientes podem usar estratégias de rebase/predição que permitam edição otimista

• Menciona que conceitos matemáticos, causais e entrópicos de conflito foram confundidos com conflito semântico

  • Entre os CRDTs, a classe que preserva conflitos é a mais promissora, e deve permitir que os usuários visualizem os conflitos

• Sugere a possibilidade de usar IA para prever merges

  • Afirma que um LLM poderia analisar os conjuntos de mudanças do autor, perguntar se as edições se sobrepõem ou não, decidir a ordem das alterações e obter 90% de bons resultados

• CRDTs são um excelente modelo formal para estruturas de dados distribuídas, mas há um problema na ideia de que todos os conflitos devem ser resolvidos automaticamente

  • É necessário um modelo que represente conflitos estruturalmente e permita resolvê-los de forma compartilhada e colaborativa
  • Foi desenvolvido um modelo de representação estrutural de conflitos chamado "Lazy Merging", que apresenta um modelo conceitual simples por meio de uma abordagem matemática

• Menciona que ter várias entidades com autoridade simultânea sobre os dados é um problema sem solução

  • É uma lição aprendida em sistemas distribuídos, e isso fica claro na edição distribuída de documentos

• Em 2009, houve muita discussão sobre algoritmos com que o Git mescla mudanças automaticamente, e menciona-se que Torvalds era cético quanto aos limites do merge automático

  • Edição offline é um problema de UI/UX e está relacionada ao problema da computação de repetir soluções antigas
  • Na edição de texto, o merge colaborativo offline deveria estar no centro do processo, e observa-se que é difícil escapar de máximos locais como o MacWrite