Les mensonges qu’on m’a racontés sur l’édition collaborative, partie 1 : des algorithmes pour l’édition hors ligne

• Début 2024, l’équipe a commencé à étudier un système d’édition collaborative à utiliser dans l’éditeur de texte principal de Moment. Plusieurs algorithmes affirment aujourd’hui résoudre les problèmes d’édition en ligne et hors ligne. En pratique, il s’est toutefois avéré que l’expérience d’édition hors ligne était médiocre.
• Les problèmes de l’édition hors ligne
  • Des algorithmes populaires comme les CRDTs et l’OT résolvent les conflits d’édition directs de manière peu intuitive, au point que les utilisateurs les perçoivent comme une corruption des données.
  • L’édition hors ligne augmente la probabilité de conflits directs, et ces algorithmes ne sont pas adaptés à ce mode d’édition.
• Exemple : un conflit d’édition mineur
  • Alice et Bob modifient un document hors ligne. Bob remplace « Color » par « Colour », tandis qu’Alice supprime tout le texte. Une fois de nouveau en ligne, il faut résoudre ce conflit.
  • Ce type de conflit est fréquent et, au final, les utilisateurs ont l’impression que les données ont été corrompues.
• Les limites des algorithmes
  • Des projets comme Yjs, ShareJS et Peritext affirment prendre en charge l’édition hors ligne, mais en pratique des erreurs surviennent fréquemment.
  • Les algorithmes ne peuvent pas connaître l’intention de l’utilisateur et fonctionnent au niveau du caractère, ce qui offre peu de garanties sur le résultat.
• Vers un problème d’UI/UX
  • Les algorithmes seuls ne peuvent pas résoudre complètement le problème ; il faut l’aborder comme une question d’UI/UX.
  • Il existe déjà des interfaces de fusion de documents comme git, et il faut étudier comment les rendre plus accessibles et plus automatisées.
  • Certains chercheurs se concentrent sur cette question comme un problème d’UI/UX, par exemple dans l’étude d’Ink & Switch sur l’histoire de la collaboration.

[GN⁺]

Avis Hacker News

• L’auteur d’Eg-walker et de ShareJS indique que les outils de collaboration en temps réel sont utiles pour travailler ensemble en ligne, mais que pour l’édition hors ligne ou les branches de longue durée, il faut aussi une option permettant d’ajouter des marqueurs de conflit et d’effectuer une revue manuelle

  • L’algorithme Eg-walker conserve le suivi des modifications caractère par caractère pour chaque utilisateur, ainsi que le moment où chaque changement a eu lieu, ce qui ouvre la possibilité de construire un CRDT capable de détecter et de signaler les zones de conflit
  • Il souligne qu’il s’agit d’un problème intéressant, toujours non résolu, qui mérite davantage d’attention

• Un autre problème des implémentations utilisant des CRDT est la charge d’infrastructure

  • En cas d’utilisation de CRDT, il recommande d’utiliser quelque chose comme Redis ou MyRocks, et déconseille de les sauvegarder dans un SGBDR, en particulier Postgres

• Il remercie la personne qui travaille à l’intégration des CRDT dans un logiciel de prise de notes

• Il est mentionné que les algorithmes de fusion mécanique peuvent avoir des performances différentes selon les types de conflit, et que les CRDT ne peuvent pas déterminer si le texte fusionné correspond à l’intention de l’utilisateur

  • L’article Upwelling détaille la différence entre conflit sémantique et conflit syntaxique
  • Une collaboration sérieuse relève d’un problème de revue documentaire, particulièrement important dans le journalisme et l’édition scientifique

• Les algorithmes utilisés pour l’édition collaborative de texte (CRDTs et OT) imposent des exigences algébriques strictes sur l’exécution des opérations d’édition et leurs interactions

  • Le serveur peut traiter les opérations selon une logique UX, tandis que le client peut utiliser une stratégie de rebase/prédiction autorisant l’édition optimiste

• Il est indiqué que les notions de conflit mathématique, causal et entropique ont été confondues avec le conflit sémantique

  • Parmi les CRDTs, la classe qui préserve les conflits semble la plus prometteuse, et devrait permettre aux utilisateurs de visualiser ces conflits

• Il évoque la possibilité d’utiliser l’IA pour prédire les fusions

  • Il mentionne qu’un LLM pourrait examiner les ensembles de modifications des auteurs, demander si les éditions se chevauchent, déterminer l’ordre des changements, et obtenir de bons résultats dans 90 % des cas

• Les CRDTs sont un excellent modèle formel pour les structures de données distribuées, mais il estime problématique l’idée selon laquelle tous les conflits devraient être résolus automatiquement

  • Il faut un modèle capable de représenter les conflits de manière structurelle et de les résoudre de façon partagée et collaborative
  • Il a développé un modèle de représentation structurelle des conflits appelé « Lazy Merging », qui propose un modèle conceptuel simple à partir d’une approche mathématique

• Il est indiqué que le fait que plusieurs entités détiennent simultanément l’autorité sur des données est un problème insoluble

  • C’est une leçon tirée des systèmes distribués, et cela apparaît clairement dans l’édition distribuée de documents

• Il est mentionné qu’en 2009, il y avait beaucoup de discussions sur les algorithmes permettant à Git de fusionner automatiquement les changements, et que Torvalds était sceptique quant aux limites de la fusion automatique

  • L’édition hors ligne est un problème d’UI/UX, lié à la tendance de l’informatique à recycler d’anciennes solutions
  • Dans l’édition de texte, la fusion collaborative hors ligne devrait être au cœur du processus, et il est difficile de sortir d’un optimum local comme MacWrite