Loading article…
ATプロトコル（Authenticated Transfer Protocol、発音は「アットプロトコル」、一般的にはATprotoまたは「ATP」と略される）[ 1 ] [ 2 ]は、ソーシャルウェブ内で自己認証データの分散型公開および配信のためのプロトコルおよびオープン標準のセットです。[ 3 ] [ 4 ]これは、元々はプロトコルのリファレンス実装として開発されたBlueskyソーシャルネットワークの技術的基盤として機能し、また、ATmosphereと総称される相互運用可能なソーシャルアプリケーションおよびサービスの生態系としても機能します。[ 5 ] [ 6 ] [ 7 ]
ATプロトコルは、 ActivityPubやNostrなどの以前の分散型ソーシャルネットワーキングプロトコルで認識されていた問題に対処することを目的としています。これには、ユーザーエクスペリエンス、意味的相互運用性、発見可能性、ネットワークのスケーラビリティ、ユーザーデータとソーシャルグラフの移植性などが含まれます。[ 4 ]モジュール式のマイクロサービスアーキテクチャと、フェデレーションされたサーバー非依存のユーザーIDを採用することで、ネットワークサービス間のシームレスな移動を可能にし、単一の特権エンティティに依存することなく統合されたオンラインエクスペリエンスを提供することを目指しています。[ 8 ]
2026年1月現在、プロトコルの一般的なアーキテクチャ、ユーザーリポジトリ、およびデータ同期仕様は、インターネット技術タスクフォース（IETF）内で標準化の過程にある。[ 3 ] [ 9 ]データスキーマ、IDシステム、 OAuth実装、プライベート/限定可視データなどのさらなる仕様は、 Bluesky Social PBCによって開発中である。同社は、現在の取り組みの結果次第で、将来的にIETFを通じて追加の仕様の標準化を目指す可能性があると述べている。[ 9 ] [ 10 ] [ 11 ]
ATプロトコルは、フェデレーションされたアイデンティティの作成を容易にするように設計されており、ユーザーは複数のプラットフォームやサービスにわたって1つのオンラインアイデンティティを保持、管理、カスタマイズできます。独立したホストやその他のネットワーク参加者は、フェデレーションされたネットワーク全体のデータストリームから定義済みのデータスキーマとしてフォーマットされたコンテンツを取得することにより、ネットワーク内の任意のユーザーコンテンツにアクセスして提供できます。[ 12 ] [ 13 ] Bluesky Socialは、このプロトコルを「オープンウェブをモデルにしたもの」と説明しています。[ 8 ]
ActivityPubなどの他のソーシャルネットワーキングプロトコルでは、実装は通常、ユーザーデータとアプリケーションの両方をホストするモノリシックサーバーとして設計されていますが、このプロトコルではこれらの要素をより小さなマイクロサービスに分割し、必要に応じて使用できるようにします。[ 14 ]
ATプロトコルのクライアントとサービスは、関連データの送受信にJSONを使用するXRPC（Cross-organizational Remote Procedure Calls）[ 15 ]と呼ばれるHTTP APIを介して相互運用します。 [ 16 ]さらに、認証、参照、または保存する必要のあるプロトコル内のすべてのデータはCBORでエンコードされます。[ 17 ]
ATプロトコルは、ドメイン名の形式で表される可変ハンドルと、不変の分散型識別子（DID）という二重の識別子システムを利用しています。[ 18 ]
ハンドルは検証可能なユーザー識別子として機能します。検証は、ドメイン名の制御を証明する2つの同等の方法のいずれかによって行われます。ハンドルと同じ名前のリソースレコードに対するDNSクエリ、または同じ名前のWebサービスからのテキストファイルの要求のいずれかです。[ 19 ]
DID はDID ドキュメントに解決され、そこにはユーザーのハンドル、公開鍵、データ リポジトリなど、キー ユーザーメタデータへの参照が含まれています。 [ 20 ]理論的には、コンポーネントがそのメソッドをサポートしていれば、どの DID メソッドでもプロトコルで使用できますが、実際には、プロトコルの参照実装でサポートされている (「承認済み」) メソッドは と の 2 つだけです。[ 21 ]これらの識別子の有効性は、それぞれ、 DID に関連付けられたドキュメントをホストするレジストリと、接続されたドメイン名のよく知られた場所にホストされているファイルによって検証できます。did:plcdid:web
これらの DID メソッドの使用は、プロトコルの分散性を損なう可能性がdid:plcあるとして批判されてきた。特にこのメソッドは、現在の実装と一般的な使用法が Bluesky Social がホストする単一のレジストリに依存しており、ドキュメントの現在の状態を独立して検証するシステムがないため、プロトコル内の単一障害点として指摘されている。同社は、ディレクトリをスイス協会として法人化される独立組織に移管することを約束しており、また、PLC メソッドのアーキテクチャを、中央集権型の単一ライター レジストリという現在のモデルから変更できる可能性を示唆している。[ 22 ]
サービスは、サブドメイン(例: )@username.bsky.socialを使用して新規ユーザーにサインアップ時にハンドルを割り当てることができます。あるいは、ユーザーは、ドメインのレコードにTXT レコードを追加するか、特定のよく知られた URIへの HTTP リクエストに応答してドメインまたはサブドメインをユーザーの DID に関連付けることで、カスタム ドメインまたはサブドメインをハンドルとして設定できます (例: または )。[ 23 ] [ 24 ]@username.com@username.wikipedia.org
このプロトコルの二重識別子システムは、エンドユーザーサービスで使用するためのユーザーフレンドリーな識別子と、プロトコル内での一貫した暗号化されたIDの両方を提供すると同時に、プロトコルレベルで堅牢なTCP/IPベースのアカウント検証メカニズムも提供します。 [ 19 ]
プロトコル内のユーザーデータは、専用のデータリポジトリ、つまり「リポジトリ」に保存されます。各ユーザーは単一のリポジトリに関連付けられており、そのリポジトリに対する排他的な管理権限を持っています。リポジトリには、投稿、いいね、フォロー、ブロックなどのアクションを記録するユーザーレコードの変更可能なコレクションが含まれています。レコードは永続的であり、ユーザーからの明示的な要求があった場合にのみ追加または削除できます。[ 25 ]
リポジトリのコレクション内の各レコードには一意のレコードキーが割り当てられ、ネットワークエージェントはこれを使用してユーザーのリポジトリ内のレコードを参照します。現在のレコードキーの実装は、レコードの作成時間から派生したタイムスタンプ識別子（TID）です。 [ 26 ]リポジトリは、レコードをTIDに基づいて時系列順にソートするマークル検索ツリーにコレクションを保存します。[ 27 ]
メディアファイルは、メタデータ、サイズ、メディアタイプとともに、リポジトリとは別に、非構造化バイナリデータの一種であるブロブとしてユーザーのホストサーバーに保存されます。[ 28 ]これにより、ネットワークエージェントは、元のスキーマやアップロードコンテキストに関係なく、任意のメディアファイルにアクセスして処理することができます。[ 29 ]
現在、リポジトリ内のすべてのデータは公開されていますが、プロトコルにプライベートデータを追加する計画があります。[ 30 ]
パーソナルデータサーバー（PDS）は、ユーザーリポジトリとその関連メディアをホストします。また、ユーザーのネットワークアクセスポイントとしても機能し、リポジトリの更新、バックアップ、データクエリ、ユーザーリクエストを容易にします。[ 8 ]
プラットフォームクライアントは、ユーザーに代わってPDSにクエリを実行することでプロトコルにアクセスし、 PDSはネットワーク内の他のサービスから要求されたデータを取得します。この設計は、プロトコルの相互作用とサービスがモノリシックなホストサーバーによって処理されるActivityPubとは異なります。ネットワークイベントはプロトコルのネットワーク全体のインデックスインフラストラクチャを通じて解決されるため、設計上、個々のPDSの可用性はユーザーエクスペリエンスにほとんど影響を与えません。[ 31 ]
ATプロトコルはデータポータビリティを優先し、敵対的なPDSの場合でも、ユーザーがデータ損失なしにリポジトリと関連メディアをバックアップおよび移行できるようにします。[ 32 ]プロトコル内のPDSの設計により、動作に必要な計算要件が低くなり、個人またはグループが大きな計算リソースを必要とせずに独自のPDSを実行できるようになります。[ 4 ]
ほとんどのユーザーのリポジトリはBluesky Socialが運営するPDSにありますが、ネットワーク内には多くの独立したPDSが存在します。[ 2 ]
リレーはプロトコルのインデックス作成インフラストラクチャの重要なコンポーネントであり、ネットワーク内のコアインデクサーとして機能します。[ 8 ]リレーは、PDS からリポジトリの更新を継続的に取得してネットワークをクロールし、これらの更新を集約、インデックス化して、ネットワーク全体のデータ ストリーム(まとめてファイアホースと呼ばれます) に転送します。[ 13 ]ファイアホースはすべてのネットワーク エージェントが利用でき、ネットワーク内の任意のサービスで使用できます。[ 4 ]リレーは、ネットワーク全体または一部をインデックス化することを選択できます。[ 8 ]
リレーは、ユーザーデータのクロールや保存の必要性を排除し、統一されたデータストリームを提供することで、プロトコル内のアプリケーションやサービスの開発を簡素化し、運用コストを削減します。[ 33 ]
リレーは、ネットワークにおいてほぼ不可欠な役割を果たしているにもかかわらず、リレーを運用する明確なインセンティブがないため、プロトコルの設計において最も中央集権的なコンポーネントであると批判されてきた。 [ 34 ] [ 35 ]
AppViewsは、現代のソーシャルネットワーキングサービスに類似しており、プロトコル内のエンドユーザープラットフォームおよびサービスであり、ユーザーのPDSからのクエリに応じてリレーからユーザークライアントにデータを消費、処理、配信します。投稿、いいね、フォロー、返信などのファイアホースからのネットワーク全体の情報を使用して、クライアント内でカスタマイズされたユーザーエクスペリエンスを作成します。[ 4 ]
プロトコル内の AppView の設計により、実装に大きなバリエーションが生まれます。AppView は、招待システム、カスタムアルゴリズム、代替クライアント、さまざまな収益化およびコンテンツモデレーション戦略、プロトコル外サービスを実装できます。[ 36 ]これらの違いにもかかわらず、すべての AppView は、ファイアホースから取得した同じデータで動作します。このアーキテクチャにより、AppView の計算負荷とストレージ要件が軽減され、ユーザーが投稿、フォロー、いいねなどを保持したまま AppView 間を簡単に切り替えることができるため、ユーザーのロックインが防止されます。 [ 37 ]
このプロトコル上で最大のAppViewは現在Blueskyですが、Blacksky（黒人のソーシャルメディアユーザーを支援するプロジェクト）、Frontpage（Hacker NewsスタイルのソーシャルニュースWebサイト）、Smoke Signal（RSVP管理サービス）などの他のAppViewもプロトコル内で利用可能です。[ 38 ] [ 39 ] [ 40 ]
ATプロトコル内のすべてのレコードとXRPC呼び出しは、さまざまなサービスとプラットフォームのモダリティをサポートするために、レキシコンと呼ばれる特定のグローバルスキーマ言語に従います。[ 41 ]プロトコル内のAppViewは、独自のレキシコンを定義するか、既存のレキシコンを利用する柔軟性があります。
このアプローチにより、AppView は、より広範なネットワークとの互換性を維持しながら、特定のユースケースに合わせたカスタム語彙集を作成できます。たとえば、マイクロブログに特化した AppView に表示されるレコードは、動画共有に特化したレコードとは異なる語彙集を使用する可能性が高いです。これは、コンテンツの種類によって必要な属性のセットが異なるためです。[ 8 ]
しかし、AppView は、コンテンツが元々ネットワーク内の別の場所に投稿されていた場合でも、他のAppView によって定義された語彙を使用してコンテンツを提供することもできます。 [ 12 ]例えば、新しいマイクロブログ AppView は、既存の競合他社によって定義された語彙を使用して以前に投稿されたコンテンツを提供することを選択でき、既存のコンテンツとの互換性を維持しながら新しい機能やサービスを提供できるようになります。
このスキーマ設計は、コンテンツへの排他的アクセスに頼るのではなく、独自のユーザーエクスペリエンスと追加機能によってAppViewを差別化することで、ユーザーの囲い込みをなくし、ユーザー中心のイノベーションを促進することを目的としています。[ 42 ]
レキシコンは、名前空間識別子（NSID）を使用してレコード内で参照されます。NSIDは、ドメイン名の逆順のドメインオーソリティと、それに続く任意の名前セグメントで構成されます。[ 43 ]例えば、は有効なNSIDです。ここで、はドメインオーソリティ、は名前セグメントです。com.example.foocom.examplefoo
プロトコルで最も人気のあるレコード語彙集はapp.bsky、Blueskyのマイクロブログスキーマを定義します。[ 12 ] XRPC呼び出し用の語彙 com.atproto集は、サービス全体で広く採用されるべきエンドポイントに使用され、仕様で参照されています。
意見表明型サービスとは、プロトコル内でファイアホースからのデータを処理し、コンテンツのモデレーションとキュレーションを目的としてネットワークデータに対する主観的な判断を提供するサービスのことです。これらのサービスは、リレーの意図された「意見表明をしない」性質とは対照的です。[ 4 ]意見表明型サービスにより、ユーザーはプロトコルのコアコンポーネントの相対的な中立性を維持しながら、プロトコル内でコンテンツの消費とモデレーションの好みをカスタマイズできます。
ユーザーは、クライアントアプリを通じていつでもこれらのサービスに登録および登録解除できます（ただし、ユーザーの現在の AppView にハードコーディングされている場合は除きます）。 [ 36 ]これらのサービスのモジュール性により、プロトコル内でのコンテンツのキュレーションとモデレーションに対して、カスタマイズ可能で積み重ね可能なユーザー中心のアプローチが可能になります。[ 44 ]
ラベラーは、スパムや不適切なコンテンツを識別するなど、ユーザー生成コンテンツに関する判断を下します。これらのラベルは、投稿、画像、アカウントなど、ネットワークのさまざまな側面に適用できます。ラベラーの出力は、AppViewとPDSによって消費され、その後、非表示、ラベル付け、ぼかしなど、ラベル付けされたコンテンツを処理するためのさまざまな戦略をユーザーに提供できます。[ 45 ]
Bluesky Socialは、社内のラベル付けモデレーションサービス「Ozone」をオープンソース化し、ユーザーがネットワーク向けにカスタムモデレーションサービスを作成できるようにした。[ 46 ] [ 44 ]
ラベラーはモデレーションサービスとして使用できるだけでなく、投稿トピックやユーザーの代名詞にラベルを付けたり、ユーザーのプロフィールや投稿に肯定的または遊び心のあるラベルを追加したりするなど、情報提供や娯楽目的にも使用できます。[ 47 ]
フィードジェネレーターは、カスタム Bluesky フィードに含めるために、ファイアホース内の Bluesky の投稿を処理します。PDS クエリの後、投稿 ID のリストをユーザーの AppView に返し、それを使用してキュレーションされたフィードを作成できます。[ 48 ] [ 49 ] Bluesky はカスタムフィードを生成およびホストするための組み込みツールを提供していませんが、Graze などのサービスは、ブロック コーディングを使用してフィードを作成およびホストし、挿入された広告で収益化するためのツールをユーザーに提供しています。[ 50 ]
ATプロトコルは、 Twitter社内でサービスの分散化の可能性を調査するために設立された公益法人Bluesky Social PBCによって開発が開始されました。プロトコルのリファレンス実装は、2022年5月4日にAuthenticated Data Experiment（ADX）という名前でGitHubに初めて公開され、 MITライセンスとApacheライセンスの両方でライセンスされています。 [ 51 ] 2022年10月にATプロトコルにブランド名が変更されました。[ 52 ]
2025年3月、シアトルでATプロトコルに焦点を当てた初のカンファレンス、ATmosphereConfが開催された。[ 53 ] [ 54 ]このカンファレンスでは、Blueskyソーシャルネットワークを超えたATプロトコルの可能性を探ることに重点が置かれた。セッションでは、分散型ソーシャルネットワーキング、アイデンティティの移植性、アプリケーション間の相互運用性に焦点が当てられた。
2025年9月、IETFはATプロトコルのコアサービスの仕様に関するインターネットドラフトを公開した。 [ 55 ] 2026年1月には、標準化を担当するワーキンググループの憲章が公開された。[ 3 ]
ATプロトコルは、 Blueskyソーシャルネットワーク（Bluesky Social PBCによって開発された）で採用されており、最も普及している実装です。Bluesky Socialが運営していない他のサーバーと連携する機能がないままサービスを開始したため、ソーシャルネットワーク自体は2024年2月下旬に他の個人データサーバーとの連携を開始しました。[ 56 ]さらに、ニュースアグリゲーターのFlipboardでは、ユーザーがBlueskyアカウントでログインして、サービスからの投稿を表示したり操作したりできます。[ 57 ]採用を促進するため、Bluesky Socialは、ATプロトコルを使用して連携またはコンテンツを作成する、あるいはその両方を行うさまざまなプロジェクトに助成金を通じて資金を提供しています。[ 58 ]助成金によって資金提供されている注目すべきアプリケーションは、SkyBridgeと呼ばれるプロキシサーバーで、 MastodonアプリからのAPI呼び出しを同等のATプロトコルおよびBluesky APIに変換できるため、公式サポートがなくても両方のネットワークにアクセスできます。[ 59 ]
AT プロトコルは他のプロトコルとは技術的に大きな類似点のない独立したプロトコルですが、プロトコル間でコンテンツを橋渡しできるサービスが開発されています。例としては、ActivityPubプロトコルで行われたすべての投稿と、AT プロトコルで Bluesky 語彙を使用した投稿の間でコンテンツをクロスポストできる Bridgy Fed ソフトウェアがあります。 [ 60 ] [ 61 ] Nostrからの投稿は、Nostr から ActivityPub にノートをクロスポストできる別のブリッジを介して、AT プロトコルに「二重に橋渡し」することもできます。[ 62 ]
Blueskyの人気が高まるにつれ、このプロトコルは独立系開発者と投資家の両方からより多くの注目を集めるようになりました。ほとんどの開発者は、既存のコンテンツにアクセスでき、開発が迅速に行えるため、BlueskyのAPIサブセットのみをターゲットにすることを選択しています。その中でも注目すべきは、Instagramに似たクライアントであるFlashes [ 63 ]と、TikTokに似たショートビデオプラットフォームとして設計されたクライアントであるSkylightです。Skylightは、米国でのアプリの（当時）差し迫った禁止を受けて、プロトコル上でアプリケーションの代替を開発するよう呼びかけた後、アメリカの起業家マーク・キューバン[ 64 ]によって支援されました[ 65 ]。
Blueskyとの互換性に重点が置かれているにもかかわらず、BlueskyのAppViewや語彙集とは独立して開発されたアプリもあり、許可されるコンテンツに関してより柔軟性が高まっている。[ 66 ]その例としては、以下のようなものがある。
2026年5月、AutomatticはWordPressプラグイン「ATmosphere」をリリースしました。これはコンテンツ管理システムをATプロトコルに統合するものです。このプラグインはapp.bsky.feed.postBlueskyでの表示用に標準レコードを公開し、Standard.siteの語彙集を使用して各記事をレコードとして保存することで、他のATプロトコルアプリケーションが長文記事全体を独立してレンダリングできるようにします。[ 72 ]
2025 年 8 月、AT プロトコルの一部が、作業部会を形成しないBirds of a Feather (BOF) 提案としてインターネット技術タスク フォースに提出されました。これは主に IETF コミュニティからのフィードバックを受けることを目的としていました。 [ 73 ]同年 9 月、プロトコルのリポジトリ フォーマットとデータ同期プロセスの仕様書、およびプロトコルのアーキテクチャの概要に関するインターネット ドラフトが IETF に提出されました。 [ 9 ] [ 74 ] [ 75 ]
{{cite web}}: CS1 maint: url-status (リンク)