# Bluesky 全网回放上线，谁在保管这份历史档案？ **Summary:** Jetstream v2 能回放经过筛选的 AT Protocol 历史记录，并无缝切换到实时数据。Bluesky 仍持有默认档案，使得恢复更容易，同时去中心化进程尚未完成。 - Canonical: https://markhuang.ai/zh/news/bluesky-network-replay-who-holds-archive - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-13 - Section: News - Tags: Bluesky, AT Protocol, Jetstream, 去中心化社交, 开发者基础设施 - Source: [AT Protocol](https://atproto.com/blog/introducing-bluesky-protocol-services) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![分布式网络节点将数据汇入一条蓝色实时流，穿过一叠透明的历史档案片段](https://cdn.markhuang.ai/news/bluesky-network-replay-who-holds-archive/hero.webp) *回放让网络历史更容易获取，也让谁在保管这段历史这件事变得更加显眼。* 2026 年 8 月 13 日，[Bluesky 推出了 Bluesky Protocol Services](https://atproto.com/blog/introducing-bluesky-protocol-services)，给它运营的公共 AT Protocol 基础设施换了个名字，也搬到了新的文档站点。这次更新带来了 Jetstream v2——它保存着整个网络的压缩档案，能回放过去记录的任意筛选片段，然后无缝衔接到实时更新。 我真正关心的是这个切换动作。开发者停机之后可以恢复服务，也可以从头构建索引，不用再挨个爬取每个 Personal Data Server，也不用写那种从历史数据切到实时流的脆弱衔接逻辑。Bluesky 对档案下载要求 API 密钥，因为这部分流量很大；而实时 WebSocket 依然开放，不需要认证。 我的看法是喜忧参半，但总体偏正面。Bluesky 把网络管道里一个棘手的部分做成了可用的服务，同时也让网络当前的依赖关系变得更清晰。协议是开放的，但大多数开发者会用的那个便捷档案，仍然由 Bluesky 运营。 ## 回放解决了一个不起眼但要命的故障模式 Jetstream 之前就在通过 WebSocket 推送选定的 AT Protocol 事件，纯 JSON 格式。做实时信息流、标签器、机器人或者搜索索引都挺好用，但它解决不了历史数据的问题。新接入的消费者得先拉取现有仓库、自己管理回填，然后再切到实时流——这个过程不能漏掉记录，也不能重复。 新的[网络回放流程](https://bsky.network/docs/jetstream-replay)会先规划你要的档案时间范围，通过 HTTP 下载已归档的数据段，然后在归档的末端直接接上实时流。服务器不需要为每个消费者维护游标或订阅状态。客户端自己保存最后处理到的序列号，SDK 负责处理归档和实时数据之间的去重。 这远不只是文档层面的整理。恢复服务从一个需要自己折腾的数据工程，变成了一个可以断点续传的服务调用。档案端点按压缩后的响应字节数计费，而不是按请求次数。如果客户端在下载过程中触达限额，服务会返回一个重试间隔，并支持从上一个字节偏移处继续下载。 > **Info:** > > 我会用 Replay 来做恢复和受控回填，但我仍然会自己持久化游标，保证事件处理是幂等的，并且提前演练一遍完整的重建流程。托管档案减少了工作量，但索引的责任并没有转移出去。 ## API 密钥标记了成本边界 Bluesky 把实时流保持开放、把历史数据放在 API 密钥后面，这个分法很合理。实时分发的成本相对低。提供旧数据意味着要存储档案、在档案里扫描你要的那段数据，再传出大量字节。API 密钥让运营方能够计量这部分负载，也保护了其他消费者不被挤占。 这也划出了一道服务边界，开发者应该把它当作一个依赖来看待。Bluesky 在发布文章和 Replay 文档里都没有提到价格。API 密钥不等于未来一定会收费，我不应该凭空猜测。但它确实意味着，档案访问现在绑定了账户、配额和运营方的策略。这些都是托管基础设施的常见属性，但它们应该出现在架构图里，也应该出现在故障预案里。 早期 [Reddit 上的讨论](https://www.reddit.com/r/BlueskySocial/comments/1vnk5vc/introducing-bluesky-protocol-services/)基本没触及这个取舍。有人抱怨想要面向用户的新功能，有人把大规模数据访问等同于"又多了一堆机器人"。这些评论算不上有力证据，倒是暴露了这次发布在传播上的问题——回放服务对开发者之所以重要，恰恰是因为普通用户根本不应该感知到背后那套让应用数据保持完整的回填流程。 ## 开源仍然需要运营方 Jetstream 是开源的，可以自己部署。这一点很重要。[自托管指南](https://bsky.network/docs/jetstream-self-host)说，一个静态编译的 Go 二进制文件就能跑实时流、回放和快照，不需要额外的数据库。运营方可以在自己的硬件上保存档案、决定保留多久，也可以审计自己提供的数据。 但同一份指南也暗示了独立性的代价，虽然没有直接报价。全网档案已经是 TB 级别，而且还在随网络增长。稳定状态下内存需求只要几 GiB，指南说 CPU 需求也不高。真正的硬性要求是磁盘和网络流量。开源代码让替代方案成为可能，但还是得有人出钱、有人运营。 这正是我觉得[电子前沿基金会（EFF）](https://www.eff.org/deeplinks/2024/12/what-you-should-know-when-joining-bluesky)之前的批评有用的地方。2024 年 12 月，EFF 指出 Bluesky 的“可信退出”并不等于去中心化网络，因为核心托管、中继、审核和身份基础设施仍然集中在公司手里。那篇文章里的具体数据已经过时了，我不会直接引用。但这个区分依然成立：别人能跑的代码，和别人已经在实际规模上跑起来的基础设施，是两回事。 Bluesky 自己的机器之外也有进展。AT Protocol 指南现在列出了 Microcosm、Blacksky、UpCloud、Firehose 和 Bluesky 的中继。2026 年 3 月，Bluesky 还宣布给 [Hubble](https://atproto.com/blog/introducing-hubble-a-public-mirror-for-the-whole-atmosphere) 项目提供了 2 万美元资助，这是一个独立维护的项目，目标是在 Personal Data Server 离线时保持公共仓库数据可用。公告说 Hubble 会镜像当前的公共状态，而不是事件历史，所以它不能替代 Jetstream Replay。但它的资金模式更接近可信退出的要求：付钱给另一个运营方来构建和运行副本，然后把软件开放给其他人。 ## 谁应该保管档案？ 如果是小团队，我会先用 Bluesky 托管的 Jetstream。在证明产品价值之前就重建网络摄入层，只是昂贵的表演。我会记下 API 限制，保留我能合法保留的游标和派生数据，然后把这个依赖关系明确写下来。 但如果你的应用承诺依赖完整历史、独立审核，或者需要在 Bluesky 宕机时还能活下来，答案就不一样了。在说系统有弹性之前，我会先测试自托管或者第二个提供商。公开源代码回答了"能不能替换"的问题。我关心的是，当默认端点挂掉的时候，替换需要多久。 Bluesky Protocol Services 给网络提供了一个更清晰的入口，Jetstream v2 解决了背后的一个实际问题。我觉得这是扎实的基础设施工作。等到开发者能在多个可用的运营方之间选择时，我才会说回放层是去中心化的。今天，Bluesky 让默认选项变得更好，也让剩下的依赖关系变得更清晰。