分散型プロトコルとは
分散型ソーシャルプロトコルは、従来の中央集権型SNSとは根本的に異なるアーキテクチャを持っています。Twitter、Facebook、Instagramなどの従来型SNSでは、すべてのデータとインフラストラクチャが単一の企業によって管理されています。ユーザーはそのプラットフォーム内でしかコミュニケーションできず、データの所有権もプラットフォーム側にあります。
対照的に、分散型プロトコルでは、データの保存場所、アプリケーションの実装、コンテンツの配信が分離されています。これにより、ユーザーは自分のデータを完全に所有し、好きなクライアントアプリケーションを選択でき、異なるサーバー間でもシームレスにコミュニケーションできます。
この概念は、Eメールのアーキテクチャに似ています。Gmailユーザーは、OutlookユーザーやYahooメールユーザーとも問題なくメールのやり取りができます。これは、すべてのメールサービスがSMTP、IMAP、POPといった共通のプロトコルを実装しているためです。分散型ソーシャルプロトコルも同様に、異なる実装間での相互運用性を実現することを目指しています。
AT Protocol(Bluesky)の技術解説
AT Protocol(Authenticated Transfer Protocol)は、Blueskyを支える分散型プロトコルで、Jack Dorsey(Twitter創業者)の支援のもと開発されました。2024年2月の一般公開以来、急速に成長し、2026年には2000万ユーザーを超えています。
アーキテクチャの基本構成
AT Protocolは、以下の主要コンポーネントで構成されています:
1. PDS(Personal Data Server)
PDSは、個々のユーザーのデータを保存するサーバーです。ユーザーは自分のPDSを選択するか、自分でホストすることができます。これは、Eメールで自分のメールサーバーを選べることに似ています。
PDSには以下のデータが保存されます:
- 投稿(ポスト)とリプライ
- フォロー・フォロワー関係
- いいね、リポスト、ブックマーク
- プロフィール情報
- メディアファイル(画像、動画)
重要な点は、ユーザーがPDSプロバイダーを自由に変更できることです。データはポータブルで、新しいPDSに移行しても、フォロワーや過去の投稿は維持されます。
2. Relay(リレーサーバー)
Relayは、ネットワーク全体の投稿をインデックス化し、配信する役割を担います。複数のPDSから投稿を集約し、クライアントアプリケーションに効率的に配信します。
Relayは「ファイアホース」と呼ばれるリアルタイムストリームを提供し、ネットワーク全体のアクティビティを購読できます。これにより、トレンド検出、リアルタイムフィード、検索機能などが実現されます。
3. AppView(アプリケーションビュー)
AppViewは、Relayから受け取ったデータを処理し、クライアントアプリケーション向けにフィードやタイムラインを生成します。異なるAppViewは異なるアルゴリズムやフィルタリングロジックを実装できます。
例えば、あるAppViewはクロノロジカル(時系列)フィードを提供し、別のAppViewはAIベースのレコメンデーションを提供するといったことが可能です。ユーザーは自分の好みに応じてAppViewを選択できます。
DIDとハンドルシステム
AT Protocolは、DID(Decentralized Identifier)を使用してユーザーを識別します。DIDは、中央機関に依存しない分散型識別子で、ユーザーのアイデンティティをプラットフォームから独立させます。
ユーザーは人間が読めるハンドル(例:@alice.bsky.social)を持ちますが、これはDIDへのエイリアスに過ぎません。ハンドルは変更可能で、カスタムドメインを使用することもできます(例:@alice.com)。
Lexicon - データスキーマ定義
AT ProtocolのデータはLexiconと呼ばれるスキーマ定義言語で記述されます。Lexiconは、投稿、いいね、フォローなどのアクションの構造を定義し、異なる実装間での互換性を保証します。
例えば、投稿のLexiconは以下のように定義されます:
{
"lexicon": 1,
"id": "app.bsky.feed.post",
"type": "record",
"record": {
"type": "object",
"required": ["text", "createdAt"],
"properties": {
"text": { "type": "string", "maxLength": 300 },
"entities": { "type": "array" },
"reply": { "type": "ref" },
"embed": { "type": "union" },
"createdAt": { "type": "datetime" }
}
}
}
この標準化により、異なるクライアントやサーバー実装間でのデータ互換性が保証されます。
Farcaster Protocolの仕組み
Farcasterは、イーサリアムブロックチェーンと連携する分散型ソーシャルプロトコルです。2021年にDan RomeroとVarun Srinivasanによって創設され、クリプトネイティブなコミュニティを中心に成長しています。
ハイブリッドアーキテクチャ
Farcasterの特徴は、オンチェーン(ブロックチェーン上)とオフチェーン(通常のサーバー上)を組み合わせたハイブリッドアーキテクチャです:
オンチェーン要素
- アイデンティティ: ユーザーのアカウントはイーサリアム上のスマートコントラクトで管理
- ユーザー名: ENS(Ethereum Name Service)を使用したユーザー名の登録
- ストレージレジストリ: ユーザーがどのHubを使用しているかの記録
オフチェーン要素
- 投稿データ: 実際の投稿内容は分散型のHubネットワークに保存
- ソーシャルグラフ: フォロー関係、いいね、リアクションなど
この設計により、ブロックチェーンのセキュリティと検閲耐性を活かしつつ、高速でスケーラブルなソーシャル体験を実現しています。
Hubネットワーク
Farcasterのデータは、Hubと呼ばれる分散型ノードのネットワークに保存されます。Hubは以下の役割を果たします:
- ユーザーの投稿、いいね、フォロー関係などのデータを保存
- 他のHubとデータを同期(ゴシッププロトコル使用)
- クライアントアプリケーションにAPIを提供
誰でも自分のHubを運用でき、ネットワークに参加できます。これにより、単一障害点がなく、検閲に強いネットワークが実現されています。
署名付きメッセージ
Farcasterのすべてのアクション(投稿、いいね、フォローなど)は、ユーザーの秘密鍵で署名されたメッセージとして表現されます。これにより、データの真正性が暗号学的に保証されます。
例えば、投稿メッセージの構造:
{
"type": "MESSAGE_TYPE_CAST_ADD",
"fid": 123456,
"timestamp": 1709510400,
"castAddBody": {
"text": "Hello Farcaster!",
"mentions": [],
"embeds": []
},
"signature": "0x..."
}
この署名により、なりすましや改ざんが不可能になり、分散型環境でも信頼性が保たれます。
ActivityPub(Mastodon)
ActivityPubは、W3Cが標準化した分散型ソーシャルネットワーキングプロトコルです。Mastodon、Pixelfed、PeerTubeなど、多くの分散型SNSプラットフォームがこのプロトコルを採用しています。
Fediverseの概念
ActivityPubベースのネットワークは、総称して「Fediverse(Federated Universe)」と呼ばれます。Fediverseでは、異なるサーバー(インスタンス)が連合(Federation)を形成し、ユーザーはサーバーを越えてコミュニケーションできます。
例えば、mastodon.socialサーバーのユーザーは、mastodon.jpやpixelfed.socialのユーザーとも交流できます。これは、Gmailユーザーが他のメールプロバイダーのユーザーとメールできることと同じです。
ActivityPubの仕組み
ActivityPubは、「Actor」「Activity」「Object」という3つの主要概念で構成されています:
- Actor: ユーザーやボットなど、アクションを実行するエンティティ
- Activity: 投稿、いいね、フォローなどのアクション
- Object: アクティビティの対象となるコンテンツ(投稿、画像など)
例えば、「AliceがBobの投稿にいいねする」というアクションは、以下のようなJSON形式で表現されます:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Like",
"actor": "https://alice.example/users/alice",
"object": "https://bob.example/posts/123"
}
このActivityは、AliceのサーバーからBobのサーバーに送信され、Bobは通知を受け取ります。
サーバー間通信
ActivityPubサーバーは、HTTPSを使用して互いに通信します。各サーバーは、他のサーバーから受け取ったActivityを処理し、必要に応じて自サーバーのユーザーに配信します。
この連合モデルにより、中央サーバーなしでグローバルなソーシャルネットワークが実現されています。
プロトコル間の相互運用性
現在、AT Protocol、Farcaster、ActivityPubは、それぞれ独立したエコシステムを形成しています。しかし、プロトコル間の相互運用性を実現する取り組みが進行中です。
ブリッジサービス
異なるプロトコル間をつなぐブリッジサービスが登場しています。例えば:
- Bluesky ⇔ Mastodon ブリッジ: Blueskyの投稿をMastodonで閲覧可能にするサービス
- Farcaster ⇔ Lens ブリッジ: 異なるWeb3ソーシャルプロトコル間の投稿連携
これらのブリッジにより、ユーザーは複数のプロトコル上の友人と、単一のクライアントアプリからコミュニケーションできるようになります。
統一クライアント
複数のプロトコルに対応したクライアントアプリケーションも開発されています。これにより、ユーザーはBluesky、Mastodon、Farcasterのアカウントを一つのアプリで管理できます。
将来の標準化
2026年以降、プロトコル間の相互運用性を実現するための標準化作業が進むと予測されています。W3Cや他の標準化団体が、異なる分散型プロトコル間の共通仕様を策定する可能性があります。
プロトコル比較
AT Protocol、Farcaster、ActivityPubを比較すると、それぞれに特徴があります:
AT Protocol
強み:
- データポータビリティが優れている
- アルゴリズム選択の自由度が高い
- スケーラビリティに優れた設計
弱み:
- 比較的新しく、エコシステムが発展途上
- 完全な分散化にはまだ時間がかかる
Farcaster Protocol
強み:
- ブロックチェーンによる強固なアイデンティティ
- Framesなど革新的機能
- クリプトネイティブなエコシステム
弱み:
- イーサリアムへの依存
- クリプト初心者には参入障壁が高い
ActivityPub
強み:
- W3C標準で成熟している
- 多様な実装とエコシステム
- 完全な分散化を実現
弱み:
- ユーザー体験が実装により大きく異なる
- モデレーションが困難
プロトコルの未来
分散型ソーシャルプロトコルは、まだ発展途上の技術です。2026年以降、以下のような進化が予想されます:
- パフォーマンス向上: より高速で効率的なデータ同期とフィード生成
- プライバシー強化: エンドツーエンド暗号化、ゼロ知識証明の統合
- モバイル最適化: モバイルデバイスでの分散型ノード運用
- AI統合: AIによるコンテンツモデレーション、レコメンデーション
- マルチメディア対応: ライブストリーミング、VR/ARコンテンツのサポート
分散型ソーシャルプロトコルは、インターネットの未来を形作る重要な技術です。ユーザーがデータを所有し、プラットフォームに依存しないソーシャル体験を実現することで、より健全で自由なデジタル社会の構築に貢献します。