公式: Blueskyの連合機能の概要

概要

2023-05-05にBluesky公式記事「Federation Architecture Overview – Bluesky」が投稿されたので紹介します。以下の公式アカウントでも告知されていました。

2023-05-05T19:32:28.738Z

Bluesky|@bsky.app

We’ll soon be launching a sandbox environment to begin the testing phase of federation for the AT Protocol with allow-listed servers. In advance of this launch, here are some technical details about our design decisions.

Federation Architecture Overview

blueskyweb.xyz

分散SNSが分散たる所以の肝心の連合 (federation) 機能の概要となります。

Federation Architecture

まもなく許可リストに登録されたサーバーとAT Protocolの連合のテストを開始するサンドボックス環境を開始します。このリリースに先立って、設計上の決定に関する技術的な詳細をいくつか共有します。

おおまかにいうと、連合とは自分のサーバーなど、AT Protocol自体を構成する部分を誰でも実行可能なことを意味します。サンドボックスモードは、実際のネットワークに接続せずに連合の実験を開始可能なことを意味します。テストネットワークです。

AT Protocol自体は多数のパーツで構築されています。下位レベルの原形はデータリポジトリ―/Lexicon/DIDです。多数のパーツで構成されていることから、我々が提案するアーキテクチャーが、連合に可能な唯一のものではないことを意味します。

連合の3の主なサービスはPersonal Data Server (PDS)/Big Graph Service (BGS)/AppViewです。これの他にFeed Gen/Labelerの2の役割を開発中です。

• Personal Data Server (PDS): ネットワーク内で参加者のエージェントとして機能します。これはリポジトリ―のデータ (投稿など) をホストするものです。また、アカウントのログインを処理して、署名キーを管理し、個人データ (ミュートアカウントなど) を保存し、リクエストに対する通信サービスを処理します (ActivityPubの単独サーバー相当)。
• Big Graph Service (BGS): big-world (ビッグワールド) ネットワーキングを処理します。ネットワークをクロールしてできるだけ多くのデータを収集し、他のサービスが使用できるように一つの大きなストリームを出力します (リレーノード相当)。
• App View: フィードとアプリで表示される他の全てのデータの構築部分。BGSの下流に存在。ネットワーク全体の集約を生成し、サブセットを表示します。BGSの生データを取り込み、キュレートされたフィードをユーザーに表示できるようにする。

誰でもBGSをホストできますが、これはかなりリソースが必要なサービスです。ほとんどの場合、大規模な古ネットワークプロバイダーがいて、部分的なネットワークプロバイダーが存在する可能性を予想しています。小規模BGSは特定アプリや小規模コミュニティーなどで提供可能です。

その他、ネットワークに展開された各Lexicon、つまりソーシャルモード (social mode) のApp Viewsのシステムもあります。例えば、Blueskyは現在マイクロブログモードのapp.bskyのLexiconに対応しています。新しく、動画や長文ブログ、グループ、フォーラムなどのLexiconがありえます。

“Big World” Design

AT Protocolのトポロジーの設計時に、一番成功している分散型システムであるWebを調べました。

その結果、「小さな世界のフォールバックを備えた大きな世界」の方法でプロトコルを設計しました。Webでは、個々のコンピューターがコンテンツをネットワークにアップロードし、そのコンテンツを他のコンピューターにブロードキャストされます。AT Protocolも同様に、少数の大きなアグリゲーター (BGS) にメッセージを送信し、そのデータをネットワーク全体のPDSにブロードキャストします。

技術レベルでは、スモールワールドよりもビッグワールドインデックス作成の優先には以下の利点があります。

• PDSの負荷の大幅軽減。これによるセルフホストの容易化。
• 近隣ユーザー以外のコンテンツの発見性の向上。
• ネットワーク全体のUXの向上。

なお、サーバー間ではなくBGSを介したネットワークというのは、規定的なものではありません。実際にはスモールワールド (PDS同士) とビッグワールド (BGS経由) の両方で動作するように設計されています。

What’s Next For Us

連合が重要であるには、全要素を簡単に設定できる必要があります。サンドボックス環境の公開時に簡単な手順を提示します。

その他、追加で2個の機能に取り組んでいます。フィードジェネレーターとラベラーです。現在BlueskyのAp Viewはユーザーに表示するフィードやコンテンツモデレーションで使用するラベルなど、いくつかの独自のデータを生成します。しかし、これらを独自のサービスとして分割する実験も行っています。これが完了すると、誰でもフィードジェネレーターをホストし、アルゴリズムのマーケットプレイスでユーザーに宣伝できます。

技術的にはフィードジェネレーターやラベラーはBGSの下流にいて、AppViewから参照されて表示やPDSに取り込まれるアーキテクチャーが一つの想定です。

Sandbox Mode

最初は許可リストに登録されたサーバーを使用して、サンドボックスモードで連合を開始します。これは、少なくとも週1回リセットされるステージング環境です。サンドボックス環境の保有は、開発者がシステムのストレステストとデバッグに非常に便利です。将来のプロトコルの変更のテストにも使えます。誰でもサンドボックスに参加できますが、データが消去されることに注意してください。

サンドボックス環境は、モデレーションやキュレーションツールの構築完了にも役立ちます。

モデレーションとサンドボックス環境での実験開始方法は、近日中に共有します。

結論

Bluesky/AT Protocolの連合機能の概要でした。これまで存在だけが登場していたBGSについても説明がありました。

個人的には、ActivityPubのとAT Protocolの最大の違いはBGSだと思っていました。ただ、今回の説明を見る限り、ただのリレーサーバー的なものになるようで、少々期待外れでした。というのも、過去に「連合リレーへの参加を推奨しない理由 | GNU social JP」で紹介した通り、連合リレーへの参加は推奨されないからです。サーバーに残るたくさんの無駄なデータ、コンテンツモデレーションの問題が発生するので、個人サーバーだとあまり参加する意味がありません。大規模サーバーがホストすればいいのかもしれませんが、それは結局集中的な存在に依存することになります。

そうなると、アルゴリズムやキュレーションなど現行のActivityPubでもできることをわずかにカスタマイズしやすくなったものでしかなく、現状そこまで目新しいものがありません。現状だと個人的にはあまり魅力を感じません。この後実際に連合が始まって、PDSやBGSが機能し始めたり、ただのSNSを超えた用途、例えばGitHubでのメッセージなどあらゆるメッセージ機能で使われだすようなら可能性があります。もう少し様子を見守ります。