誰もが、この宇宙の中で対応する星が輝いている。
アーサー・C・クラーク『2001 年宇宙の旅』
はじめに#
マスクが Twitter を 𝕏 に変換する過程でのいくつかの物議を醸す行動により、多くのユーザーが Twitter から Mastodon、Threads などのプラットフォームに移行することを選択しました。連邦宇宙（Fediverse）という言葉が徐々に一般の視野に入ってきました。同時に、Threads でさえ将来的に ActivityPub プロトコルをサポートし、相互接続を実現し、連邦宇宙に参加すると主張しています（これにより連邦宇宙コミュニティ内で一連の議論が引き起こされました）。
2024 年 2 月 6 日、Bluesky は 2021 年以降のパブリックベータを終了し、ユーザーは招待コードなしで登録できることを発表しました。1 Twitter の共同創設者によって設立された連邦宇宙の新興勢力である Bluesky は、現在の 連邦宇宙 で人気のある ActivityPub プロトコルを採用せず、自ら開発した AT プロトコル（AT Protocol or @ protocol, Authenticated Transfer Protocol） を採用しています。
連邦宇宙に関心を持って 2 年半以上 の私は、好奇心から AT プロトコル に関する内容を閲覧し、一緒にハマる 相互共有の精神で、AT プロトコル に対する考察と理解を記録するために、論文でも報告書でもブログでもないこの文章を書きました。私のレベルは限られているため、参考程度にご覧いただき、指摘や交流を歓迎します。
初歩的な印象と比較#
この比喩が適切でないかもしれませんが、ブロックチェーンの発展を例に挙げると、個人的には OStatus を代表とするプロトコルはかつてのアダム・バックの hashcash に似ており、ActivityPub は Bitcoin に似ていると思います。そして AT プロトコル は Ethereum や EOS に似た感覚があります。
以前に Mastodon のような ActivityPub プロトコルに基づく 連邦宇宙 の インスタンス（Instance） を利用していた場合、インスタンス 間の相互接続性の欠陥について理解しているかもしれません：既存のドメインが停止している場合に新しいドメインに移行できず、他のインスタンスとのインタラクションでは、自分が所属するインスタンスがすでに連携しているインスタンスのインタラクションしか表示できません。もしそのような インスタンス を運営していた場合、連邦宇宙 の資金消費についても感じることがあるかもしれません（これにより、Hetzner のような IDC が連邦宇宙の半数以上のインスタンスホスティングサービスの選択肢となり、連邦宇宙の首都と呼ばれることになりました）、また技術と管理の両方を行う疲労感もあります。もちろん、これは ActivityPub が 連邦宇宙 の非常に優れたプロトコルの一つであることを妨げるものではありませんが、これらのバグは改善の余地があるかどうかを考えさせます。
2023 年、Nostr を代表とするブロックチェーンベースの Web3 ソーシャルは、エドワード・スノーデンを中心としたプロモーションによって徐々に「火がつき」、一時的に Twitter 上で一連の「神秘的なコード」が流行しました。Nostr はブロックチェーンをソーシャルプラットフォームに導入し、価値層（またはインセンティブ層）を追加し、DHT などの P2P プロトコルを通じてノードの相互接続を実現しました。しかし、Nostr の設計理念により、情報のフィルタリングの内在的なメカニズムが欠如しており、現在のクロスチェーンメカニズムの欠如や運営チェーンまたはノードの高コストとリスクにより、ユーザーは基本的に Nostr のメインチェーンに集中しており、Nostr の「神秘的なコード」もこのソーシャル方式の欠陥を示しています：可読性の欠如です。コンピュータはハッシュを解読するのが日常茶飯事ですが、ほとんどの人間は大量のランダムな文字列のハッシュアドレスを記憶できません。例えば、別のブロックチェーンベースの Web3 ソーシャルである Farcaster や、私が以前体験した Status などのプロジェクトは、ENS などの人間に優しい方法でマッピングを試みていますが、ENS の高コストがユーザーの参加を妨げています。
さらに、ActivityPub も Nostr や Farcaster の実装も絶対的なタイムラインとフォローのプッシュを採用しており、これはプラットフォームの単一アルゴリズムによる 情報の茧 を回避することができますが、別の問題を引き起こします。ユーザーの注意は限られているため、ActivityPub の考え方は、まず インスタンス および連携している インスタンス の情報をプッシュ（あるいはプッシュのみ）することを優先し、情報を発見する際にはユーザーが時間順に並べられた情報をフィルタリングする必要があり、フィルタリングコストをユーザーに転嫁しています。一方、Nostr なども時間軸に強く関連したメカニズムを採用していますが、メインチェーンの集中性により、情報の溢れが ActivityPub プロトコルを採用した大規模な インスタンス を超えてしまい、情報の茧 から 情報の爆発 へと変化しています。ActivityPub プロトコルの設計により、ユーザーは実際には情報に対して一律の ブロック しかできず、インスタンス 管理者による情報の削除や阻止を待つしかなく、プッシュの需要を減らす可能性を考慮していません。Nostr の状況はさらに悪化しており、大量の情報がユーザーがタイムラインを探索する際にほぼブロックできなくなり、クライアントベースのフィルタリングや人間による審査が非常に困難になっています。
AT プロトコルのアーキテクチャ#
AT プロトコル の巧妙な設計は、データの保存、プッシュと発見、フィルタリングと選別、そしてユーザーが接触できるインターフェースを分離し、オープンで、友好的で、災害に強く、移行が容易で、拡張性を持たせることに成功しています。
Bluesky が論文で述べているように：AT プロトコルの設計は現代のインターネットを参考にしており、2 ウェブサイトはすべてが相互発見やインターネット全体のすべてのウェブサイトの責任を負うべきではなく、またすべてがインターネット全体のフィルタリングと選別作業を負うべきではありません。言うまでもなく、ワールドワイドウェブ は現在最も成功した 分散型自治組織 であり、その基盤に基づいて参考にすることは非常に賢明であり、思考量と作業量を大幅に削減します。インターネットは ハードウェア、ソフトウェア、および 標準 を持ち、AT プロトコル の設計にも ハードウェア、ソフトウェア、および 標準 が含まれていますが、インターネットが仮想化とコンテナ技術を利用してソフトウェアとハードウェアの境界を徐々に曖昧にしているように、AT プロトコル の ソフトウェア と ハードウェア なども将来的には元の標準実装に制限されず、融合や拡張が見られる可能性があります。
ハードウェア#
AT プロトコル の ハードウェア をインターネットにおける従来のハードウェアの一部と定義すると、AT プロトコル の公式標準実装において、個人データサーバー（Personal Data Server，PDS）、中継（Relay）、および アプリビュー（App View）3 は AT プロトコル の ハードウェア と言えます。
個人データサーバー (Personal Data Server，PDS)#
個人データサーバー はその名の通り、ユーザーデータを保存する場所です。以前の ActivityPub 実装では各 インスタンス に依存していましたが、AT プロトコル の設計では、個人データサーバー はワールドワイドウェブのサーバーに相当し、関連データを保存する実装を行うだけで済み、性能要件やコストを大幅に削減できます。家庭用 NAS や Raspberry Pi でも構築可能であり、これにより AT プロトコル に基づいて構築された分散型ネットワーク全体が、より多くのノードの参加によってより堅牢になることが期待されます。同様に、インターネットが仮想化技術を通じて独立したサーバーが複数の仮想サーバーをホストできるように、個人データサーバー も集約して運用しサービスを提供できます。例えば、Bluesky の公式運営は現在最大の 個人データサーバー 集約体であり、クラウドコンピューティングにおける IDC に似ています。
中継 (Relay)#
中継 はインターネットにおける ゲートウェイ や ルーター に似ており、個人データサーバー 同士の接続の仲介役です。中継 の最初のコンポーネントは 中継器 で、既知の 個人データサーバー のプッシュデータを取得し、データの検証を行い、検証に失敗したデータを破棄し、高頻度のスパム情報を初期フィルタリングします。中継 はこれらのデータを 中継器 を通じて集約し、パイプライン（Firehose） を作成します。3 パイプライン は アプリビュー によって 受信（Consume） されます。3 これにより、複数の 個人データサーバー をそれぞれ購読するのではなく、パイプライン を通じて情報を集約することで、個人データサーバー および アプリビュー のリクエスト数を大幅に削減でき、タイムスタンプに基づく Merkle ツリー による検証も可能です。インターネットにおいて運営回線やゲートウェイを担当する事業者が少ないのと同様に、中継 の運営は AT プロトコル のすべてのノードの中でコストが最も高く、数が少ないと予想されます。
アプリビュー (App View)#
アプリビュー はユーザーが最も明確に認識するコンポーネントであり、インターネットに例えると、インターネットに接続する端末、あるいはより具体的には APP（アプリ） に相当します。アプリビュー は 中継 からの パイプライン を 受信 し、対応する記録を 辞書 に従って処理します。Bluesky では、各投稿のいいね数を集計し、投稿の返信スレッドを整理し、各ユーザーのフォロワー集合を維持し、フォローしているユーザーの投稿を含むタイムラインを構築し、情報中のメディアファイルのアドレスを解析し、解析後のファイル（必要に応じて圧縮などの処理を行う）をユーザーに配信します。現在の接続されたアプリケーションがほぼ本質的に TCP または UDP に基づいて通信しているのと同様に、アプリビュー も AT プロトコル に基づいて通信します。しかし、TCP と UDP は通信のためのプロトコルを提供するだけであり、内容の入力、解析、出力は APP に依存しています。AT プロトコル に基づいて、ワールドワイドウェブエコシステムに類似した多くのアプリケーションが開発されることが期待されます。現在最大のアプリケーションは Bluesky というマイクロブログプラットフォームですが、将来的には既存の連邦宇宙における多くの アプリビュー が開発されることが予想されます。
ソフトウェア#
同様に、AT プロトコル の ソフトウェア をインターネットにおける従来のソフトウェアの一部と定義すると、AT プロトコル の公式標準実装において、フィード生成器（Feed Generator）、ラベラー（Labelers）3 は AT プロトコル の ハードウェア と言えます。
フィード生成器 (Feed Generator)#
ウェブサイトのディレクトリと検索は、主に 検索エンジン とそのアルゴリズムに依存しています。それに対応して、AT プロトコル の フィード生成器 はインデックス作成と選択的プッシュの役割を果たします。ユーザーは自由に検索アルゴリズムを作成し、検索エンジンを構築できるように、ユーザーは自由に フィード生成器 を自作することもできます。Bluesky は Github で便利なスタートキットを提供しています。4 また、SearXNG のように、ユーザーは検索エンジンの情報を選択し、集約することができ、ユーザーは アプリビュー 内で フィード生成器 を選択し、情報を取得し探索するために集約することができます。追加するだけで済み、アプリストアからアプリをダウンロードするのと同じように、または大量の フィード生成器 が アルゴリズム市場 を形成すること自体が AT プロトコル のビジョンです。
ラベラー (Labelers)#
ウェブサイトのコンテンツのフィルタリングと選別は、主に 広告ブロック や 詐欺防止、あるいは ファイアウォール に依存しています。AT プロトコル の ラベラー も同様の役割を果たします。ユーザーは異なる 広告ブロック ルールを購読し、重ねることができるように、ユーザーは異なる ラベリングノード を使用してデータにラベルを付け、より詳細なフィルタリングと制御を実現し、異なるユーザーの異なるニーズに配慮しつつ、運営と管理の作業を効果的に分離できます。
標準#
先ほどの定義に従い、AT プロトコル の 標準 をインターネットにおける従来の標準の一部と定義すると、AT プロトコル の公式標準実装において、DID（Decentralized Identifiers，去中心化標識）、Handle（ハンドル）、Repository（リポジトリ）、および Lexicon（辞書）3 は AT プロトコル の 標準 と言えます。
標準 の背後には、AT プロトコル のデータモデルがあります。AT プロトコル は多様なリソース識別規範を適用しており、現在は DIDs（Decentralized IDs）、CIDs（Content IDs）、NSIDs（Namespaced Identifiers ） および rkey（Record Keys） を含んでいます。5
DID (去中心化標識)#
ATプロトコル のアイデンティティ識別システムの設計が非常に優れているため、単独で取り上げます（バカではありません）
まあ、実際には長さの問題ですが、設計は確かに非常に巧妙です。
DID は一見するとインターネットのアカウントシステムに似ていますが、個人的にはインターネットにおける ドメイン名 の実現により近く、インターネットの証明書発行メカニズムを大いに参考にしています。正確には、DID は AT プロトコル のオリジナルの発明ではなく、真の発明者は W3C であり、現在数百種類の DID メソッドが存在しています（人類は本当に面倒くさいことをするのが得意です）。6 AT プロトコル の開発者たちは議論の結果、did:web メソッドと did:plc メソッドのみを採用することに決定しました。より良い 残業を避ける 要求に応じるためです。
DID の巧妙さは、それが単なる文字の組み合わせではなく、インターネットの DNS レコードのように DID を DID ドキュメント（DID Document）3 と呼ばれる JSON 配列に解釈するメカニズムを持っていることです（本質的には文字の組み合わせですが）。DID ドキュメント は AT プロトコル において Merkle ツリー 規範に従い、改ざん不可能性と検証可能性を保証します。そのため、DID ドキュメント の Merkle ツリー は時間の経過とともに操作が進むにつれて徐々に成長します。
しかし、DID の多くはハッシュに基づく圧縮メカニズムを採用しているため、DID は多くの場合、ランダムな文字の組み合わせのように見え、人間にとっては使いづらいものとなっています。これに対して、AT プロトコル の開発者たちは Handle の方法を採用し、この問題を解決しました。人間に優しいドメイン名メカニズムを通じて、TXT レコードや /.well-known/ パスの https 方法（Let's Encrypt のような無料の SSL がこのパスに慣れているはずです）を使用して、インターネットのドメイン名と DID とのマッピングを確立します。したがって、Bluesky ではユーザー名が @xxx.com となり（同時に青い V 認証問題も間接的に解決されます。example.com が特定の個人または組織の公式ウェブサイトであれば、認証を得たことになります。認証の責任を ICANN に転嫁する）
did:web メソッドの実装は Handle メカニズムに似ており、この時点でユーザーの DID はドメイン名となり、DID を解釈して JSON 配列を返すメカニズムは、ドメイン名に対応する特定の TXT レコードを照会することによって行われ、返される値は DID ドキュメント です（この場合、「似ている」を取り除いてもよく、実際に DNS 解釈です /doge）。あるいは、https 方法で /.well-known/ パスにアクセスして DID ドキュメント を取得することもできます。このようにして、Handle と DID を結びつけ、人間に優しいものにしましたが、欠点は、DID の不変性により、DID と Handle のドメイン名も不変であることです。しかし、現実にはドメインの変更などの事象に簡単に遭遇します。同時に、各 Merkle ツリー の成長に伴い、TXT レコードや /.well-known/ パスを手動で更新する必要があり、大規模なアプリケーションでは非効率的であり、ネットワーク環境の違いにより更新がタイムリーに伝達されず、ハイジャックの可能性もあります。
did:plc メソッドは、これらの痛点を解決するために設計されました。did:plc と呼ばれる理由は、開発者がこれを「プレースホルダー（Placeholder）」として扱ったからですが、明らかに今はそうではありません、did:plc の未来について心配する必要はありません。AT プロトコル の DID の対応実装において後方互換性を提供し、既存の方式が無効になるのを避けることができます。did:plc メソッドは、did:key の secp256k1 および NIST P-256 アルゴリズムを使用して DID ドキュメント の暗号化と圧縮を実現し、ネイティブな暗号化特性を持っています。
did:plc のリクエストプロセスは、PLC サーバー（PLC Server） にリクエストを送信し、3 PLC サーバー は登録されているかどうかを確認します。登録されている場合はステータスコードを返し、必要に応じて DID ドキュメント を返します。DID の更新操作の場合、PLC サーバー は検証メカニズムを通じて判断を行います。PLC サーバー は DID が分岐した場合にどのバージョンを保持するかを判断します。PLC サーバー には多様な検証メカニズムが選択可能で、ddi:plc に付属するローテーションキーを使用して検証することも、PLC サーバー が代わりにホスティングする署名キーを使用し、従来のメール - パスワードなどのメカニズムで検証することもできます（例えば、Bluesky の公式 PLC サーバー など）。便利さと安全性の選択とバランスを実現しています。
DID の利用により、AT プロトコル におけるデータ移行が非常に容易になり、ユーザーは自分の DID Merkle ツリー を更新し、新しい 個人データサーバー への変更記録を追加し、元の 個人データサーバー からメディアファイルのバックアップを新しい 個人データサーバー に移転するだけで済みます。元の 個人データサーバー が完全に消失しても、元のソーシャルネットワークを保持することができます。同時に、did:plc と拡張された Oauth 2.1 の組み合わせにより、AT プロトコル を使用して、対応する Oauth 標準のアプリにログインすることも可能です。7
Lexicon （辞書）#
ActivityPub プロトコルに基づく 連邦宇宙 で遊んだことがあるなら、異なるプロジェクト間の違いに何かしらの印象を持っているはずです。例えば、Mastodon では投稿に対して いいね という操作しかありませんが、Misskey では複数の絵文字で応答できます。Mastodon と Misskey のいずれも ActivityPub を相互接続のプロトコルとして採用していますが、Mastodon が Misskey の絵文字応答をサポートするには、Mastodon プロジェクト全体を修正する必要があります。この設計はあまり優雅ではありませんが、AT プロトコル の Lexicon の設計はこの問題を非常に優雅な方法で解決しています。
Lexicon のアーキテクチャ言語は JSON と OpenAPI を参考にしており、筆者個人の感覚では NSID は Android パッケージ名に似た役割を果たし、rkey は個々の Activity に似ています。NSID という名前空間メカニズムにより、Lexicon はより拡張しやすくなり、AT プロトコル に基づいて開発されるプロジェクトは Lexicon と アプリビュー の対応要素を設計することだけを考慮すればよく、連邦宇宙 の相互接続性と相互運用性はこれまでにないほど便利になりました。
Repository （リポジトリ）#
IPFS に関する知識がある場合、CID を見て親しみを感じるかもしれません。間違いありません、AT プロトコル の Repository は IPLD 規範に従い、Git の Merkle ツリー メカニズムを通じてバージョン管理機能を実現しています。IPLD 規範の内容アドレス指定、重複データの回避、Git と Merkle ツリー の署名検証やバージョン管理などの利点については、ここでは繰り返し説明しません。
結論#
AT プロトコル の発展は、無数の巨人の肩の上に立っており、至る所に見られるインターネット要素のマッピングから、「自分はブロックチェーンではない」と口にしつつ、8 体は非常に正直に Merkle ツリー の多くの成熟した応用に対して、前例のないプッシュのカスタマイズ性に見られる RSS の影を見つけ、データモデルにおける Git の応用まで、AT プロトコル は Twitter、ActivityPub、Nostr などの落とし穴から教訓を学び、絶えず発展し、後発の成功を収め、現在の Web3 ソーシャルプロトコルの中で最も有望な形態を実現しました。
現在の AT プロトコル のアプリケーションには、依然としてかなりの中央集権的な現象が存在し、Bluesky は多くの状況で唯一の選択肢ですが、Bluesky の声明に従って発展していくなら、AT プロトコル はますますオープンになり、AT プロトコル の優れた特性が多くの開発者を引き付けることが予想され、未来のエコシステムに期待が持てます。𝕏 はかつてのネットスケープ社のようであり、その中から生まれた Bluesky が Mozilla のようなオープンな組織となり、技術をよりオープンで透明、公平かつ相互接続の方向に推進することを願っています。
原文アドレス：https://blog.iceyear.eu.org/atprotocol-study