Bluesky 把自己运营的协议基础设施重新打包成一个新品牌——Bluesky Protocol Services,换了新站点,也换了一条规则。最扎眼的一条:实时数据流依旧免费、无需鉴权,但你想拿历史数据、做大规模归档抓取,现在需要一个API token,而且是按下载内容压缩后的字节数计费,不是按调用次数。这是Bluesky第一次在协议基础设施层面,公开划出一条收费线。
免费的只剩实时那一半
新站点取代了原来的docs.bsky.app,把relay、Jetstream、Bluesky API的文档收进一个入口。真正的产品动作藏在Jetstream v2里。
Jetstream原本只干一件事:把relay吐出的原始协议数据转成JSON,通过WebSocket实时推给开发者。它快、轻,但没有记忆——想要历史记录,只能自己去backfill整个repo,再手动切到live流,一套系统要养两条数据管线。
v2补上了这块记忆。Network Replay让开发者把filter POST给planSnapshot,拿到归档segment,下载完直接无缝接上实时WebSocket,中间不留空档。更轻的用法是只走listSegments+getSegment的纯HTTP snapshot,连WebSocket都不碰,做一次月度分析或故障后补数据就够。配套还发了TypeScript和Go两版Jetstream SDK,把重连、去重、cursor管理这些琐事包了一层。
收费的那一半:按字节,不按次数
规则很直白:实时WebSocket继续免费、不鉴权;涉及归档的请求——snapshot下载、replay补历史——都要token,计费按返回内容压缩后的字节数算。
这个计费单位选得有意思。按次数收费,防的是刷接口;按字节收费,防的是真正的带宽消耗——爬全网历史的数据分析团队,成本会比只做增量订阅的小开发者高出一个量级。对个人爱好者、单个feed生成器来说几乎无感;对做规模化历史抓取、跑长周期分析的团队,这是第一次要认真算一笔基础设施账。
官方也给planSnapshot划了硬上限:一次请求最多4种event kind、10,000个DID、100个collection;归档segment压缩后单个体积在256MB量级,后台还会做compaction,重写过的segment需要重新核对checksum才能确认没读错。
- 提醒.官方文档目前没有公开具体单价和配额,只说明鉴权失败返回401、超限返回429并带Retry-After——真实成本账,现在只能等定价落地才算得清。
“整网存档”这句话,得打个问号
官方把这套归档能力描述成保留了“整个网络的压缩存档”,听起来像历史数据可以无限回溯。但业内对Jetstream这类轻量流的一贯认知是:它面向的是补最近数据、扛短暂宕机,不是替代relay做长期完整归档——真正需要密码学验证、完整仓库状态的场景,还得回去用firehose那套更重的协议层接口。官方没公开具体保留窗口有多长,这中间的落差,值得在拿它做长周期分析前先打个问号。
天下熙熙,皆为利来。
去中心化社交一直拿“开放、免费的基础设施”当卖点,对Twitter/X 2023年那场API收费风暴冷眼旁观。这次Bluesky对归档访问引入token和按字节计费,是它第一次在协议层公开划出付费线——哪怕现在只对高带宽的归档请求收钱,实时流还继续免费。
这个选择不算意外。维护relay、维护整网压缩存档,带宽成本是实打实的,靠开放精神撑不住服务器账单。真正该盯的是接下来两件事:定价什么时候公布,v1到v2的迁移期给多久。如果定价压得太狠,历史数据抓取会变成大公司才玩得起的游戏,和Twitter/X当年逼退中小开发者的路径有几分像;但至少Bluesky留了live tail全免这条底线,没把整条协议一次性锁死。
- 结论.免费的从来不是基础设施本身,而是你还没碰到它的成本边界。