Bitsocial と Bluesky
Bluesky は、Bluesky Social PBC が設計した AT Protocol の上に構築されたマイクロブログアプリです。このプロトコルはソーシャルネットワークを別々のサービスに分割します。パーソナルデータサーバーがアカウントをホストし、リレーがそれらを 1 つのストリームに集約し、AppView がそのストリームをインデックス化して、人々が目にするタイムラインやスレッドにします。そのドキュメントは、アカウントのデータを「ピアツーピアモデルとは対照的に」ホストサーバー上に保存されるものと説明しています (概要)。
AT Protocol の仕組み
- サーバー上のリポジトリ。 投稿、いいね、フォローはどれも、投稿者の署名付きリポジトリ内のレコードであり、パーソナルデータサーバー (PDS) にホストされます。デフォルトのサーバーは Bluesky が運用していますが、誰でも自分のサーバーをホストできます。
- リレー。 リレーはすべての PDS を購読し、変更を 1 つのストリーム、つまりファイアホースとして再配信します。2025 年のプロトコル更新以降、リレーはすべてのリポジトリをアーカイブしなくなり、運用コストが大幅に下がりました (Sync v1.1)。
- AppView。 AppView はファイアホース全体をインデックス化し、タイムライン、完全な返信スレッド、各種のカウント、検索を提供します。ネットワークの中で最も多くのリソースを必要とする部分です。
- アイデンティティ。 アカウントは DID です。通常は 1 つのグローバルなディレクトリに登録される
did:plc、またはドメインに結びついたdid:webです。DID ドキュメントには、アカウントのハンドル、署名鍵、現在のサーバーが記載されます。署名鍵は PDS が保持しますが、did:plcでは利用者がローテーション鍵を持つこともでき、元のホストの協力なしに移転できます (アイデンティティガイド)。 - ハンドル。 ハンドルは
alice.bsky.socialや利用者が所有するドメインのような DNS 名で、DID と照合して検証されます。 - モデレーション。 ホスティングとリーチは別々の層です。誰でもラベラーを運用でき、利用者は複数のラベラーを重ねて使えます (モデレーションガイド) が、Bluesky アプリは常に Bluesky 自身のモデレーションを適用します。投稿者は、自分の投稿に誰が返信できるかを制限したり、返信を非表示にしたりできます。
どこが違うのか
サーバーかピアか
Bluesky のデータはサーバー上にあります。PDS が各アカウントをホストし、リレーがファイアホースを運び、AppView がクライアントの表示する内容を提供します。ブラウザはそれらのサービスの HTTP クライアントであり、ピアになることはありません。Bitsocial では、コミュニティのノードと、そのコミュニティを読むピアがコンテンツを配信し、Web アプリは自前のピアツーピアノードを動かせます。ブラウザ ピアツーピア を参照してください。
グローバルな視点か、コミュニティか
AT Protocol は 1 つのグローバルな視点を前提に設計されています。AppView はすべての返信を把握するので、スレッドも検索も完全です。Bitsocial にはグローバルなインデックスがなく、各コミュニティが自らの状態を公開し、アプリがその上にディスカバリーを構築します。コンテンツディスカバリー を参照してください。
Bluesky には現在、公開投稿のためのコミュニティオブジェクトがありません。2026 年 6 月、Bluesky は一部のプライバシーレベルで投稿を承認制にできる ネイティブコミュニティを発表しました が、2026 年 10 月の時点ではまだ提供されていませんでした。Bitsocial ではコミュニティが中核のオブジェクトであり、コミュニティのノードが投稿を受理または拒否します。
スパム対策
Bluesky は、自社サーバーでのレート制限、リレーでの新規ホストの制限、自動検出、人によるレビュー、ラベルによってスパムに対処しており、投稿者は返信を制限できます。投稿が受理される前に何を通過しなければならないかを決める、コミュニティ単位の関門はありません。Bitsocial では、各コミュニティが独自のチャレンジを選びます。カスタムのスパム対策チャレンジ を参照してください。
誰が鍵を持つか
Bluesky 自身のサーバー上のアカウントはパスワードでログインし、署名鍵はそのサーバーが代わりに保管しています (Kleppmann et al.)。Bluesky のプロトコルエンジニアによると、ほとんどのアカウントは独立して管理されたローテーション鍵を持っていません。Bitsocial のアイデンティティは、利用者のアプリが生成して保持する鍵ペアです。
インフラの運用
個人のサーバーは安価です。リファレンス PDS は、利用者 20 人までなら 1 GB の RAM を推奨しています。ネットワーク全体を扱う独立した AppView は大がかりなプロジェクトで、2025 年に構築されたある AppView は 月に約 200 ドルかかり、その大半は 16 TB のストレージ代でした。Bitsocial には複製すべきグローバルなインデックスがなく、コミュニティノードは一般向けのハードウェアで動きます。
比較
| 論点 | Bluesky (AT Protocol) | Bitsocial |
|---|---|---|
| 分類 | グローバルなインデックスを持つフェデレーション型のサーバー群 | ピアツーピアのコミュニティネットワーク |
| アイデンティティ | DID。署名鍵は通常サーバーが保持 | 利用者とコミュニティの Ed25519 鍵ペア |
| 投稿の保存場所 | パーソナルデータサーバー上の投稿者のリポジトリ | コミュニティ所有者のノードと、そのコミュニティを読んでシードするピア |
| 誰が公開を維持するか | PDS のホスト、リレー、AppView。デフォルトでは Bluesky が運用 | コミュニティ所有者のノードと補助のシーダー |
| コミュニティ | 公開投稿向けにはまだない (2026 年に発表) | 自身のノードが投稿を受理または拒否する第一級のオブジェクト |
| スパム対策 | サーバーのレート制限、自動検出、ラベル、返信の制御 | 投稿が受理される前に課される、各コミュニティのチャレンジ |
| モデレーション | 重ねて使えるラベラー。Bluesky アプリは常に Bluesky のモデレーションを適用 | コミュニティ所有者が自分のコミュニティをモデレートし、何を表示するかはアプリが選ぶ |
| 名前 | DID と照合して検証される DNS ハンドル | 鍵に解決される .bso と .eth の名前 |
| ブラウザ | PDS と AppView の HTTP クライアント | 通常のブラウザタブ内で動くピアツーピアノード |
| 主なトレードオフ | スレッドと検索がグローバルに完全だが、集約には重いサーバーが必要 | 重いグローバルインデックスは不要だが、ネットワーク全体を完全に見渡す視点はない |