content:
"# atproto入門1 PDSって？どんな特徴があるの？？<br> ーWhiteWind TechTalkー
<img src="https://blewit.us-west.host.bsky.network/xrpc/com.atproto.sync.getBlob?did=did:plc:fzkpgpjj7nki7r5rhtmgzrez&cid=bafkreigx7ri2b6g23b4hcnvw366whtp453d6wtuwtb3kbfi3noqgx4ccpi"/>
<font size=2>最終更新 2024-04-05</font>
こんにちは、このブログシステムを作っているWhiteWind開発者のK-NKSMです！最近度々マイクロブログサイトのBlueskyが話題になりますよね。Blueskyが裏で使っているプロトコルが [<mark>__Authenticated Transfer Protocol (AT Protocol, atproto)__</mark>](https://atproto.com/guides/overview) であるということは有名です。しかし、
- 規格のページを見ても抽象的なことしか書かれておらず、イメージがつかない
- atprotoの新規性がわからない
- atprotoで何かを作ってみたいけれども簡潔なサンプルコードやGetting startedが見当たらなくて進めない
という方も多いのではないでしょうか。このシリーズでは非エンジニアにもわかるようなatprotoの大まかな仕組みからスタートし、atprotoの開発環境構築やAppViewの設計、WhiteWindを例として解説し、上に挙げたような疑問解消に役立つことを目標としています。
初回はatprotoの登場人物や特徴に関して解説していこうと思います。
atprotoを最低限理解するのに必要なコンポーネントに絞った、Blueskyの動作の概要図を下に示します。
それぞれの役回りを見ていきます。
## Bluesky client
これはスマートフォンやパソコンのブラウザなどからユーザーが操作できるアプリのことです。
ユーザーからの操作を受けてpostやlikeなどのデータをサーバーに送信します。
## PDS
### PDSはAPI付きクラウドストレージ
<mark>__PDS__</mark>はPersonal Data Serverの略で、クライアントからの司令を受けてpostやlikeのデータを保存します。
PDSは各ユーザーのデータを保存する専用領域を持っています。
この領域は __リポジトリ__ (repository, repo)と呼ばれています。
PDSはatprotoデータをクライアントから受信してリポジトリに保存しますが、PDS自身はどんなデータを保存させられているのか基本的に[^1]理解していません。
一定フォーマットに従えば __Blueskyとは関係ない、ユーザーが勝手に考えて作ったデータを置くことができます__[^2]。
そのような使い方が許容されているのは、 __PDSはBlueskyではないからです__ 。
私はよくPDSは「__API機能付きクラウドストレージ__」[^4]という例えを使っています。
Google DriveにはそのデータがGoogle製品で作られていようといまいと、画像であろうとPDFであろうと好きに置くことができます。
Google DriveやOneDriveなどいろいろなクラウドストレージがあるのと同様、Blueskyとは全く関係ない人たちもPDSを運用することが想定されているがゆえに[^3]、好き勝手なデータを置くことができる、という理屈です。
ただ、2024年4月現在はatproto開発元であるBlueskyがほとんどのPDSを運用しています。
### すべてのデータが公開される
PDSに置かれているデータは __すべて全世界に公開されています__ 。
特定データの読み取りに関して認証を要求したりするようなPDSは規格上禁止されていませんが、現段階でそのようなPDS実装は存在しません。
### クライアントからの要求をAppViewに中継する
PDSはクライアントからの要求をAppViewに中継する役割もあります。[^5]
### PDSは乗り換えることができる
atprotoはユーザーにPDSを乗り換える仕組みを提供しており、__PDSを乗り換えても、同じアカウントを継続して使い続ける事ができます。__
つまり、__アカウントはPDS上のリポジトリとは別管理になっているということです。__
これは、X/Twitter上でポストを全件ダウンロードしてアカウントを削除し、別のアカウントを作ってポストやフォローをやり直す、というのと本質的に異なっています。
atprotoのアカウントの仕組みに関しては次回解説する予定です。
### これよりやや詳しいPDSの概要
- [What does a PDS implementation entail? · bluesky-social/atproto · Discussion #2350](https://github.com/bluesky-social/atproto/discussions/2350)
## Relay (firehose, BGS)
Relayは世界中のありとあらゆるPDSに常時接続しています。
PDSは自分が保持しているリポジトリに変更があれば、どんな変更があったかをRelayに通知します。
<mark>__Relayはそのデータを受けて、自身に接続しているものにそのままデータを流します。__ </mark>
Relayもまたデータの中身がどうなっているかを理解していません。
既存のインターネットの仕組みで言えばGoogleやBingのような、あらゆるWebサイトをクローリングしてデータを吸い上げている存在に類似しています。
### Relayは全世界に何個も存在し得る
GoogleやBingなどいろいろな検索サービスが有るように、Relayも何個も存在することが想定されています。
ただ、あらゆるPDSに接続して、多数の下流システムにデータを配信するという役割から、非常に強力なインフラが必要となることが想定されます。
企業など一定規模の資金力を持っていないと運用できないはずです。
### Relayは誰でも接続できる
Relayは公共のインフラなのでどんな人でも自由につなぐことができ、全世界のPDSを一つ一つクロールせずとも、あらゆるatprotoデータを吸い上げることができます。
## AppView
AppViewはRelayに接続しており、世界中から流れてくるあらゆるatprotoデータを見ています。
<mark>__AppViewは流れてくるデータの中身を理解し、タイムラインや通知を作ったりといったデータ処理を行います。__ </mark>
例えばBluesky AppViewは流れてくるデータの中からBlueskyに関係あるデータを抜き出し、特定ユーザーのポストを列挙したり、フォローしているユーザーのタイムラインを作ったりといった、<mark>__ユーザー間のインタラクションや他ユーザーの行動など、世界中のatprotoデータを知っていないとなし得ないような機能__ </mark>を提供します。
このコンポーネントがいわゆる「atprotoサービス」になります。
### AppViewも全世界に何個も存在しうる
Relay同様AppViewも全世界に何個も存在し得ます。
仮にAppViewが特定のユーザーをシャドウバンしたり、不要な情報を無理やり流そうとした場合は、別のAppViewに乗り換えることができます。
## この構成だと何が起こるのか
各コンポーネントの基本的な役割に関して解説しました。
結局このようなコンポーネント構成にするとどういうことが起こるのでしょうか？
### データがユーザーのサーバーにたまる
前述の通り、ユーザーのデータはPDSに保存されます。
PDSはクラウドストレージに近い存在であり、ユーザーの思うがままにデータを操作できる、いわば「ユーザーのサーバー」です。
つまり、<mark>__atprotoサービスのデータはユーザーのサーバーに置かれます。__</mark>
サービス運営者によって勝手に消されたり、改変されたりすることはありませんし、世界から見えなくなることもありません。
### AppViewはユーザーのデータを管理しない
前の項目と全く同じことを言っているのですが、言い方を変えるだけで趣が全く変わってきます。
<mark>__ユーザーがデータを持ち、管理するトレードオフとして、サービス運営者はデータを管理してくれません。__</mark>
中央集権的なサービス構成では、ユーザーが作ったデータがサービスのサーバーにたまるので、サービス運営者は、
- データのストレージ代
- データ配信に伴うネットワーク帯域代
- バックアップ
- 可用性の確保
といった金銭的・時間的コストを支払っていました。
atprotoではデータのコントロールをユーザーが持つ代わりに、そのようなコストをPDSが支払う構造になっています。
サービス運営者から見るとこれは非常に大きな利点となります。
### 競合サービスを簡単に作れる
全AppViewでアクセスできるデータが同じなので、データを独占することによって競合に対して優位に立つことはできなくなっています。
そのため、例えばBlueskyに対抗するSNSを（お金と時間さえあれば）誰でも作ることができます。
## ビジネスモデル
エコシステムとして長く発展していくためには、みんなお金を得られるビジネスモデルが必要です。
各コンポーネントはどうやってお金を得ていくのでしょうか？
以下は（ビジネス素人による） 個人的な考察になります。
### PDS
PDSは中身を見ること無くデータを置き、Relayやその他問い合わせに応答する「API付きクラウドストレージ」と考えるとおいてあるデータ量に応じて一定までは無料、一定を超えたらプロフェッショナルプラン加入、みたいなのはどうでしょうか。
また、帯域や可用性に応じて、「インフルエンサー向けプラン」のような、大量配信したい人、多くに見てもらうことで得をする人は相応のインフラ代を払うシステムも面白いと思います。
特定のレコードを理解して、クライアントへのレスポンスに広告を挟み込むPDSも考えられなくはないですが、今後レコードの種類がBlueskyとWhiteWind以外にも多種多様になりうることを考えるとあまりスケールしないかもしれません。
### Relay
これはどうやってお金を得るのか不明です。
下流システムと契約して一定流量以降は有料、等でしょうか。
### AppView
AppViewはクライアントをセットで開発することが多いと思うので、クライアント上に広告を入れたり、配信データに広告を混ぜたりなどが可能です。
レコードのデータ構造そのものは公にならざるを得ないので、誰でも簡単に広告カット機能をつけたクライアントを開発できるのは事実です。
ただ、そもそも従来サービス側が負担していた運用・インフラ代をPDSが支払っているので必要な広告量はそもそも少なくて済むはずです。
## まとめ
- atprotoではPDS・Relay・AppViewの3主要コンポーネントが存在する
- PDSはユーザーのサーバーで、自由にデータを置ける
- RelayがすべてのPDSからデータを常に吸い上げている
- AppViewはRelayからデータを受け取って処理・解釈し、インデクシング、データの変換、ユーザーのインタラクションなどを行う
次回はatprotoのアカウントシステムに関して解説する予定です。
[^1]: データ形式を公開する仕組みができれば、自動バリデーションなどは実装されるはずです
[^2]: モデレーションの需要が高まれば中身を何らかの方法で読み取ってユーザーをBANしたりするPDSも出てくるかもしれません。
[^3]: 既にセルフホストPDSの連合が解禁されており、非Bluesky運営のPDSは現実に存在しています
[^4]: どんなAPIかは後述
[^5]: 筆者は目的をあまり良く理解していません。AppViewがPDSを認証してその場合のみAPIを提供する、などの用途でしょうか。"
