当我们谈论去中心化社交协议时，ActivityPub 与 AT Protocol 是两个最常被对比的选项。前者依托 Mastodon 等成熟项目建立了广泛的用户认知，后者则以其更底层的「数据仓库」设计试图解决联邦社交网络的核心技术难题。Colibri 正是基于 AT Protocol 构建的即时通讯平台，它的目标是在这种尚处于 Bleeding Edge 阶段的技术之上，实现能够支撑大规模社群的分布式聊天能力。本文将聚焦其架构设计，特别是 PDS（Personal Data Server）、Repo 与 Record 三层模型如何落地为可工程化的聊天基础设施。

AT Protocol 的三层核心架构

理解 Colibri 的技术选型，首先需要厘清 AT Protocol 的三层核心模型。不同于 ActivityPub 将「发布 - 订阅」作为 federation 的核心抽象，AT Protocol 引入了 PDS、Repo 与 Record 的分层架构。PDS 是用户数据的托管节点，承担身份密钥管理与数据持久化职责；Repo 是 PDS 上每个用户的数据仓库，以 Merkle 哈希树的形式组织其所有 Record；Record 则是仓库中的最小数据单元，每条聊天消息、每个社群配置本质上都是一条带有唯一 URI 的 Record。

这种设计的核心优势在于数据可移植性与一致性保证。当用户在 PDS A 创建一条消息时，该消息被写入用户位于 PDS A 的 Repo 中，并通过 Relay 节点广播到整个网络。任何关注该用户的 PDS B 都可以通过 Repo Sync 协议拉取最新记录，实现「写入即同步」的语义。这与 ActivityPub 的端到端推送模式形成了鲜明对比 —— 后者的消息传递依赖于每个实例主动转发，而 AT Protocol 通过统一的仓库同步机制将这部分复杂度下移到了协议层。

Colibri 正是在这一协议层之上构建了其聊天模型。用户的每条聊天消息被建模为一种特定的 Record 类型，遵循 AT Protocol 的 lexicon 定义规范。消息内容、发送时间戳、引用关系等信息全部编码为 JSON 结构，存入对应用户的 Repo 中。通过这种方式，Colibri 实际上复用了 AT Protocol 原生提供的「全球可发现」与「端到端可验证」能力，无需在应用层重新实现一套分布式一致性协议。

从协议到工程：PDS 角色与部署考量

在工程实现层面，Colibri 的架构依赖于 PDS 承担的关键角色。PDS 不仅是数据的存储后端，更是身份认证与数据签名的权威节点。每当用户发送一条消息，PDS 需要使用用户的加密密钥对 Record 进行签名，确保消息的不可伪造性。这一签名过程基于 AT Protocol 定义的 DID 与 PLC 规范，用户的身份锚定在区块链式的「PLC Directory」中，支持密钥轮换与多设备同步。

对于计划自托管 Colibri 的社群而言，PDS 的部署是整个系统的第一个工程决策点。当前社区已形成几类主流部署模式：第一类是使用官方维护的 PDS 镜像，通过 Docker Compose 或 Kubernetes 进行编排，适合快速原型验证；第二类是基于开源的 PDS 实现自行搭建，适合对数据主权有更强要求的运营者。值得注意的是，PDS 的性能瓶颈往往不在于存储吞吐，而在于签名验证与 Repo Sync 的网络延迟 —— 当一个社群拥有数千活跃用户时，PDS 需要同时处理多个并发的 Repo 同步请求，这对网络 I/O 与 CPU 签名运算提出了具体的技术要求。

根据实际部署经验，建议为 PDS 分配不少于 4 核 CPU 与 8GB 内存的基础资源，并使用 SSD 作为存储后端以保证 Repo 读写延迟。网络层面，PDS 需要能够稳定访问至少三个 Relay 节点，以避免单点故障导致的同步中断。这些参数并非一成不变，而是需要根据社群规模进行线性扩展 —— 当用户数从百级增长到千级时，PDS 的横向扩展能力将成为决定用户体验的关键因素。

Repo 同步机制与消息可达性

Colibri 实现的聊天功能，其消息可达性完全依赖于 AT Protocol 的 Repo Sync 协议。当一条消息被写入发送方的 Repo 后，PDS 会将该操作封装为一个「Repo Commit」事件，附带 Merkle 树根哈希的更新。Relay 节点通过订阅这些事件，识别出哪些用户的 Repo 发生了变更，随后主动拉取新增的 Record。这一「变更驱动」的同步模式避免了全量拉取的网络浪费，使得即便在消息量极大的社群中，单次同步的数据量也保持可控。

