誰もが、この宇宙の中で対応する星が輝いている。
アーサー・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プロトコル のアイデンティティ識別システムの設計が非常に素晴らしいため、単独で取り上げます（bushi）
まあ、実際には単に長すぎるからですが、設計は確かに非常に巧妙です。
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 方法の無効化を避けるためです。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