Bluesky 与 AT Protocol：可用的去中心化社交媒体

AT Protocol vs. Matrix and ActivityPub

• 有人将 AT 与 Matrix 和 ActivityPub 相比较，并认为它们解决的是不同问题：AT 针对的是聚合海量交互图谱进行了优化（例如跨数十亿条帖子上的点赞），而他们认为现有协议无法“直接拿来就用”来实现这一点。
• 也有人反驳说，原本可以在 ActivityPub 和 Matrix 上继续扩展（例如加入 DIDs、可迁移性），而不是发明一个“只是为了不成为 ActivityPub 而不同”的新协议。

Identity, DIDs, and Account Portability

• AT 强大且透明的账号迁移能力被广泛视为一项关键创新：在迁移服务器时保留用户名、社交图谱和数据，关注者不需要重新关注。
• 批评者指出，这种真实迁移在大规模场景下尚未得到验证，因为事实上目前仍只有一个公共服务器。
• ActivityPub/Mastodon 提供部分迁移能力，也有一些改进可携带性的提案，但当前方案较为粗糙，可能会丢失历史记录或身份连续性。
• 有人认为基于 DNS 的身份和个人域名很强大；也有人说域名对大多数用户来说过于复杂/昂贵，尤其是年轻用户或非技术用户。

Decentralization, PLC, and Centralization Risks

• AT 建立在 DIDs 之上，但占主导地位的 did:plc 方法目前由 Bluesky 运行的单一 PLC directory 支持；这被一些人称为“弱点”，甚至是“致命缺陷”。
• 支持者将 PLC 描述为务实的临时折中方案，并计划引入多个运营方或替代 DID 方法，如 did:web。
• 也有人担心 AT 的架构（PDS + 大型 relays/indexers）本质上会偏向少数资本雄厚的中介，最终可能走向寡头垄断。

Moderation, Safety, and Federation Models

• Fediverse：审核以实例为中心；管理员可以屏蔽整个实例并塑造社区规范。有人将这种碎片化视为一种特性（选择一个与你价值观一致的社区）；也有人认为这是一种“不得不接受”的负担和政治表态。
• AT/Bluesky：审核与托管被设计为可分离；自定义 blocklists 和共享审核列表被强调为优势。
• 怀疑者认为托管和审核本质上是绑定的，而大型、中心化的索引器仍会集中权力。

User Experience, Onboarding, and APIs

• 许多人认为 UX 的简洁性将决定胜负：大多数用户并不在乎去中心化，甚至可能把它体验为更糟。
• 一些人认为 Mastodon 的实例选择和联邦式模型令人困惑且有劝退效果；另一些人则坚持这并不比选择一个电子邮件服务商更难，并认为“复杂性”被夸大了。
• Bluesky 的 API 被赞为简单且令人愉悦；ActivityPub 的 API 常被描述为更难为其构建客户端。
• 自定义 feeds/algorithms 被视为 AT/Bluesky 的一个有吸引力的特性：它感觉像一等公民功能，同时又对第三方开放。

Standards Process and arXiv Paper

• 有人认为在 arXiv 上发表是一种公关动作，并主张协议规格应该写入 RFC 或正式标准机构。
• 也有人说 arXiv 更容易让学术界参与进来，而 IETF/W3C 只适合在存在多个独立实现且协议趋于稳定之后介入。