加载失败
讨论源于关于 Blacksky 的迁移与用途——Blacksky 被描述为为美国黑人社区提供独立审查与社群服务的实例，同时保持与更大生态互通。争论延伸到 Bluesky 所用的 Atproto 协议与传统 ActivityPub 的优劣，核心分歧在于“真正的去中心化”定义、资源可行性（能否低成本摄取或索引全量流）以及平台层面审查与治理的集中化风险。评论里既有技术层面的规范与实现差异分析（如 ActivityPub 的事实标准问题、Atproto 的 PDS/访问模型），也有实证案例反驳（如在廉价 VPS 或 rpi4 上运行索引器的实例）和对社群导向迁移的社会学解释。
有用户发布了迁移报告，说明从现有网络迁移到 Blacksky 的具体过程和原因，强调 Blacksky 的目的在于为美国黑人社区提供一个可自主制定审查规则的服务同时保持互操作性。评论里反复指出，人们选择社交网络主要是基于社交需求（社群、调性、治理），技术只是支撑或限制这些社会功能的工具。Blacksky 被视作一个以社群为中心、在治理上独立但仍能与更大生态互通的尝试，这也是用户愿意迁移的主要理由。
有人直言 Bluesky 的“去中心化”存在严重问题，认为实际设计仍留有集中化控制点，因此不能把它等同于真正的联邦或无中心系统。具体担忧包括平台内未被联邦化的部分、由美国公司主导的集中式审查策略以及所谓的“enshittification”陷阱，这些都会使用户依赖公司的内容政策。还有人从工程角度指出，完整地联邦化或复制整个系统（例如 ingest 整个 firehose）成本可能很高，这会限制小规模独立节点的可行性并加剧中心化。
支持者给出实证反驳，称“ingest firehose”并非不可行：有项目在 $4/月 的 VPS 上运行全量索引，甚至有人在 rpi4（Raspberry Pi 4）上运行名为 Constellation 的 Bluesky 链接索引器，说明低成本运行节点和索引服务是可实现的。另一方面，Atproto 的 PDS（Personal Data Store）模型被视为让用户对自己数据有更多掌控与创造性使用的基础，支持者把这视为一种能够促成“mini apps”与新型在线社交实验的机会。该阵营强调在线社交值得更丰富、有趣的探索，认为技术可用于扩展社交想象力而非仅作审查工具。
有评论从协议规范和实现差异切入，指出 ActivityPub 的问题 partly 在于没有统一的事实层面规范，很多行为由 Mastodon 等实现决定，导致互操作性和一致性的不确定性。对比之下，Atproto 被认为在某些设计上更有结构，但也被批评为“数据去中心化、访问路径仍可能集中化”的模型——即数据可以分散存储，但大型节点或服务需要“意识到”大量数据以提供索引或全局视图，这反而产生新的中心化风险。总体讨论聚焦于两类设计的取舍：是优先保证没有“全局视图”的严格分散模型，还是牺牲部分分散性以换取可索引性、统一体验和可扩展性。
ActivityPub: ActivityPub（一个用于联邦社交网络的开放协议，Fediverse 中的 Mastodon 等项目基于它互相通信）
Atproto: Atproto（Bluesky 使用的协议，包含 PDS 等设计，试图在去中心化与可用性之间做出新的折衷）
PDS: PDS（Personal Data Store，Atproto 中的个人数据存储概念，用户的数据由其 PDS 控制以实现更细粒度的所有权与访问）
firehose: firehose（在此语境下指 Bluesky 的全量动态流，即可以被索引或摄取的完整帖子流）
federation: federation（联邦化：多个自治服务器按协议互相交换内容与事件，从而形成分布式社交网络）
Constellation: Constellation（一个公开的 Bluesky 链接索引器项目，被提到作为能在 rpi4 或廉价 VPS 上运行的全网索引示例）