分散型ソーシャルネットワークBlueskyはどのように機能しているのか？
TechFlow厳選深潮セレクト
分散型ソーシャルネットワークBlueskyはどのように機能しているのか？
atproto を理解すれば、Bluesky を理解できる。
Web3業界の深掘り報道に専念し潮流を洞察翻訳：Kurt Pan
私はBlueSkyに強い関心を寄せているが、その理由の一つはその仕組みにある。この記事では、その設計思想と背後にある原則について私の理解を述べる。ただし、私はBlueSkyチームの一員ではないため、あくまで個人的な見解である。
それでは始めよう。
BlueSkyが存在する理由
現在、BlueSkyの公式サイトには次のように書かれている。
ソーシャルメディアはあまりにも重要であり、少数の企業に支配されてはならない。私たちは、誰もがインターネットの未来を形作れるような、オープンな基盤を構築している。
これは大きなビジョンだ。
確かに素晴らしいアイデアだが、具体的にはどういう意味だろうか？現時点でのBlueSkyは、TwitterやMastodonに似たマイクロブログアプリである。この位置づけはどう考えればよいのか？実際、BlueSkyはマイクロブログアプリとして機能しているが、それだけではない。BlueSkyは、「認証トランスポートプロトコル（ATプロトコル、略してATPまたはatproto）」の実現可能性を示すために作られた最初のアプリケーションなのである。つまり、BlueSkyは「建物」であり、atprotoこそが「ソーシャルインターネットのオープンな基盤」なのである。
重要な点として、BlueSkyは企業でもある。そのため、「私たちが作り上げるのは、企業が支配できないほど巨大なものだ」という主張に対して疑念を抱く人もいるだろう。それは健全な出発点だと思うが、私にとって答えはまさにatprotoにある。
この二つの要素の相互作用は重要であり、まずatprotoの説明から始め、その後でBlueSkyがどのようにそれを活用しているかを見ていくことにしよう。
これは暗号通貨ですか？
まず最初に取り除いておくべき誤解がある。「『○○プロトコル』という分散ネットワーク」と聞くと、「まさか、これって暗号通貨？」と警戒してしまうかもしれない。
安心してほしい。これは暗号通貨ではない。暗号通貨分野由来の技術を一部利用しているものの、ブロックチェーンでもなければDAOでもNFTでもない。単に暗号技術やメルクルツリーといったものを使っているだけだ。
atprotoの概要
atproto（認証トランスポートプロトコル）の説明は次の通り。
atprotoは、大規模な分散型ソーシャルアプリケーション向けのフェデレーテッドプロトコルである。
順に分解していこう。
フェデレーテッドプロトコル
atprotoはフェデレーテッド（連合型）である。つまり、システムの各部分は複数の主体によって運営され、相互に通信できる。
このフェデレーション方式の選択は、「組織による支配不可能性」という約束を果たす上で不可欠な要素だ。もちろん他にも重要な要素はあるが、この点は特に重要である。
大規模対応
スケールアップするには、設計段階から拡張性を意識しなければならない。atprotoは、負荷を処理できる参加者に多くの負担を割り当て、そうでない参加者への負担を軽減するような工夫をしている。これにより、atproto上に構築されたアプリは、多数のユーザーに対しても問題なくスケール可能になる。
少なくとも、それが目指している理想である。先週、BlueSkyのユーザー数は500万人に達し、初期のTwitterよりも安定した運用を続けている。他のソーシャルアプリと比べればまだ小さいが、無視できる規模でもない。実際のところ、どれほどうまく機能するかは今後にかかっている。
分散型ソーシャルアプリ
atprotoは人と人をつなぐことを目的としており、ソーシャルアプリに焦点を当てている。現時点ではすべてのデータが公開であり、DM（ダイレクトメッセージ）のような非公開通信機能はない。理由は、フェデレーテッドシステム内でプライベートな機能を安全に実装するのは非常に難しく、リスクのあるものをリリースするより、まずは正しく動作するようにすることを優先しているためだ。現状では、公開しても問題ない内容のみに使うべきだろう。
これらのアプリは「分散型」である。なぜなら、アプリの運営自体がネットワーク上で直接行われるからだ。「BlueSkyサーバー」というものが存在するわけではなく、atprotoを実行するさまざまなサーバーが互いにメッセージを配信している。ここにはBlueSkyのデータだけでなく、他者が作成したアプリのデータも含まれる。
以上が概要だが、具体的には何を意味するのだろうか？
atprotoでは、ユーザーが自身の身元を証明するために、暗号学的に署名された「レコード」を作成する。このレコードには「Lexicon（レキシコン）」と呼ばれるスキーマが定義される。
レコードは「リポジトリ」内に保存される。リポジトリはHTTPおよびWebSocket経由で外部に提供され、他のリポジトリと通信しながらデータを共有する。これらは通常「PDS（Personal Data Server：個人データサーバー）」と呼ばれる。ユーザーは自分でPDSを運用するか、他人がホストするPDSを利用する。
ネットワーク上に保存されたレコードを参照することで、さまざまなアプリを構築できる。このようなサービスは「アプリビュー」と呼ばれ、ネットワーク上の情報を特定の視点から提示する。この視点はレキシコンシステムを通じて形成される。つまり、アプリを構築するとは、まずレキシコンを定義し、処理したいデータ構造を規定し、自分のレキシコンを使用するレコードだけを表示し、それ以外は無視するということだ。
しかし、これがすべてだとすると、深刻なスケーリングの問題が生じる。例えば、私がBlueSkyに新しい投稿をするたびに、フォロワー全員のPDSに個別に送信しなければならないとしたら、非常に非効率的であり、人気ユーザーのPDSを運営するコストは莫大になってしまう。これを解決するために、「リレー」と呼ばれる追加サービスが導入されている。リレーはネットワーク全体の情報を集約し、他のリレーに高速かつ大量に中継する。実際には、アプリビューはPDSではなくリレーから情報を取得する。私の投稿は、まず自分のPDSからリレーに通知され、フォロワーはアプリビューを使ってリレーの出力をフィルタリングし、自分がフォローしているユーザーの投稿だけを表示する。この仕組みにより、リレー自体は規模が大きく、運用コストも高くなるが、小規模なリレーを独自に運用して、特定のユーザーサブセットからの投稿のみを伝播させることも可能だ。リレーはネットワーク全体のコンテンツを扱う必要はなく、大規模なリレーがそうしているだけである。
以下はASCII形式の図解である。
atprotoの本質を理解するには、これで十分だ。人々がデータを作成し、それがネットワーク上で共有され、アプリがそのデータと相互作用する。
なお、他のタイプのサービスも今後導入される予定であり、さらなる進化が期待される。しかし、それらに触れる前に、現状の設計思想を理解するために必要なイデオロギー的背景を説明しておく必要がある。
「発言」と「到達」とは何か？
atprotoはソーシャルアプリの実現を意図して設計されているため、人と人の「接続」だけでなく、「切断」も考慮しなければならない。モデレーション（コンテンツ審査）はあらゆるソーシャルアプリの中心的要素である。「審査なし」ですら、一種の審査戦略と言える。BlueSkyは、異なる人が異なる審査の好みを持つこと、また大規模な審査が困難であることを認識している。
そこで、atprotoは「発言と到達（speech and reach）」というモデルを採用している。ここまで説明してきたのは「発言」のレイヤーであり、純粋にネットワーク上でのコンテンツ複製に関わるもので、その内容の意味には関与しない。一方、審査ツールは「到達」のレイヤーに属する。つまり、すべての発言を受け入れつつ、自分が見たくないコンテンツの「到達範囲」を制限する手段を提供するのである。
ときどき、「BlueSkyは完全な言論の自由を保証している」「審査を行わない」という誤解が生まれるが、これは正確ではない。審査ツールはプロトコル自体に組み込まれており、BlueSky以外のアプリを含むネットワーク全体で利用可能になっている。さらに、自分自身で審査者を選べるため、他人の審査判断に左右されずに済む。少し先走ってしまったが、ここで「フィードジェネレータ」と「ラベラー」について説明しよう。
フィードジェネレータとは何か？
ほとんどのソーシャルアプリには「フィード（購読ストリーム）」という概念がある。atprotoでは、これを独立したサービスタイプとして「フィードジェネレータ」と呼んでいる。典型的なフィードの例は、「フォローしている人の投稿を新しい順に表示してください」である。最近ではアルゴリズムによるフィードが主流になり、一部の非技術ユーザーはそれを単に「アルゴリズム」と呼ぶまでになっている。
フィードジェネレータは、リレーから得られる膨大なデータを取り込み、任意の基準に従ってフィルタリング・並べ替えを行い、ユーザーに投稿のリストを表示する。そして、そのフィードを他のユーザーと共有することもできる。
実際の例として、私がお気に入りのフィードの一つに「Quiet Posters」がある。これは、あまり投稿しない人の発言を表示してくれる。これにより、メインフィードでは埋もれてしまう人の投稿も追いやすくなる。また、「the ‘Gram」といった、画像付きの投稿だけを表示するフィードもある。あるいは「My Bangers」のように、自分の人気の高い投稿を集めたフィードもある。
私にとって、これはBlueSkyが他のマイクロブログツールに対して持つ決定的な強みの一つだ。完全なユーザー選択権である。自分でアルゴリズムを作りたいなら作れるし、簡単に他人と共有できる。BlueSkyを利用しているなら、これらのフィードにアクセスしてフォローできる。
フィードジェネレータはatprotoに最近追加された機能であり、すでに利用可能だが、まだ完璧ではなく、将来的に変更される可能性もある。今のところ私の使用感ではうまく動いているが、技術的な詳細までは見ていない。
ラベラーとは何か？
ラベラーとは、コンテンツやアカウントに「ラベル（タグ）」を付与するサービスのことである。ユーザーは特定のラベラーを購読でき、投稿に付けられたラベルに基づいて体験を変えることができる。
ラベラーは、どのような方法でもラベル付けができる。たとえば、投稿に対して何らかのアルゴリズムを適用して自動的にラベルを付けることもできるし、人間が「いいね」「悪いね」を押して手動で行うこともできる。運営者が望むどんなやり方でも可能だ。
代表的なラベラーの例として「ブラックリスト」がある。これは、見たくない人物が投稿したコンテンツにラベルを付けるものだ。もう一つの例は「職場不適切コンテンツフィルター」で、投稿内の画像に対して何らかのアルゴリズムを実行し、不適切と判断された場合にラベルを付ける。
現在、ラベラーは存在しているが、一般ユーザーが自分でラベラーを運営することはまだできない。BlueSkyが自社で運営しているが、外部向けのバージョンはまだ提供されていない。しかし、それが可能になれば、コミュニティが独自のラベラーを立ち上げ、望む種類のラベルを自由に追加できるようになるだろう。
atprotoにおける審査の仕組み
これらすべてを組み合わせると、審査がどのように機能するかが見えてくる。フィードジェネレータはラベルに基づいてフィードの内容を変換でき、アプリビューもラベラーに問い合わせることでフィードを加工できる。これらは好みに応じて自由に組み合わせることができる。
つまり、アプリ間だけでなく、同じアプリ内でも審査体験をカスタマイズできるのだ。職場で見ても問題ないフィードを使いながら、別のフィードでは不適切なコンテンツも許容したい？ それは可能だ。誰かのブラックリストを作成して全世界に共有したい？ それも可能だ。
これらの審査ツールはアプリレベルではなくネットワークレベルで機能するため、他のシステムよりも一歩進んでいる。もし誰かがatproto上でInstagramのクローンを作ったとしても、あなたのブラックリストラベラーをそのまま使うことができる。なぜなら、そのラベラーはプロトコルレベルで動作しているからだ。一度誰かをブロックすれば、望む限りどこでもブロックされたままになる。もちろん、異なるアプリで異なる審査設定を選ぶこともできる。すべてはあなた次第だ。
このモデルは、Mastodonのような「インスタンス」にアカウントを持つ従来のフェデレーテッドシステムとは大きく異なる。そのため、「自分のインスタンスがフェデレーション解除されたらどうなるのか」といった疑問がよく出るが、atprotoではその問い自体があまり意味を持たない。特定の基準に基づいてユーザーのグループをブロックするという同じ目標は達成できるが、それはあくまで「自分の選択」であり、「サーバー管理者」が決めるわけではない。
では、自宅にサーバーを持たない一般ユーザーのアイデンティティはどのように機能するのか？
アイデンティティとアカウントの移植性
アイデンティティの仕組みには多くの細部があるが、ここでは特に重要な点に絞って説明する。また、議論を呼ぶポイントにも注目したい。
核となるのは「DID（Decentralized Identifier：分散識別子）」と呼ばれるユーザーの識別番号である。私のDIDは次の通り：did:plc:3danwc67lo7obz2fmdg6jxcr。ぜひフォローしてください！ もちろん、普段見るインターフェースはこれではない。DIDに加えて「ハンドル」と呼ばれるドメイン名も関係する。私のハンドルはsteveklabnik.comである。BlueSky上の私の投稿は@steveklabnik.comから来ているのがわかるだろう。ドメインを持っていない人でも利用可能で、BlueSkyに登録すれば、任意の名前を選べ、そのハンドルは@username.bsky.socialとなる。私は当初@steveklabnik.bsky.socialで投稿していたが、後に@steveklabnik.comに移行した。しかしDIDは変わらないため、フォロワーには影響がない。UI上ではハンドルの更新が表示されるだけだ。
ドメインをハンドルとして使うには、PDSが生成したDIDを取得し、そのドメインのDNSにTXTレコードを追加すればよい。DNSという言葉さえ知らない人でも、BlueSkyとNameCheapの提携により、技術知識ゼロでドメインを登録・設定できる。その後、ドメインを使ってアプリにログインすれば、すべて正常に機能する。
この仕組みにより、BlueSkyは真の「アカウント移植性」を実現している。そもそも「アカウント」という概念が実質的に存在しないためだ。特定のDIDを持つユーザーは、作成したコンテンツに暗号署名を行い、それがネットワーク上で複製される。「あなたのアカウント」をBANすることは事実上不可能である。なぜなら、誰もがアクセスできない鍵を使ってコンテンツを管理しているからだ。PDSに問題が起きて新しいPDSに移行したい場合でも、ネットワークからデータを復元し、PDSの移転をネットワーク全体に通知する手段がある。これは、現存するどの類似サービスとも一線を画す、真に意味のあるアカウント移植性である。
しかし。
細部がすべてを決める。これはBlueSkyとatprotoに対する、より意義深い批判の一つだと思う。
DIDを作成する「メソッド」には複数の種類がある。BlueSkyは2種類をサポートしている。1つはドメインに基づく「did:web」。これはいくつかの欠点があり、私はまだ完全には理解できていないため詳述は避けるが、いずれDIDについて深掘りした記事を書くつもりだ。
これらの弱点を受けて、BlueSkyは独自のDIDメソッド「did:plc」を実装した。plcは「placeholder（プレースホルダー）」の略で、将来的にもサポートを続ける予定だが、それでも弱点がある。その弱点とは、正しい情報を解決するために、BlueSkyが運営するサービスに問い合わせる必要がある点だ。例えば、これは私のDID照会である。つまり、BlueSkyは、他の分散型ネットワーク設計では不可能なほど深刻な方法であなたをBANできる。この点を非常に重大な問題と考える人もいる。
この欠陥は致命的だろうか？ 私はそうは思わない。第一に、本当にこの仕組みに関わりたくないなら、did:webを使えばよい。確かに他の理由で不十分ではあるが、それがdid:plc開発の理由でもある。とはいえ、回避は可能だ。
第二に、個人的にはBlueSkyチームがこの問題に対する不快感を十分に理解しており、設計上、より良いシステムが登場すればそれに移行できる余地があると感じている。また、将来、did:plcのガバナンスを何らかの合意形成モデルに移管することも可能だと表明している。選択肢は存在する。さらに、他の誰かが独自にdid:plcサービスを運営し、それを使用することも理論上可能だ。
私自身はこれを現実的な運営の例と見ているが、他人は悪意ある陰謀と見るかもしれない。判断は各自にお任せする。
BlueSkyはatprotoの上にどのように構築されているか
atprotoの理解が深まったところで、BlueSkyそのものを見てみよう。BlueSkyはatprotoネットワーク上に構築されたアプリである。彼らはアプリビューを運営し、そのアプリビューを利用するWebアプリを提供している。また、Webアプリ経由で登録したユーザー向けにPDSを運営し、それらのPDSと通信するリレーも運営している。
彼らは二つのレキシコンを公開している。一つはcom.atproto.*、もう一つはapp.bsky.*。前者はネットワーク上のあらゆるアプリが共通して必要な低レベル操作を定義し、後者はBlueSky独自の機能を定義している。
BlueSkyの優れた点の一つは、ユーザーがこれらの技術的な細部を知らなくても使えるように設計されていることだ。インスタンスの選択が必要ないため、「アカウントを作るにはまずインスタンスを選ぶ」という手順がない。また、移植性のおかげで、ホストが故障しても移行でき、フォロワーには一切影響がない。
他者はどのようにatproto上にアプリを構築できるか
atprotoアプリを作成するには、まずレキシコンを作成する。その後、そのレキシコンに関連するネットワークデータを処理するアプリビューを運営し、ユーザーが自分のPDSにデータを書き込めるようにする。
私も実際にやってみようと思っている。どうなるか、楽しみだ。
終わりに
以上、技術的な観点から見たatprotoとBlueSkyの仕組みの概要である。私はこの設計が非常に巧妙だと感じる。また、atprotoとBlueSkyを分けて考える意義も大きい。ネットワークが「キラーアプリ」を持つことで、利用する価値が明確になる。同時に、atprotoが本当に実用的なアプリを構築できるだけの品質を持っているかを検証する試金石にもなっている。
今後も、このテーマについてもっと語る機会があるだろう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
