博士

やっほー、ロボ子！今日はローカルファーストアプリの話をするのじゃ！

ロボ子

博士、こんにちは。ローカルファーストアプリ、最近よく耳にしますね。どのような点が重要なのでしょうか？

博士

ローカルファーストは単なる技術じゃないぞ！「データ、ワークフロー、コミュニティの運用を個人とコミュニティの手に取り戻し、自律性を高める」ための、政治的・社会的スタンスなのじゃ！

ロボ子

なるほど、単なる技術的なアーキテクチャ以上の意味があるんですね。具体的にはどのようなプロジェクトがあるんですか？

博士

Keyhiveプロジェクトっていうのがあっての。これはプライバシーを保護するローカルファーストアプリの可能性を広げるものなのじゃ。特に、Automerge、Yjs、Loroなどのライブラリを使うと、中央集権的な管理なしにリアルタイムな共同作業アプリが作れるのがすごいぞ！

ロボ子

リアルタイム共同作業アプリを中央集権的な管理なしに作れるんですか！それはすごいですね。KeyhiveはRoomyでのアクセス制御にも使われる予定なんですね。

博士

そうそう！それで、Keyhiveの中でも特に注目なのがBeeKEMなのじゃ！

ロボ子

BeeKEMですか。どのような仕組みなのでしょうか？

博士

BeeKEMは、グループメッセージングの進化形みたいなものなのじゃ。基本となるセキュアメッセージングはSignalプロトコルっていうのがあって、これは2者間セキュアメッセージング（2SM）の新しい標準なのじゃ。

ロボ子

Signalプロトコルはよく聞きますね。でも、グループメッセージングだと効率が悪くなるという話もありますよね？

博士

そう！グループメンバー数（n）に対してn^2の複雑さになっちゃうのじゃ。そこでTreeKEMの登場なのじゃ！

ロボ子

TreeKEMはMessaging Layer Security（MLS）標準の一部なんですね。どのような仕組みで効率化を図るんですか？

博士

TreeKEMは、グループメンバーが協力して、グループの特定の状態（「エポック」）の間、全員で共有される単一のキーを計算するのじゃ。新しいメンバーは、左平衡二分木（LBBT）の葉に位置を割り当てられるのじゃ。

ロボ子

なるほど、木構造を使うことで効率的な鍵交換を実現するんですね。BeeKEMはTreeKEMとどう違うんですか？

博士

BeeKEMは、複数のメンバーが同じツリーインデックスに同時に追加された場合の処理方法が違うのじゃ。中央機関が操作の成功を仲裁する代わりに、各操作の有効性は、更新者が認識していた以前のツリー状態に対して有効かどうかで判断するのじゃ。

ロボ子

競合が起きた場合に、中央機関に頼らずに判断するんですね。具体的にはどうやって競合を解決するんですか？

博士

競合するノードを空白とみなし、解像度内の各ノードに個別に暗号化するのじゃ。解像度っていうのは、非空白で非競合の最高位の子孫のことなのじゃ！

ロボ子

なるほど、競合するノードを空白とみなすことで、オフライン更新やネットワーク分断からの回復能力を高めるんですね。

博士

そういうこと！BeeKEMは、グループ状態が複数のエポックに同時に存在することを明示的にモデル化することで、それを実現しているのじゃ！

ロボ子

ローカルファーストアプリの可能性を広げるKeyhiveとBeeKEM、とても興味深いですね！

博士

じゃろ？じゃろ？ところでロボ子、BeeKEMの話をしていたら、ハチミツが食べたくなってきたのじゃ。BeeKEMだけに…ブーン！