共同編集についての嘘 第1部: オフライン編集のためのアルゴリズム

 (moment.dev)
2 ポイント 投稿者 GN⁺ 2024-12-08 | 1件のコメント | WhatsAppで共有
  • 2024年初め、Momentの中核テキストエディタで使う共同編集システムの調査を始めた。現在、複数のアルゴリズムがオンラインおよびオフライン編集の問題を解決すると主張している。しかし実際には、オフライン編集の体験は良くないことがわかった。
  • オフライン編集の問題点
    • CRDTsやOTのような人気のアルゴリズムは、直接的な編集衝突を直感に反する形で解決するため、ユーザーにはデータ破損のように見えてしまう。
    • オフライン編集では直接衝突の可能性が高まり、これらのアルゴリズムはオフライン編集に適していない。
  • 例: ささいな編集衝突
    • AliceとBobがオフライン状態で文書を編集する。BobはColorをColourに変更し、Aliceはすべてのテキストを削除する。その後オンラインに戻ったとき、この衝突を解決しなければならない。
    • このような衝突はよく起こり、結果としてユーザーはデータが壊れたと認識する。
  • アルゴリズムの限界
    • Yjs、ShareJS、Peritextのようなプロジェクトはオフライン編集をサポートすると主張しているが、実際には頻繁に問題が発生する。
    • アルゴリズムはユーザーの意図を知ることができず、文字単位で動作するため、結果に対する保証が乏しい。
  • UI/UXの問題への転換
    • アルゴリズムだけでは問題を完全に解決できず、UI/UXの問題として取り組むべきである。
    • gitのような文書マージUIはすでに存在しており、これをより使いやすく自動化する方法を研究すべきである。
    • 一部の研究者はこの問題をUI/UXの問題として重視しており、Ink & Switchによる共同編集の歴史研究がその一例である.

関連記事

1件のコメント

 
GN⁺ 2024-12-08
Hacker Newsの意見

  • Eg-walkerとShareJSの作者は、リアルタイム共同作業ツールはオンラインで一緒に作業する際には有用だが、オフライン編集や長期的なブランチでは、コンフリクトマーカーを追加して手動レビューできる選択肢が必要だと述べている

    • Eg-walkerアルゴリズムは、すべてのユーザーによる文字単位の編集追跡を保存し、すべての変更が発生した時点を記録することで、コンフリクト範囲を検出して表示できるCRDTを構築できる可能性を示している
    • この問題は興味深く、まだ解決されていないため、より多くの関心が必要だと強調している

  • CRDTを使用する実装のもう一つの問題は、インフラ負荷である

    • CRDTを使う場合は、RedisやMyRocksのようなものを使うのがよく、RDBMS、特にPostgresへバックアップしないことを勧めている

  • CRDTをノート作成ソフトウェアに統合する作業をしているユーザーに感謝を伝えている

  • 機械的マージアルゴリズムはさまざまな種類のコンフリクトで性能が異なる可能性があり、CRDTはマージされたテキストがユーザーの意図したものかどうかを判断できないと述べている

    • Upwelling論文では、意味的コンフリクトと構文的コンフリクトの違いについて詳しく説明している
    • 真剣なコラボレーションは文書レビューの問題であり、特にジャーナリズムと科学出版で重要である

  • 共同テキスト編集に使われるアルゴリズム（CRDTsとOT）には、編集操作の実行と相互作用に関する厳密な代数的要件がある

    • サーバーはUXロジックに従って操作を処理し、クライアントは楽観的編集を可能にするリベース/予測戦略を使用できる

  • 数学的、因果的、エントロピー的なコンフリクト概念が意味的コンフリクトと混同されていたと述べている

    • CRDTsの中では、コンフリクトを保持するクラスが最も有望であり、ユーザーがコンフリクトを視覚的に確認できるようにすべきである

  • AIを使ってマージを予測できる可能性を示している

    • LLMが著者の変更セットを見て、編集が重複しているかどうかを問い、変更順序を決定することで、90%は良い結果を得られるだろうと述べている

  • CRDTsは分散データ構造に対する優れた形式モデルだが、すべてのコンフリクトを自動的に解決しなければならないという考え方には問題があると述べている

    • コンフリクトを構造的に表現し、共有的・協調的に解決できるモデルが必要である
    • 「Lazy Merging」という構造的コンフリクト表現モデルを開発し、数学的アプローチによってシンプルな概念モデルを提示している

  • 複数の主体が同時にデータに対する権限を持つことは、解決不可能な問題だと述べている

    • これは分散システムで学んだ教訓であり、文書の分散編集で明確に表れる

  • 2009年には、Gitが変更を自動でマージするアルゴリズムについて多くの議論があり、Torvaldsは自動マージの限界に懐疑的だったと述べている

    • オフライン編集はUI/UXの問題であり、古い解決策を踏襲するコンピューティングの問題とも関係している
    • テキスト編集におけるオフライン共同編集マージはプロセスの中心であるべきで、MacWriteのようなローカルな極大値から抜け出しにくいと述べている