Lügen über kollaboratives Editieren, Teil 1: Algorithmen für Offline-Bearbeitung

• Anfang 2024 begann man, ein System für kollaboratives Editieren für den zentralen Texteditor von Moment zu untersuchen. Derzeit behaupten verschiedene Algorithmen, die Probleme von Online- und Offline-Bearbeitung zu lösen. In der Praxis stellte sich jedoch heraus, dass die Offline-Bearbeitung keine gute Erfahrung bietet.
• Probleme der Offline-Bearbeitung
  • Beliebte Algorithmen wie CRDTs und OT lösen direkte Bearbeitungskonflikte auf unintuive Weise, sodass Nutzer dies als Datenbeschädigung wahrnehmen.
  • Offline-Bearbeitung erhöht die Wahrscheinlichkeit direkter Konflikte, und diese Algorithmen sind für Offline-Bearbeitung nicht gut geeignet.
• Beispiel: ein trivialer Bearbeitungskonflikt
  • Alice und Bob bearbeiten ein Dokument offline. Bob ändert "Color" in "Colour", und Alice löscht den gesamten Text. Wenn sie später wieder online sind, muss dieser Konflikt gelöst werden.
  • Solche Konflikte sind häufig, und infolgedessen nehmen Nutzer die Daten als beschädigt wahr.
• Grenzen der Algorithmen
  • Projekte wie Yjs, ShareJS und Peritext behaupten, Offline-Bearbeitung zu unterstützen, in der Praxis treten jedoch häufig Fehler auf.
  • Algorithmen können die Absicht der Nutzer nicht kennen und arbeiten auf Zeichenebene, wodurch es kaum Garantien für das Ergebnis gibt.
• Übergang zu einem UI/UX-Problem
  • Allein mit Algorithmen lässt sich das Problem nicht vollständig lösen; man muss es als UI/UX-Problem angehen.
  • Dokument-Merge-UIs wie bei git existieren bereits, und es sollte untersucht werden, wie sie zugänglicher und stärker automatisiert werden können.
  • Einige Forschende konzentrieren sich auf dieses Problem als UI/UX-Thema; ein Beispiel dafür ist die Forschung von Ink & Switch zur Geschichte der Kollaboration.

[GN⁺]

Hacker-News-Kommentar

• Der Autor von Eg-walker und ShareJS erwähnt, dass Echtzeit-Kollaborationstools nützlich sind, wenn man online gemeinsam arbeitet, dass es für Offline-Bearbeitung oder langlebige Branches jedoch eine Option braucht, Konfliktmarker hinzuzufügen und eine manuelle Prüfung vorzunehmen

  • Der Eg-walker-Algorithmus zeigt die Möglichkeit auf, ein CRDT aufzubauen, das die zeichenweise Bearbeitungsverfolgung aller Nutzer speichert und den Zeitpunkt jeder Änderung festhält, sodass Konfliktbereiche erkannt und markiert werden können
  • Er betont, dass dies ein interessantes Problem ist, das noch nicht gelöst wurde und daher mehr Aufmerksamkeit braucht

• Ein weiteres Problem bei Implementierungen mit CRDTs ist der Infrastruktur-Overhead

  • Bei der Nutzung von CRDTs sei es besser, so etwas wie Redis oder MyRocks zu verwenden, und es wird empfohlen, kein Backup in einem RDBMS, insbesondere nicht in Postgres, anzulegen

• Es wird einem Nutzer gedankt, der daran arbeitet, CRDTs in Notizsoftware zu integrieren

• Es wird erwähnt, dass mechanische Merge-Algorithmen je nach Art des Konflikts unterschiedlich gut funktionieren können und dass CRDTs nicht entscheiden können, ob der zusammengeführte Text tatsächlich dem entspricht, was der Nutzer beabsichtigt hat

  • Das Upwelling-Paper erklärt ausführlich den Unterschied zwischen semantischen und syntaktischen Konflikten
  • Ernsthafte Kollaboration ist ein Problem der Dokumentenprüfung und besonders im Journalismus und in wissenschaftlichen Publikationen wichtig

• Die für kollaboratives Text-Editing verwendeten Algorithmen (CRDTs und OT) haben strenge algebraische Anforderungen an die Ausführung und Interaktion von Bearbeitungsoperationen

  • Der Server kann Operationen entsprechend der UX-Logik verarbeiten, und der Client kann Rebase-/Vorhersagestrategien verwenden, die optimistisches Editing erlauben

• Es wird erwähnt, dass mathematische, kausale und entropische Konfliktbegriffe mit semantischen Konflikten verwechselt wurden

  • Unter den CRDTs sei die Klasse, die Konflikte erhält, am vielversprechendsten, und Nutzer sollten Konflikte visuell prüfen können

• Es wird die Möglichkeit angesprochen, mithilfe von AI Merges vorherzusagen

  • Ein LLM könnte die Änderungssätze der Autoren ansehen, gefragt werden, ob sich Bearbeitungen überschneiden, und die Reihenfolge der Änderungen bestimmen, um in 90 % der Fälle gute Ergebnisse zu erzielen

• CRDTs sind ein hervorragendes formales Modell für verteilte Datenstrukturen, aber es gibt ein Problem mit der Vorstellung, dass alle Konflikte automatisch gelöst werden müssen

  • Es braucht ein Modell, das Konflikte strukturell darstellt und ihre gemeinsame sowie kollaborative Auflösung ermöglicht
  • Dazu wurde ein Modell struktureller Konfliktdarstellung namens "Lazy Merging" entwickelt, das mit einem mathematischen Ansatz ein einfaches konzeptionelles Modell präsentiert

• Es wird erwähnt, dass es ein unlösbares Problem ist, wenn mehrere Entitäten gleichzeitig Berechtigungen über Daten haben

  • Das ist eine Lehre aus verteilten Systemen und zeigt sich deutlich beim verteilten Bearbeiten von Dokumenten

• 2009 gab es viele Diskussionen über Algorithmen, mit denen Git Änderungen automatisch zusammenführt, und es wird erwähnt, dass Torvalds den Grenzen des automatischen Mergings skeptisch gegenüberstand

  • Offline-Bearbeitung ist ein UI/UX-Problem und hängt mit dem Problem des Computings zusammen, alte Lösungen immer wieder nachzuahmen
  • Beim Text-Editing sollte das Zusammenführen in der Offline-Kollaboration im Zentrum des Prozesses stehen, und es wird erwähnt, dass es schwer ist, sich von lokalen Maxima wie MacWrite zu lösen