传统的博客评论系统往往依赖第三方服务，无论是 Disqus 这类商业平台还是自建的评论数据库，都意味着数据控制权的让渡与维护成本的累积。Bluesky 背后开放的 AT Protocol 提供了一种全新的可能：将评论存储在去中心化的社交图谱中，由用户自己掌控数据，同时保持与现有博客系统的无缝集成。本文将从实际实现角度出发，详解如何利用 AT Protocol 的公共 API 为静态博客添除去中心化评论功能，并探讨自建 PDS 服务器的工程考量。
去中心化评论的实现原理
AT Protocol（Authenticated Transfer Protocol）是 Bluesky 团队设计的开放社交网络协议，其核心理念是将用户身份与数据存储解耦。在传统社交平台中，平台既是身份提供商也是数据托管方；而在 AT Protocol 中，这两者可以分离。用户通过 Personal Data Server（PDS，个人数据服务器）管理自己的数据与身份，其他应用只需遵循协议规范即可访问这些数据。这种架构使得「评论」这一功能可以独立于任何单一平台存在，评论数据存储在评论者的 PDS 中，而博客只需要通过公开 API 读取这些数据即可呈现。
实现去中心化评论的关键在于理解 AT Protocol 的数据模型。协议使用 DID（Decentralized Identifier）作为全局唯一身份标识，数据的组织形式为「仓库」（Repository），每个用户的仓库中包含多种记录类型，其中 app.bsky.feed.post 即为帖子 / 评论记录。当博客想要展示某篇文章的评论时，实际上是查询特定 URI 指向的帖子及其回复线程。Bluesky 官方维护的公共 API（public.api.bsky.app）提供了对这些数据的查询接口，无需任何认证即可读取公开帖子，这为博客集成提供了极大便利。
公共 API 调用与数据获取
对于大多数博客场景，使用 Bluesky 的公共 API 是最简单直接的方案。该 API 提供了多个端点来获取帖子数据，其中与评论功能最相关的是 app.bsky.feed.getPostThread 和 app.bsky.feed.getLikes。前者用于获取帖子的完整线程信息，包括帖子本身及其直接回复；后者用于获取点赞者列表。这两个接口都是公开可访问的，不需要 API 密钥或 OAuth 认证，这大大降低了集成门槛。
具体实现时，首先需要将 Bluesky 帖子 URL 转换为 AT Protocol URI 格式。标准 URL 格式为 https://bsky.app/profile/{handle}/post/{postId}，而 API 需要的 URI 格式为 at://{did}/app.bsky.feed.post/{rkey}。handle 是用户可读的域名标识，did 是分布式标识符，rkey 是记录键（通常就是 URL 中的 postId）。实现时可以通过 API 自动完成这种转换，也可以直接在前置元数据中存储转换后的 URI。Brian Douglas 在其实现中采用了混合方案：前端接受标准 URL 以简化编辑体验，后端在发送请求前自动转换为协议所需的 URI 格式。
获取评论数据的典型请求如下：首先调用 getPostThread 端点，传入帖子 URI 和 depth 参数（设置线程深度）以获取主帖及回复；然后调用 getLikes 端点获取点赞信息。两个请求可以并行发送以优化加载时间，返回数据包含作者的头像、显示名、处理（handle）、创建时间以及评论内容。对于静态站点生成器，通常在构建阶段发起这些请求，将评论数据内嵌到生成的 HTML 中，这样可以实现零客户端 JavaScript 的评论展示，同时获得更好的 SEO 效果。
自建 PDS 的工程考量
对于追求完全数据主权的开发者，自建 PDS 服务器是更深入的选择。PDS 本质上是一个托管用户数据仓库的服务节点，连接 PDS 到 AT Protocol 网络后，该节点成为联邦网络的一部分，可以与网络中其他 PDS 进行数据同步。自建 PDS 的动机通常包括：避免依赖第三方服务、获得完整的数据导出能力、以及对数据存储位置的完全控制。
部署自建 PDS 对基础设施有一定要求。根据官方指南，PDS 需要运行在 Ubuntu 22.04 服务器上，配备至少 2GB 内存和一定容量的存储空间。安装过程通过官方脚本自动化完成，主要步骤包括：配置域名解析、安装依赖包、初始化数据库、设置 WebSocket 支持。PDS 通过 WebSocket 与联邦网络保持长连接，实时同步关注列表、帖子流等数据。部署完成后，可以使用 pdsadmin 工具创建账户，所创建的账户将完全归属于这台自建服务器。
然而，自建 PDS 也带来额外的运维负担。首先是网络可用性：PDS 必须保持公网可达，否则其他节点无法同步数据，这要求服务器具备稳定的公网 IP 和可靠的网络连接。其次是证书管理：PDS 使用 HTTPS 进行加密通信，需要配置有效的 TLS 证书，且证书续期需要自动化机制保障。此外，虽然 PDS 软件本身是开源的，但协议仍在快速演进中，升级过程中可能遇到兼容性问题。Steve Simkins 在其实践中指出，使用自建 PDS 时会遇到「规范 URL」缺失的问题 —— 通过 PDS 发布的帖子默认使用 PDS 自身的 URL，而非作者的域名，这意味着严格意义上的 POSSE（Publish on Your Own Site, Syndicate Elsewhere）难以完全实现。
评论系统的实际集成要点
将去中心化评论集成到现有博客的技术门槛并不高，但有几个实践要点值得注意。首先是错误处理：由于依赖外部 API，网络波动、API 变更或帖子被删除都可能导致数据获取失败。健壮的实现应该将这些故障隔离 —— 评论加载失败不应阻塞主内容展示，同时应提供降级 UI 提示用户前往 Bluesky 原文参与讨论。Chris Reddington 在其 Hugo 主题实现中采用了「静默失败」策略：若 API 调用异常，评论组件直接隐藏，不显示任何错误信息，对读者保持无感体验。
其次是性能优化。对于高流量的博客，每次页面访问都调用外部 API 可能带来显著的延迟。静态站点生成器通常在构建时预取评论数据，将其嵌入生成的 HTML 中，从而实现即时的评论渲染。如果需要实时性，可以考虑客户端延迟加载：使用 Intersection Observer API 在评论区域进入视口时再触发请求，既保证首屏加载速度，又避免不必要的数据获取。对于 Hugo 用户，可以创建自定义 partial 模板，接收前置元数据中的 Bluesky URI 参数，在模板中完成 API 调用和数据渲染。
最后是用户界面设计。去中心化评论的独特价值在于与原生社交平台的互通，因此 UI 设计应强化这种关联感。常见的做法包括：显示点赞者的堆叠头像（类似 Bluesky 的点赞展示）、将评论作者链接回其 Bluesky 个人主页、添加「在 Bluesky 上回复」的操作按钮引导用户前往平台交互。堆叠头像可以通过 CSS 负边距和递减的 z-index 实现层叠效果，hover 时展开以显示更多头像，这种视觉模式已经被用户熟知，能够传达「社交验证」的含义。
数据主权与可持续性
选择 AT Protocol 作为评论后端，意味着拥抱一种新的内容管理范式。评论数据不再锁定在博客运营者的数据库中，而是存储在评论者各自选择的 PDS 中。这种架构的优势在于：即使博客关停，评论数据仍然存在于网络中；评论者拥有对自己发言的完整控制权，可以选择迁移到其他 PDS 或导出数据；多个网站可以共享同一套评论生态，形成真正的社交图谱互联。
但这种模式也带来新的责任。评论者需要理解自己的数据存储在何处，以及该 PDS 的可靠性如何。博客运营者则需要接受一个事实：评论的可用性依赖于外部网络，如果 AT Protocol 网络整体出现故障（如协议升级导致兼容性问题），评论功能将不可用。因此，在设计中预留降级路径是必要的 —— 至少保留传统的「邮件联系」或「跳转到社交平台」选项，确保读者总能找到与作者沟通的途径。
从长期可持续性角度看，AT Protocol 仍处于相对早期的阶段，协议规范、API 稳定性以及 PDS 基础设施都在持续演进中。选择在此基础上构建评论系统，需要有跟踪协议更新的准备，以及在 API 变更时快速响应的能力。对于个人博客而言，这种投入通常是可接受的 —— 拥抱开放协议的乐趣往往超越了维护成本的担忧。
参考资料
本文技术细节参考了 Brian Douglas 的博客实现（2025 年 8 月）、Chris Reddington 的 Hugo 集成方案（2025 年 11 月），以及 AT Protocol 官方文档与 PDS 部署指南。