Bluesky 宣布为自托管用户提供数据联邦

架构、联邦与中心化风险

• AT Protocol 引入了个人数据服务器（PDS）、中继和“AppViews”。用户可以自托管 PDS；中继汇总数据；AppViews 提供信息流。
• 支持者表示这会“让开放保持开放”：协议是开源的，可以有多个中继，账户也可以在不同 PDS 之间迁移。
• 怀疑者认为，只要 Bluesky 的主服务掌握约 99% 的用户，它就能像一个中心化把关者那样运作（例如关闭联邦、单方面修改协议），类似 Google Chat 退出 XMPP。
• 有人担心对中心化 DID 目录实现的依赖，以及这种主导地位是否会实际上把网络“重新中心化”。

商业模式与广告

• 对可持续性的质疑：当前收入包括一个域名合作；发帖者怀疑这不足以支撑一个大型网络。
• Bluesky 的表态强烈淡化或拒绝会把产品“弄烂”的广告模式，但也有人指出博客措辞仍为非主导性的广告留有余地。
• 还有几条评论提到，VC 资金会带来压力，最终可能把公司推向专有变更或广告驱动的决策。

审核与黑名单

• Bluesky 将托管与审核分离：审核服务、拉黑/静音名单和信息流被设计成“可组合”的，由用户或社区选择，而不是只在实例层面生效。
• 有人喜欢这种灵活性，并把它类比为 subreddit 风格或插件式审核；另一些人担心这会把艰难的工作外包给志愿者和大公司，而且仍可能通过热门黑名单产生不透明的“全局”权力。
• 争论在于，外置化审核究竟是真能防止滥用的中心化控制，还是只是把它重新包装了一下。

与 Mastodon、ActivityPub、Nostr、Web3 的比较

• 许多人拿 AT 和 ActivityPub 作对比：有人觉得 AP 规定不够明确，而且偏向大型实例；也有人说 AP 的多协议灵活性和现有生态是优势。
• 关于 Bluesky 是否只是“换了更花哨技术栈和中心化索引器的 Mastodon”，类似争论反复出现。
• Bluesky 与 Mastodon 之间的桥接极具争议，尤其是在默认退出的情况下；对于“公开就是公开”是否足以支持跨网络复制，意见分歧很大。
• 讨论中还提到 Nostr 和基于 Web3 的系统；一些人认为它们更适合自我主权，另一些人则因其与加密货币的关联或成本/复杂度而不以为然。

技术自托管细节

• PDS 的参考实现采用 MIT/Apache-2.0 许可，已容器化，目前为 Debian/Ubuntu 编写脚本；高级用户可以在其他环境运行。
• 由中继施加的每个 PDS 的初始速率限制被描述为反垃圾邮件措施；批评者认为这会限制独立的大型实例。
• 仅支持 IPv4 以及早期运营协调依赖 Discord 也引发不满；IPv6 支持“计划中”。

垃圾信息、滥用与不良行为者

• 发帖者担心开放联邦会让未审核或极端主义实例出现；另一些人回应说，这本就是任何开放协议的内在特性，必须通过审核服务以及更高层的类似断联机制来处理。
• 私信被刻意推迟；在一个以公开为设计前提的协议上加入私密消息被认为很复杂，尤其是在垃圾信息和隐私方面。

用户体验、功能与网络效应

• 有人认为，先发布联邦而不是私信/视频，才符合一个以协议为中心的项目；也有人认为主流用户更看重功能而不是协议设计。
• 与 Twitter/X 和 Mastodon 的比较突出显示：
  • Bluesky 因自定义信息流和早期社区质量而受到称赞。
  • 批评则是：如果没有视频、私信和大规模采用，它就像一个小众的“HN 圈子”玩具。
• 一个强烈观点认为，Bluesky 的长期成功将取决于它能否摆脱作为绝对主导节点的地位，以及第三方应用/服务器能否蓬勃发展。