但这里存在一个关键的工程挑战：AT Protocol 的 Repo Sync 设计面向的是「全局公开」的数据模型，而聊天消息在语义上往往具有「仅对特定接收者可见」的需求。Colibri 目前的实现策略是遵循协议的默认公开语义 —— 所有聊天记录默认公开存储在用户 Repo 中，可被任何 Relay 与 App View 访问。这种设计选择降低了技术复杂度，使团队能够专注于核心聊天功能的打磨，同时也与 AT Protocol 官方的发展路线保持一致。根据项目 Roadmap，一旦协议层完成私有数据支持的实现，Colibri 将引入加密的私密空间功能。

对于运营者而言，理解这一默认公开语义至关重要。在部署 Colibri 时，需要明确告知社群成员：当前版本的所有聊天内容默认对全网络可见，不适合承载敏感信息。这一约束并非技术缺陷，而是 AT Protocol 发展阶段的客观现实 —— 协议本身正在快速演进，私有数据加密层预计在未来的 lexicon 更新中逐步引入。

规模化挑战与社群扩展策略

当一个社群从初始的几十人扩展到数百甚至数千人时，AT Protocol 之上的聊天系统会面临一系列规模化挑战。第一个挑战来自 Relay 层的聚合能力。每个 PDS 产生的 Repo Commit 事件需要被 Relay 接收并重新发布为 Firehose 流向，当网络中的 PDS 数量增长时，Relay 的带宽与计算资源会成为瓶颈。当前社区的共识是：一个中等规模的 Relay 节点能够稳定处理约一万个 PDS 的事件流，超过这一规模需要部署 Relay 集群并进行流量分片。

第二个挑战在于 App View 的渲染性能。App View 是 Colibri 的前端展示层，负责从 Firehose 中消费事件并构建聊天的 UI 状态。当消息吞吐量高时，App View 需要实现高效的增量更新机制，避免每次新消息到达都触发全量 UI 刷新。Colibri 在这一层的工程实践采用了典型的事件驱动架构：后端服务消费 Firehose，通过 WebSocket 将增量消息推送给前端客户端，前端根据消息时间戳与 ID 进行有序合并。这种架构在技术上可行，但当单群组的消息频率超过每秒数十条时，端到端的延迟与客户端的内存占用会成为需要专项优化的方向。

针对大规模社群，建议的工程实践包括：为每个活跃社群部署独立的 App View 实例，以实现故障隔离与资源保障；在 PDS 层面启用消息批量写入，将短时间内的多条消息聚合为单次 Repo Commit，减少签名运算与网络请求次数；监控 Relay 的事件处理队列深度，当队列积压超过阈值时触发告警并考虑扩展 Relay 节点。这些参数化建议并非 универсальн 解决方案，但为运营者提供了可参考的基准线。

技术演进与生态定位

Colibri 的架构选择深刻反映了 AT Protocol 生态的现状：协议本身仍处于快速迭代的 Bleeding Edge 阶段，核心功能逐步完善但部分高级特性（如前文提及的私有数据加密）尚待成熟。在这一背景下，Colibri 选择了一种务实的工程策略 —— 优先实现协议已充分支持的功能（公开聊天、Repo 同步、身份鉴权），对暂不支持的特性保持技术跟踪并规划后续演进。

这种策略的另一个体现是对协议「透明性」设计的遵从。AT Protocol 默认所有数据公开可检索的设计，在传统社交网络视角下或许是一个限制，但对于构建「可验证的社群治理」与「数据可携带性」场景而言，恰恰提供了独特的优势。Colibri 正是利用这一特性，将聊天记录的可发现性转化为社群治理的透明性 —— 任何成员都可以独立验证群组的历史消息，无需依赖中心化服务器的诚信背书。

从更长远的视角看，Colibri 的技术路线与 AT Protocol 的演进方向高度契合。随着协议层逐步引入私有数据加密、多设备同步增强与更高效的 Repo 同步机制，Colibri 有望在不大幅重构架构的前提下平滑升级。这种「协议驱动」的演进模式，是去中心化系统相较于传统闭源软件的核心优势 —— 应用的迭代不再受制于单一厂商的版本发布，而是与底层协议的生态演进同步推进。

参考资料