この投稿は、Daniel HolmgrenがAtmosphereConf（2025年3月）で行った講演のブログ版です。
ATプロトコル（またはatproto）は、分散型ソーシャルアプリケーションを作成するためのプロトコルです。
同じ目的を掲げるプロトコルは初めてではありません。分散型ソーシャルメディアプロトコルの歴史の中で、atprotoは独自のアプローチを取りつつも、それ以前の技術やムーブメントから深い影響を受けています。
「atproto ethos」という言葉は、私たちのプロトコル設計の議論の中でよく登場します。曖昧な用語ではありますが、ネットワーク設計の根底にある哲学的・美学的な原則を指すために使っています。
この投稿では、そのethosを掘り下げます。まず、atprotoに最も直接的な影響を与えた技術的ムーブメントを見ていきます。次に、atprotoがもたらした中核的な革新を取り上げます。最後に、設計に影響を与えた主張の強い思考様式をいくつか紹介します。
3つのムーブメントの交差点にあるatproto
ウェブ
atprotoへの最初で最も明白な影響は、ウェブそのものです。
ウェブは、インターネット上で文書を公開しアクセスするための情報システムです。参加や相互作用に許可は不要です。この保証は、下層のインターネットにおける同様の保証を前提としています。インターネットが正しく機能していて、コンピューター、インターネット接続、そしてIPアドレスがあれば、誰でもウェブ上で文書をホストできます。
ウェブの許可不要性には、コンテンツの権限が分散していることが必要です。つまり、ウェブに何を含めるか、あるコンテンツが「正当」かどうかを決める権威は存在しません。代わりに、文書を公開・ホストする各コンピューターが、その文書の権威となります。この権威は場所に基づくもので、あるサイトにホストされた文書が何かは、そのサイトと通信して文書を受け取ることで分かります。言葉にすると当たり前に聞こえますが、実はこれはラディカルな発想です。配布業者や文書の認証者、文書の中央レジストリは必要ありません。
この開放性がウェブのガバナンス上の決定的特徴である一方、プロダクト上の決定的特徴はハイパーリンクです。ハイパーリンクは文書内のリンクで、別の文書へ導きます。特筆すべき点は、これらのリンクが相手の権威の許可なしに権威をまたいでリンクできることです。その結果、ウェブは孤立して公開された無関係な文書の集合ではなく、相互に接続されたデータの巨大な統合ネットワークになります。
ここで述べた文書ベースのウェブは、一般にWeb 1.0と呼ばれます。しかし、ここ20年私たちが暮らしてきたWeb 2.0は、形と機能が大きく異なります。
現代のウェブは主にFacebookやYouTubeのような少数の巨大プラットフォーム上で展開され、ユーザーはそこにアカウントを持ってコンテンツを投稿し、他のアカウントのコンテンツを閲覧・交流します。これらのやり取りやコンテンツは、伝統的な意味での「文書」に見えないことが多いです。コンテンツ同士は依然として深く相互接続されていますが、その接続は一般に作成されたプラットフォームの境界内に制限されます。
この新しいウェブは参加がはるかに容易です。ウェブ上でコンテンツを公開するためにサーバーの運用方法や固定IPアドレスの取り方を知る必要はありません。アカウントを作成するだけでよいのです。そして最も重要なのは、現代のウェブがより豊かで動的なコンテンツと相互作用を支えられることです。リアルタイムの会話、ネットワーク内で起きるすべてのことのグローバルなビュー、そして膨大なデータのネットワークを通じてユーザーの注意を惹くアルゴリズムなどです。
文書ベースのウェブが現代のウェブへ進化したことは、ウェブの失敗と見るべきではありません。むしろ、その成功の証です。ウェブを支える理念、思想、プリミティブは十分に強力で柔軟だったため、実質的にウェブの上に2つ目の層の創出を可能にしました。しかしこの進化の中で、私たちは何かを失ってもいます。
ピアツーピア
ピアツーピア（P2P）ムーブメントは、色々な意味で現代のウェブを支配する巨大プラットフォームの出現への反動でした。理想主義的で急進的（時に行き過ぎるほど）なこのムーブメントは、バックエンドアプリケーションを完全に排除できないかと問いかけました。
コンテンツや相互作用を調整役のバックエンドサービスへ送る代わりに、ソーシャルメディアのユーザーは、自分のデバイスから別のデバイスへ直接関連データを送ります。2人のユーザーが互いにフォローしていて片方が投稿した場合、もう片方は直接接続によってその投稿を受け取ります。もちろん、データ転送のためには両者が同時にオンラインである必要があります。P2Pシステムは、多数のデバイスにデータを複製することでこの問題を回避しようとしました。したがって、ユーザーは投稿者本人から投稿を受け取ることも、現在オンラインでその投稿を保持している別の友人から受け取ることもできます。
これにより、P2Pはウェブの伝統的な場所ベースの権威モデルから離れ、自己証明データへと向かいました。データは元の作成者ではないデバイスから届く可能性があり、たとえ正規のデバイスから来ていても、そのデバイスはアカウントに紐付いた固定IPを持たないことが多いのです。結果として、P2Pプロトコルはデータの権威をデータの置場からデータそのものへ移しました。
P2Pデータは、多くの場合データのハッシュで指定され、投稿者が保持する秘密鍵で署名されます。これにより、投稿者由来の権威を保ったまま、コンテンツを任意に再配布できます。したがってクライアントは、既知のハッシュを持つコンテンツを探すために抽象的な「ネットワーク」へ問い合わせればよいのです。うまく機能しているとき、コンテンツアドレッシング型ネットワークは、データが協調するデバイスによるメッシュのどこかに「ただ存在する」かのような美しい性質を持ちます。受け取るデータが話しかけるサービスに依存する従来のロケーションアドレッシング型ウェブと異なり、P2Pシステムのデータは場所ではなくデータそのものが本質であるという性質を持っています。
もちろんこの抽象化が常に完璧に機能するわけではなく、この新しいトポロジーは多くの問題、特にデータの可用性と発見性の問題をもたらしました。前述の通り、あるデータの投稿者がオフラインなら、ネットワーク内の別のデバイスからそのデータを見つける必要があります。どのデバイスがそのデータを提供できるのかを見つけるのは難しい問題で、特にデバイスが異なるアドレスで頻繁にオンライン/オフラインを繰り返す場合はなおさらです。探しているデータを送れるオンラインデバイスが1台もないことすらあり得ます。すべてがうまく動いていても、ネットワーク分断がはるかに一般的で、ネットワーク内に全データのグローバルビューを持つと主張できるサービスがないため、これらのシステムは結果整合性に強く依存せざるを得ません。
もう一つの大きな問題は、現代のウェブでユーザーが慣れ親しんだリッチなソーシャルメディアが、大規模な計算・ストレージ集約型のインデックスに依存していることです。サーバーを排除することは、そのリソース消費がすべてユーザーのデバイスに移ることを意味します。タイムライン生成、スレッド構築、インタラクション数の集計、ソーシャルグラフのクエリなどを、相対的に非力なエンドユーザーデバイスで行わなければなりません。
結果として、これらのP2Pプロトコル上に構築された製品はしばしば不安定に感じられます。投稿や反応が欠け、グローバルなアルゴリズムを作れず、アプリの実行はバッテリー寿命やデバイス資源に目に見える負荷を与えます。要するに、現代ウェブの巨大プラットフォームが持つシームレスで動的な感覚を再現するのは現実的ではありません。
データ集約型の分散システム
P2P技術が探求される一方で、現代のウェブを構成するプラットフォームは規模を拡大し続けました。ウェブ参加の障壁が下がるにつれ、数百万、やがては数十億の人々がウェブに参加し、コンテンツを生成するようになりました。
これらのプラットフォーム上のコンテンツは、単に静的に提供される文書ではありません。これらのプラットフォームは毎日何十億ものインタラクションを処理します。それらのインタラクションは、プロフィールページ、ニュースフィード、スレッド、いいね数など、リッチで動的なビューとしてユーザーに提供されます。
これらのプラットフォームは読み取りが非常に多いため、単にデータを処理するだけでは不十分です。コンテンツが一つ作られるたびに、他のユーザーからの数百〜数千のリクエストを処理する必要があります。プラットフォームがより包括的になるにつれ、可用性やレイテンシに対するユーザーの期待も高まりました。ダウンタイムやサービス劣化は許容されにくくなり、企業に数百万ドルの損失を与えることもあります。
これらの要因は、サービス構築のための新しいツールやアーキテクチャを必要としました。これらの技法の概観は、Martin Kleppmanの著書『Designing Data Intensive Applications』に最もよくまとめられているかもしれません。プラットフォームはそれぞれ異なり、競合するツールや手法も多いものの、それでも一般的な傾向をまとめることはできます。
これらのプラットフォームは読み取りが非常に多いため、一般に読み取りと書き込みの負荷を分離することで、それぞれ独立にスケールさせます。単純な例としては、データベースの読み取りレプリカを導入する方法があります。単一の「リーダー」データベースがある一方で、多数のレプリカが過大な読み取り負荷をさばきます。
しかし、これらのプラットフォームを支える膨大なデータ量と計算量は、単一のマシンでは処理できません。したがって、ひとつのプラットフォームのデプロイ内でも作業は多数のマシンに分割する必要があります。よくあるパターンは、アプリケーションを小さな「マイクロサービス」に切り出し、それらが相互に呼び出し合いながら大きなプラットフォームを構成することです。各サブシステムの関心を分離することで、チームはそれぞれの必要に応じてスケールできます。例えば、フィード生成と動画トランスコードは大きく異なるため、それぞれに適したマシンでホストすることで恩恵を得られます。
分散システムの導入は、分散による問題も導入します。分解されたマイクロサービスは、プラットフォーム上のすべてのデータについて強い一貫性を保つという考えを放棄します。場合によっては、Blueskyが使っているScyllaのような、高スループット向けの結果整合性を備えたデータベースを使うことを意味します。Scyllaのようなデータベースは、従来のSQLデータベースが提供するACID特性やリッチな動的クエリのサポートを手放します。代わりに、データのインデックスとアクセスパターンを事前に把握しておかなければいけません。
新しいデータベース技術の導入やマイクロサービス化の流れは、さらに多くの問題をもたらしました。マイクロサービスはしばしば同じデータへアクセスする必要があります。マイクロサービスがしばらく停止した場合、その間に起きたすべてに追いつく仕組みが必要です。さらに、過去のデータを含めて新しいインデックスを作る手段も必要になります。ストリーム処理のアプローチは、こうした問題の多くに答えを与えました。Kafkaに代表されるストリーム処理アーキテクチャでは、システムを流れるすべてのイベントのログを保持します。多くのコンシューマーがこのイベントログに接続します。コンシューマーがオフラインになっても、復帰時に中断点から再開できます。新しいインデックスが必要になれば、イベントログ全体をリプレイすればよいのです。これらのストリーム処理ツールは、プラットフォームが信頼できる唯一の情報源に収束するための背骨として機能します。
統合
atprotoは、3つのムーブメントを統合したものとして位置づけられます。-
ウェブから：開かれており、許可不要な、相互接続コンテンツの単一ネットワーク
-
P2Pから：位置に依存しないデータ、自己証明データ、ユーザー体験のあらゆる側面に対する中央集権的支配への懐疑
-
データ指向分散システムから：読み取り/書き込み負荷の分離、高スループットと低レイテンシのためのアプリケーション向けセカンダリインデックス、正規データのストリーミング、モノリスからマイクロサービスへの分割
イノベーション
この基盤の上に、atprotoは2つの核となるイノベーションを加えます。IDに基づく権威と、データホスティング層をその上のリッチなアプリケーションから分離することです。
IDに基づく権威
atprotoのデータモデルはP2Pネットワークのそれに非常に似ています。大きな違いは、単なるコンテンツアドレッシングではなく、間接層を追加してデータをIDアドレッシング化している点です。したがって、at-uriはat://username/record-type/record-keyのようになります。
このデータのIDアドレス化は、ロケーションアドレッシングデータというウェブ的モデルの裏返しです。従来のウェブでは場所（またはサーバー）が主対象ですが、atprotoではユーザーが主対象です。
IDは長期間維持され、今いる場所から切り離されています。P2Pネットワークではデータが主体ですが、このスタックの主体はIDへと移ります。IDは特定のホストやアプリケーションに依存せずに存在し、それらの間を流動的に移動できます。ネットワーク内のデータはこれらのIDが源流となり、IDをデータの集まりに解決する仕組みと、新しいコンテンツが生成された際にリアルタイム更新を受け取る仕組みが明確に定義されています。
IDは、そのIDのデータの真正性を検証できる鍵材料と、消費者がそのIDデータの正規の最新状態を取得するための特定のホストへ解決されます。これらのユーザーデータの正規ホストは、パーソナルデータサーバー（PDS）として知られています。
各IDには1つ正規のホストがありますが、そこから出てくるデータは自己証明的で自己記述的です。つまり、ネットワークに向けて任意に再配信できます。ユーザーデータの利用者は、その正規ホストに直接アクセスする必要はありません。代わりに、正規データホストをクロールしてネットワークの特定範囲に対するストリームを出力する外部サービスを利用できます。
IDが出力するデータは「レコード」のリポジトリという形を取ります。各レコードは構造化データの断片で、投稿、いいね、フォロー、プロフィールなどを表します。ウェブでは主対象は文書であり、文書はハイパーリンクで結び付けられます。atprotoでは主対象はレコードであり、レコードはat-uri参照によって結び付けられます。
汎用ホスティングと集権型プロダクト開発
PDSのデータモデル（リポジトリ）は汎用的なものです。PDSの役割はとてもシンプルで、ユーザーデータのホスティングとアカウント/ID管理だけです。この単純さは意図的であり、データ層を強靭でロックインされない状態に保つために重要です。PDSがアプリケーション固有のロジックや高価なインデックス処理で過積載になると、ベンダーロックインや中央集権化へインセンティブが歪むリスクがあります。
PDSからアプリケーション固有の詳細を切り離すことのもう一つの側面は、アプリケーションに実験と迅速な反復の自由を与えることです。プロダクト開発は集権的に行えます。この集権性は、ネットワーク上で新しいプロダクトの構築し易さのために重要です。私たちはプロダクト開発において「後退なし」という考え方を採用しました。プロジェクトは現代的なツールやプロダクト/アプリ開発パターンを使えるべきです。プロダクトは迅速な反復の恩恵を受けるため、そのためにはアプリケーション領域の明確な所有が必要です。
この所有権は、atprotoネットワークのスキーマ言語に反映されており、スキーマIDに所有権の概念が組み込まれています。スキーマの所有者は、アプリケーションのデータモデルを自由に反復・進化させられます。同様に、アプリケーションの所有者は自分に適した方法でバックエンドを構築できます。atprotoネットワークには独自性の境界が存在します。IDとデータがその境界を越えた後は、どのようにインデックスし、ユーザーに提示するかはアプリケーションの判断になります。
プロダクト開発が集権的であっても、atproto上に構築されているため、基盤となるデータとIDは開かれており普遍的にアクセス可能です。言い換えれば、特定アプリケーションの進化に関する所有権は明確ですが、データがオープンである以上、ネットワーク内の他の誰でも再利用・リミックス・拡張できます。
設計へのこだわり
構造が自由をもたらす
atprotoは多者間・低協調のネットワークです。サービスは許可不要で参加し、それぞれのポリシーで運用できます。調整の痛みはある程度避けられませんが、atprotoは非常に構造化されたプロトコルであることで、最悪の事態を避けようとしています。これはプロトコルの多くの設計判断に反映されています。例えば、正規化CBORでエンコードされたレコード、至る所に現れるmultiformats、unicit（挿入順序に依存しない決定的構成）なデータ構造を持つリポジトリ、許可されたDID/ハッシュ関数の制限、さらにはOAuthでDPoPを要求することなどです。
何でもできるという考えには力強さがありますが、同時に構造なき専制へ陥りやすく、結果として協調が崩壊し、何も進まなくなります。ネットワークに構造がなければ、新しい開発に注げるはずのエネルギーは、相互運用の協調、実装間のエッジケース修正、悪意ある参加者や他者由来のセキュリティ問題への防御、明確なリーダー不在での進化の調整へと振り向けられてしまいます。
この構造は、おそらくatprotoのスキーマ言語であるLexiconに最もよく表れています。RDFのようにデータ上の属性を一般化して表現しようとする手法や、Lensのように異なるドメイン間でデータを翻訳して相互運用を実現しようとする手法とは異なり、Lexiconは二者が同じ言語を話しているかを判断する方法と、データが正しく整形されていることを保証するための非常に構造化された仕組みを提供します。
これにより、atprotoは「だいたい同じことを話しているけれど実は違う」というグレーゾーンを避け、同じことを話すならまったく同じことを話すという離散的な選択をアプリケーションに強います。意味の普遍性を仮定しようとするのではなく、atprotoは特定のセマンティクスを促進し、その協力と拡張を可能にします。
後回し信頼
ウェブでは、やり取りするサービスに対する相当の信頼が必要です。トランスポート層が保護されていても、特定のサーバーから受け取るデータの正しさは、そのサーバーから受け取ったという事実だけで証明されます。例えばFacebookで友人の投稿を読み込む場合、Facebookが正しい投稿本文を提供していると信頼しなければなりません。同様に、アカウントとデータの良き管理者であることもFacebookに信頼を置く必要があります。
P2Pネットワークは、根本的に信頼不要という別のアプローチを取りました。もちろん自分のクライアントデバイスを信頼する必要はありますが、それだけです。ソフトウェアはクライアント上で動作し、信頼がデータに埋め込まれるため、ネットワーク内の他のサービスや主体を信頼する必要がありません。
atprotoは中間的なアプローチを取り、私たちはこれを「後回し信頼（lazy trust）」と呼ぶことがあります。P2Pネットワークと同様に、信頼はデータに埋め込まれています。しかし、ネットワークを閲覧する際にユーザーが見るのは多くの場合、正規データではなく計算済みのビューです。例えばタイムラインを見るとき、クライアントは流れてくるすべての投稿の署名を検証しないでしょう。これは、正規データが常に手元にあることで緩和されます。したがって、これらの計算済みビューを提供するサービスは、提供するすべてのビューに評判を賭けています。サービスが無効なビューを出し始めたら、それを検証できます。しかもデータはオープンなので、ユーザーはより適切な別サービスへ移行できます。
また、P2Pネットワークと異なり、ユーザーは自分のデータとID情報をホストする永続的なバックエンド（PDS）と関係を持ちます。特に（atprotoで厳密に必須というわけではありませんが）、私たちは署名鍵をバックエンド側へ移す決定をしました。これにより、クライアントが鍵を持つことによる複雑な鍵管理UXの問題を防げます。しかし、その分ユーザーのコントロールが失われるのも事実です。これも後回し信頼で緩和されます。信頼はIDシステムの一段上に移され、ユーザーはIDの復旧鍵を保持でき、それによって不適切なPDSから移行できます。
信頼のもとで運用するほうが、信頼不要で運用するより本質的に効率的です。一般的に、これは高信頼運用によるパフォーマンスとUXの利得を活かすというatprotoの哲学を示しています。しかしその際も常に、信頼できる出口と、不正な利用者や粗悪なサービス提供者に備えるための抑制と均衡の仕組みを維持する必要があります。
結論
これらすべてを踏まえると、プロトコルとネットワークの全体像が浮かび上がります。
ATプロトコルは、ウェブの哲学を土台に、P2Pプロトコルの技術とデータ指向分散システムの実践を組み合わせて構築されています。
私たちはIDを最優先とし、プロトコル設計の中心に据えています。正規のユーザーデータは流動的でコモディティ化されたホスティングネットワークに存在し、その上にリッチなアプリケーションを構築できます。
そして、このネットワークの設計においては構造を重視し、可能な限り高信頼環境の利点を活かしつつ、その関係が悪化した場合のために信頼できる出口を常に確保します。
興味があるなら、プロトコル仕様を読んだり、このプロトコル上に構築されたStatusphereのサンプルアプリで実際に触れてみてください。