Blueskyとフェディバース（fediverse）の比較

中核となるアーキテクチャの違い: メッセージ配送 vs 共有ヒープ

• フェディバース: メールに似た「メッセージ配送」方式を使用

  • 特定の受信者に直接メッセージを配送
  • 必要なサーバーにのみメッセージが送信されるため効率的
  • 個人でも安価なハードウェアでノードを運用可能

• Bluesky: 「共有ヒープ」方式を使用

  • すべてのメッセージが中央の「リレー」に保存される
  • ユーザーはリレーから関連情報をフィルタリングする
  • 大規模な中央集約型インフラが必要
  • リレー運用コストが急増（4か月で1TB→5TB）

グローバルビューと中央集権化の問題

• Bluesky: 一貫したネットワーク全体ビューの維持に注力

  • すべてのAppViewが全体のブロック情報などを必要とする
  • ブロックリストが公開されるためプライバシー問題が発生
  • 中央集権的な統制なしには実装が難しい

• フェディバース: 各サーバーが独立してポリシーを実施

  • ユーザーにより多くの自律性を提供
  • ブロック情報は公開されないよう設計されている

プロトコルの開放性の比較

• フェディバース/ActivityPub: W3Cが採択したオープン標準

  • 誰でも自由に実装可能
  • 多様なソフトウェア間の相互運用性を保証
  • FEPを通じたコミュニティ主導の発展

• Bluesky/AT Protocol: 企業主導のプロトコル

  • まだオープン標準としての地位は確立されていない
  • 拡張性と持続可能性に限界がある

ダイレクトメッセージ（DM）の中央集権化

• Bluesky: すべてのDMが中央サーバーを通過

  • ユーザーのPDSやリレーとは無関係にBluesky社を通じて送信される
  • Bluesky社はすべてのDMにアクセス可能
  • 「信頼できる離脱」という概念と矛盾する

• フェディバース: サーバー間の直接配送メカニズム

  • 自分のサーバー管理者のみがメッセージにアクセス可能

移動可能なアイデンティティ実装の問題

• Bluesky: DIDを使用しているが、依然として中央集権化に依存

  • did:webとdid:plcはDNSと中央レジストリに依存
  • 初期にはすべてのアカウントが同一のrotationKeysを使用
  • ユーザー鍵はBlueskyによって管理される

• フェディバース: ノマディック・アイデンティティの概念を発展中

  • Zotプロトコルなど、より包括的な移動性を提供
  • FEP-ef61などを通じた継続的な改善

商業的圧力と持続可能性

• Bluesky: ベンチャーキャピタル資金に依存

  • 「組織は未来の敵だ」という認識
  • 有料アカウントと広告導入による商業的圧力
  • 投資家の収益圧力が分散化を阻害する可能性

• フェディバース: 多様な運営主体と資金モデル

  • 商業的・非商業的・個人的ノードからなるエコシステムを構成
  • 単一障害点がない

結論

• BlueskyはユーザーフレンドリーなインターフェースとTwitterに似た体験により、Xの優れた代替になり得る
• しかし、中央集権的な設計、運用コスト、プライバシーの脆弱性、企業依存性などのため、フェディバースの代替ではない
• 両システムは根本的に異なる目標と設計思想を持っており、理想的には互いを補完する方向で発展し得る

[hongminhee]

このような反論もあります: https://hackers.pub/@yurume/0195cc17-b1ed-712e-9ecf-dcc49158220a