当我们谈论去中心化社交网络时，文字类内容已有 Mastodon、Pixelfed 等成熟方案，但视频这种富媒体形态始终是联邦化道路上的难点。Loops 作为首个专注于短视频的联邦化平台，提供了极具参考价值的工程实践 —— 它没有另起炉灶，而是基于 ActivityPub 进行深度适配，在保证去中心化特性的同时实现了跨实例的视频内容分发与社交图谱同步。本文将剖析其协议设计选择与工程实现细节，并给出可落地的部署与运维参数。
协议适配的核心选择：Note 而非 Video
Loops 在对象建模上做了一个关键决策：将视频封装为 ActivityStreams 的 Note 对象而非原生的 Video 对象。这一选择并非技术上的妥协，而是出于最大化联邦兼容性的商业考量。当前 Fediverse 中，Mastodon、Pleroma、Misskey 等主流客户端对 Note 类型的渲染已经非常成熟，但不同平台对 Video 对象的处理能力参差不齐 —— 有的仅支持简单的 URL 引用，有的则完全忽略该类型。通过将视频作为 Note 的附件（attachment）传递，Loops 保证了即使目标实例不理解视频对象本身，依然可以展示文本内容并在客户端支持的情况下嵌入媒体。附件中包含多个分辨率的转码版本、缩略图、预览图以及内容警告标记（CW/NSFW），形成了一套完整的媒体元数据结构。
从工程角度而言，这种设计的实现成本主要集中在附件处理流程上。当一条短视频发布时，服务器端会生成一个 Create 活动，活动主体是带有视频附件的 Note，随后通过用户的出站端点（outbox）向关注者的入站端点（inbox）推送。对于使用共享入站端点（shared inbox）的远程实例，单次活动推送即可覆盖该实例上的所有目标接收者，显著降低了网络请求次数与服务器负载。
跨实例社交图谱同步：Followers 集合与 Shared Inbox
社交图谱的跨实例同步是联邦化平台的核心挑战之一。Loops 继承 ActivityPub 的演员模型（Actor Model），每个用户和每个实例都有对应的 Actor。用户 Actor 拥有独立的 inbox 和 outbox，支持被其他实例上的用户关注，从而使其发布的视频能够出现在远程时间线中。实例 Actor 则代表整个服务器，负责处理实例级别的操作（如全局删除、Relay 订阅）以及提供实例元数据。
在具体实现层面，Loops 采用两项关键技术来优化图谱同步效率。首先是 WebFinger 协议的用户发现机制 —— 无论是 @user@example.org 这样的个人标识还是实例级别的服务发现，都通过 WebFinger 解析为对应的 ActivityPub Actor 文档。这一步是所有联邦交互的前提，决定了后续活动能否正确路由。其次是共享入站端点的部署：当远程实例向本实例发送活动时，如果目标接收者数量众多，使用 shared inbox 可以将单次 HTTP 请求拆分合并为一次批量投递。工程实践表明，对于关注者分布在 5 个以上远程实例的场景，Shared Inbox 能够将出站请求数量降低约 60% 至 80%，是保障大规模联邦吞吐的关键设计。
图谱同步的另一个工程难点在于评论和回复的联邦化处理。Loops 实现了图遍历验证器（graph-walking validator），在接收远程回复时会沿着回复链向上追溯，验证该回复是否真正锚定在目标视频或其评论之上。这一机制有效阻击了垃圾信息和无关话题的跨实例渗透。内部建模层面，回复视频主 Note 的内容被存储为 Comment 对象，而对评论的回复则标记为 CommentReply 并维护正确的父子链路，确保嵌套线程在不同实例间保持一致的呈现。
工程落地：实例配置与运维监控要点
将上述协议设计转化为生产可用的系统，需要关注以下工程参数与配置建议。
在服务器基础设施层面，实例运营者需要确保域名已正确配置 HTTPS，这是 ActivityPub 安全模型的基础。存储容量方面，由于原始视频文件始终保存在发布实例本地，而远程实例仅缓存媒体元数据与缩略图，建议初始配置不低于 100GB 并预留按需扩容能力。CPU 与内存则主要消耗在视频转码与联邦活动解析两个环节，4 核 CPU 搭配 8GB 内存可以支撑日均千条视频发布的中小规模实例。
在联邦行为配置方面，Loops 在 Beta 阶段将联邦设为可选项，实例运营者需要在配置中明确声明支持的活动类型集合。建议开启的活动包括 Create、Update、Delete、Follow、Accept、Like、Announce 以及 Reject，这些覆盖了内容发布、关系变更和社交互动的主要场景。对于媒体处理，建议配置至少两种分辨率（原始分辨率加 720p 以下的移动端优化版本）以平衡带宽与兼容性。远程媒体缓存策略上，建议设置 7 天的 LRU 淘汰周期，单个媒体文件上限为 100MB，超过阈值的视频拒绝联邦分发并回退至仅本地展示。
在监控与告警层面，核心指标应聚焦于联邦投递成功率（目标值 > 95%）、Shared Inbox 响应时间 P95（阈值 < 2 秒）以及远程关注者集合的增量变化率（异常波动可能提示图谱同步延迟或对端实例故障）。日志审计方面，建议记录所有入站活动的来源域、类型和验证结果，以便在出现内容污染时快速溯源。
总结
Loops 的架构实践揭示了一个核心原则：在去中心化协议之上构建垂直场景时，兼容性优先级应当高于功能完备性。通过将视频适配为 Note 附件而非独立的 Video 对象，Loops 实现了与整个 Fediverse 的无缝互通；通过 Shared Inbox 与 WebFinger 的工程组合，它在去中心化架构下达到了可接受的内容分发效率。这些选择为后续的联邦化视频平台提供了可复用的设计范式 —— 协议层面的妥协往往能换取生态层面的最大化覆盖，而工程层面的精细化配置则是保障系统稳定运行的关键。
资料来源：Loops 官方文档与 Architecture 介绍（https://joinloops.org）