# ActivityPub 与 AT Protocol 联邦协议架构对比及跨平台数据迁移设计 > 深入对比 W3C ActivityPub 与 AT Protocol 的架构设计差异，解析联邦协议在身份模型、数据同步与跨平台迁移的工程实现要点。 ## 元数据 - 路径: /posts/2026/03/26/activitypub-at-protocol-federation-comparison/ - 发布时间: 2026-03-26T23:53:49+08:00 - 分类: [web](/categories/web/) - 站点: https://blog.hotdry.top ## 正文 随着去中心化社交网络的快速发展，开放 Web 互操作性已成为行业关注的核心议题。W3C 推荐的 ActivityPub 作为联邦社交网络的基础协议已有多年积累，而由 Bluesky 主导的 AT Protocol 则代表了新一代模块化联邦协议的演进方向。与此同时，IEEE 2874-2025 空间 Web 协议（Spatial Web Protocol）的获批为更广泛的智能体间通信奠定了标准化基础。本文将从架构设计、数据模型、身份机制三个维度对比 ActivityPub 与 AT Protocol，并探讨跨平台数据迁移协议的工程实现路径。 ## 核心架构差异：集中式联邦与模块化架构 ActivityPub 采用经典的客户端-服务器双层架构，包含社交 API（客户端到服务器）与联邦协议（服务器到服务器）两个核心组件。服务器间通过 ActivityStreams 2.0 格式的 JSON 对象传递活动通知，实现内容的跨实例分发。这种架构的优势在于部署简单、概念清晰，Mastodon、Pleroma、Pixelfed 等主流去中心化社交平台均基于此构建。然而，其局限性也较为明显：服务器充当内容聚合的单一节点，客户端功能受限于服务器提供的能力集合，迁移到新服务器时数据完整性依赖服务器实现质量。 AT Protocol 则采用了完全不同的模块化架构设计。协议层被划分为标识层（PDS，Personal Data Server）、应用层（AppView）与算法层（Relay）三个独立组件。用户的身份数据存储在个人数据服务器上，而非平台所属的服务器，这从根本上解决了数据主权问题。应用层负责聚合来自多个 PDS 的数据并提供统一的查询接口，算法层则负责发现和同步新内容。这种分层设计使得用户可以在不同平台间自由切换，而无需重新建立社交图谱。2026 年初，AT Protocol 已在 IETF 开启标准化进程，其Lexicon 机制允许协议进行渐进式扩展而无需大规模版本升级。 从工程实现角度，两种架构的核心取舍在于：ActivityPub 追求简单性与向后兼容性，适合构建同质化的社交网络集群；AT Protocol 则以数据可移植性为核心目标，适合需要跨生态互操作的复杂场景。 ## 数据模型对比：ActivityStreams 与 Lexicon 扩展机制 ActivityPub 的数据模型基于 ActivityStreams 2.0，这是一套以「对象-活动」（Object-Activity）为中心的语义框架。每个内容实体被建模为对象（Object），创建、关注、分享等操作被建模为活动（Activity）。这种设计天然适合社交网络的动态流模型，服务器通过解析活动类型即可理解内容意图。但 ActivityStreams 的固定词汇表也限制了协议的扩展灵活性——当需要表达新的内容类型或交互模式时，社区需要通过 Fediverse Enhancement Proposals（FEP）流程推动标准演进。 AT Protocol 采用了完全不同的设计哲学。其核心数据定义语言称为 Lexicon，本质上是一种基于 AT URI 的模式系统，允许任何人定义新的数据结构与 API 端点。Lexicon 使用 JSON Schema 的超集语法，支持类型检查、枚举定义与嵌套对象结构。每个 Lexicon 文档拥有唯一的 NSID（Namespaced ID）标识，例如 `app.bsky.feed.post` 即为 Bluesky 发帖内容的标准定义。这种设计使 AT Protocol 具备了类似 GraphQL 的强类型特性，同时保持了去中心化架构的开放性。从实际效果看，Lexicon 机制使得 AT Protocol 能够快速演进并接纳新功能，而不会破坏现有实现的兼容性。 对于跨平台迁移协议设计而言，理解两种数据模型的映射关系至关重要。当前社区已出现 Bridgy Fed 等桥接工具，尝试在 ActivityPub 与 AT Protocol 之间建立数据转换层，但其转换逻辑复杂且难以完整保留语义信息。 ## 身份与认证机制：WebFinger 联合与 DID 分布式标识 身份系统是联邦协议的核心基础设施。ActivityPub 依托 WebFinger 协议实现跨实例身份发现，通过 `.well-known/webfinger` 端点解析用户acct（如 user@example.com）到对应的服务器端点。这种设计延续了传统域名体系的信任模型，身份与服务器绑定，用户迁移时需要在新实例重新建立社交关系。 AT Protocol 采用了去中心化标识符（DID）作为身份层核心。每个用户拥有独立的 DID 文档，其中包含公钥、认证方法与服务端点信息。当前主要实现使用 DMO（Did Method Operator）简化方案，将 DID 解析结果存储在用户自己的 PDS 上，实现了身份与特定服务商的解耦。更重要的是，AT Protocol 的身份系统支持密钥轮换与恢复机制，用户更换 PDS 时只需更新 DID 文档中的服务指向，无需改变身份本身。 从工程实践角度，两种身份模型的取舍直接影响迁移协议的设计复杂度。ActivityPub 环境下，跨平台迁移需要导出关注列表、帖子历史、媒体附件三层数据，并在目标实例逐个重建社交关系；AT Protocol 环境下，由于身份绑定于加密密钥而非服务器，数据迁移可实现自动化，用户在目标平台完成身份验证后即可自动恢复社交图谱。 ## 跨平台数据迁移协议的设计要点 综合上述分析，设计一套实用的跨平台数据迁移协议需要关注以下参数与实现细节。首先是数据导出层协议，建议采用标准化的 ATVR（ActivityPub Transport Virtualization）格式，将导出数据打包为包含元数据包、关系图谱、内容库三部分的 JSON 存档。元数据包含原始平台标识、导出时间戳与数据完整性校验值；关系图谱使用图结构存储关注者、封禁列表、分组信息；内容库则按时间倒序存储带签名的原始数据。 其次是身份验证层设计，建议支持双模式验证：对于 ActivityPub 实例，采用 OAuth 2.0 授权码流程获取跨实例操作权限；对于 AT Protocol 环境，直接使用用户私钥签名迁移请求。迁移过程应实现增量同步机制——首次全量同步后，源平台持续推送增量变更直至用户确认切换完成，避免迁移期间的信息丢失。 最后是回滚策略，建议在协议层引入迁移状态机：初始化（Initiated）→ 同步中（Syncing）→ 验证中（Validating）→ 完成（Completed）→ 可回滚（Rollback-Enabled）五个状态。用户在验证通过后仍保留 48 小时的回滚窗口期，期间源平台保留只读访问权限，确认为不可逆迁移后再彻底清理源数据。 ## 资料来源 本文技术细节参考以下来源：W3C ActivityPub 规范定义了联邦社交网络的客户端-服务器与服务器-服务器通信模型；AT Protocol 官方文档阐明了 Lexicon 机制与模块化架构设计；IEEE 2874-2025 空间 Web 协议为智能体间通信提供了标准化框架；Bridgy Fed 项目展示了跨协议桥接的工程实践路径。 ## 同分类近期文章 ### [浏览器内Linux VM通过WebUSB桥接USB/IP：遗留打印机现代化复活工程实践](/posts/2026/04/08/browser-linux-vm-webusb-usbip-bridge-printer-rescue/) - 日期: 2026-04-08T19:02:24+08:00 - 分类: [web](/categories/web/) - 摘要: 深入解析WebUSB与USB/IP在浏览器内Linux虚拟机中的协同机制，提供遗留打印机复活的工程参数与配置建议。 ### [从 10 分钟到 2 分钟：Railway 前端构建优化的实战复盘](/posts/2026/04/08/railway-nextjs-build-optimization/) - 日期: 2026-04-08T17:02:13+08:00 - 分类: [web](/categories/web/) - 摘要: Railway 将前端从 Next.js 迁移至 Vite + TanStack Router，详解构建时间从 10+ 分钟降至 2 分钟以内的关键技术决策与迁移步骤。 ### [Railway 前端团队 Next.js 迁移复盘：构建时间从 10+ 分钟降至 2 分钟的工程决策](/posts/2026/04/08/railway-nextjs-migration-build-optimization/) - 日期: 2026-04-08T16:02:22+08:00 - 分类: [web](/categories/web/) - 摘要: Railway 团队将生产级前端从 Next.js 迁移至 Vite + TanStack Router，构建时间从 10 分钟压缩至 2 分钟以内。本文深入解析两阶段 PR 迁移策略、零停机部署细节与可复用的工程参数。 ### [WebTransport 0-RTT 在 AI 推理服务中的低延迟连接恢复实践](/posts/2026/04/07/webtransport-0-rtt-connection-recovery/) - 日期: 2026-04-07T11:25:31+08:00 - 分类: [web](/categories/web/) - 摘要: 深入解析 WebTransport 基于 QUIC 协议的 0-RTT 握手机制，为 AI 推理服务提供毫秒级连接恢复的工程化参数与监控方案。 ### [Web 优先架构决策：PWA 与原生 App 的工程权衡与实践路径](/posts/2026/04/06/pwa-native-app-architecture-decision/) - 日期: 2026-04-06T23:49:54+08:00 - 分类: [web](/categories/web/) - 摘要: 深入解析 PWA、Service Worker 与响应式设计的工程权衡，提供可落地的技术选型参数与缓存策略清单。