为什么 Bluesky 不是点对点网络？

P2P、联邦式与中心化架构

• 几位评论者指出，Bluesky 的模式看起来不像纯粹的 P2P，更像 Web 或 GitHub：用户“个人数据服务器”加上更大的聚合基础设施。
• 批评者认为 Bluesky 的 relay／“大图服务器”会产生不可避免的控制中心；支持者则表示 relay 是可插拔的“总线”，PDS 可以连接多个 relay，或者直接连接，因此权力并不是固定的。
• 也有人认为，带认证的帖子和最终删除的真正 P2P 是可行的，但在实践中很难强制执行。

发现、搜索与规模

• 一方认为，并不严格需要大型索引／搜索服务；社交图谱、标签以及“好友的好友”视图就能提供人类规模的发现能力。
• 另一方坚持认为，全球搜索（按标签／主题，覆盖数百万用户）对许多现实用例至关重要，而这不可避免地需要大量存储和中心化索引。
• Fediverse 式的全量复制被批评在全球规模下既昂贵又不环保，技术上也难以承受。

ActivityPub / Mastodon / Nostr 对比

• ActivityPub 被认为可用，但在实践中存在缺陷：账号迁移不佳、按应用类型需要多个身份、缺少广泛使用的 client-to-server 模式，以及在主流实现中很难轻松“自带域名”。
• Mastodon 生态：节点很多，但少数大型节点占主导，因为成本、便利性和社交引力的作用。小型／自托管实例会感觉孤立，因为它们只能看到自己明确抓取过的数据。
• Nostr 因其简洁的核心规范而受到称赞，但也因基于私钥的身份机制而受到批评，许多人认为这对主流用户不可用，并且在文化上与“crypto”社区紧密相关。

身份：域名 vs 公钥

• Bluesky 基于 DNS 的身份（句柄作为主机名，通常可用自有域名）广受欢迎；讨论中也提到可以把个人域名通过简单的 HTTP 或 CNAME 重定向到个人资料。
• 一些人担心域名稀缺、会过期，并且把控制权集中在注册局和注册商手里；他们主张公钥身份作为持久、与存储位置无关的锚点。
• 另一些人反驳说，密钥不可读、难以输入，而且对普通用户没有意义；没有哪一种方案能同时完全满足易记、去中心化和安全。

审核、权力与目标

• 存在相互竞争的叙事：Bluesky 是对高知名度封禁的回应，还是旨在让提供商“可替换”并减少平台捕获，而不是消除审核。
• 这里存在一种张力：既希望系统能抵抗审查，又承认任何广告资助或中心化基础设施都倾向于积累审核权力。

产品定位与用户体验

• 有人把 Bluesky 看成“更慢的 Twitter”，区别不清、搜索能力也弱；也有人恰恰喜欢这种更慢、算法更少、毒性更低的感觉。
• 一个关键批评是，开发者过于关注协议细枝末节，而忽视市场定位和长期商业模式。
• 优质内容的发现仍是痛点：如果没有强社交图谱或算法，新用户很难找到值得关注的信息流。

真正 P2P 的技术障碍

• 除了 NAT／防火墙之外，评论者还强调手机的电池和带宽限制：始终在线的对等连接需要频繁保活，这代价很高。
• 现有的 NAT 穿透框架（ICE／WebRTC、覆盖网络）能提供帮助，但会增加复杂性；并不存在普遍可用的“TCP/IP 的 P2P 等价物”。
• 有人认为，Bluesky 架构中的许多复杂性，都是为了绕开这些现实部署约束。