Bluesky와 페디버스(fediverse)의 비교

핵심 아키텍처 차이: 메시지 전달 vs 공유 힙

• 페디버스: 이메일과 유사한 “메시지 전달” 방식 사용

  • 특정 수신자에게 직접 메시지 전달
  • 필요한 서버에만 메시지가 전송되어 효율적
  • 개인이 저렴한 하드웨어로도 노드 운영 가능

• Bluesky: “공유 힙” 방식 사용

  • 모든 메시지가 중앙 “릴레이”에 저장됨
  • 사용자는 릴레이에서 관련 정보를 필터링
  • 대규모 중앙화된 인프라 필요
  • 릴레이 운영 비용이 급격히 증가 (4개월만에 1TB→5TB)

전역 뷰와 중앙화 문제

• Bluesky: 일관된 네트워크 전체 뷰 유지에 집중

  • 모든 앱뷰가 전체 차단 정보 등 필요
  • 차단 목록이 공개되어 프라이버시 문제 발생
  • 중앙 집권적 통제 없이는 구현 어려움

• 페디버스: 각 서버가 독립적으로 정책 시행

  • 사용자에게 더 많은 자율성 제공
  • 차단 정보는 공개되지 않도록 설계됨

프로토콜 개방성 비교

• 페디버스/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의 훌륭한 대안이 될 수 있음
• 그러나 중앙화된 설계, 운영 비용, 개인정보 취약성, 기업 의존성 등으로 인해 페디버스의 대안은 아님
• 두 시스템은 근본적으로 다른 목표와 디자인 철학을 가지고 있으며, 이상적으로는 서로 보완하는 방향으로 발전할 수 있음