当我们谈论去中心化代码托管时，通常会想到 Radicle 的 P2P 迁移方案、Forgejo 的政府平台部署，或是 GitHub 被微软收购后的开源替代浪潮。这些方案各有侧重，但几乎都聚焦于单一平台的自洽性建设。然而，当不同去中心化 forge 之间需要实现真正的互联互通时，一个更为根本的问题浮现出来：如何在保持各平台自主性的前提下，建立标准化的联邦通信协议，让代码协作跨越平台边界流动？
这正是 Tangled 试图回答的问题。作为一个构建于 AT Protocol 之上的代码协作平台，Tangled 不仅是一个去中心化的 Git 托管服务，更提出了一种联邦化 forge 的互联互通思路。其核心理念并非重新发明一种全新的协议，而是借助 AT Protocol 已经成熟的联邦架构，为不同 forge 实例之间的身份认证、仓库发现、Pull Request 交互提供统一的消息层。
AT Protocol 作为联邦通信层的技术逻辑
理解 Tangled 的联邦化路径，首先需要理解 AT Protocol 的设计哲学。AT Protocol 起源于 Bluesky 项目，旨在解决社交网络的联邦互联问题。与传统联邦社交协议（如 ActivityPub）不同，AT Protocol 采用了一种更接近 Git 的数据结构模型：所有数据以 repository 的形式组织，每个 repository 由一条 MERGE DAG（有向无环图）构成，数据提交采用类似 Git 的哈希链式结构。这种设计天然适合代码协作场景，因为 Git 本身就是一种分布式版本控制系统，两者之间存在深层的结构亲和性。
Tangled 将这种亲和性进一步放大。在 Tangled 的架构中，每个代码仓库被映射为 AT Protocol 中的一个 repository，提交历史对应为该 repository 的更新记录，而 Pull Request、Code Review、Star 等社交行为则被编码为 AT Protocol 的记录类型。这种映射方式使得 Tangled 无需为联邦通信单独设计协议层，而是直接复用 AT Protocol 已有的数据同步机制。更重要的是，由于 AT Protocol 本身支持跨服务器的数据拉取和推送，Tangled 天然具备了跨实例访问其他兼容 forge 的能力。
联邦互联的核心工程挑战
理想很丰满，现实却充满工程细节的荆棘。联邦化 forge 互联面临的首要挑战是数据模型的异构性。不同的 forge 平台在 Issue、Pull Request、CI 配置等概念的定义上存在显著差异。GitHub 使用 RESTful API 描述工作流，GitLab 强调管道（Pipeline）和 MR（Merge Request）的层级关系，Forgejo 则兼容大量 GitHub API 但在权限模型上有所简化。Tangled 要实现与这些平台的互联，首要任务是建立一套通用抽象层，能够将不同平台的实体映射为统一的联邦消息格式。
身份联邦是另一层挑战。在传统单点登录场景中，OpenID Connect 或 OAuth 2.0 提供了标准化的身份验证流程。但在去中心化语境下，身份的可移植性要求更高：用户应当能够使用同一个 DID（Decentralized Identifier）在不同 forge 实例之间自由迁移，同时保留其在该身份下积累的声誉和协作历史。Tangled 依托 AT Protocol 的 ATP（Authenticated Transfer Protocol）实现了这种身份抽象，用户持有私钥即可在任意支持 AT Protocol 的服务上进行签名操作，无需依赖中心化的身份提供商。
第三个挑战在于事件一致性。当一个 Tangled 实例上的 Pull Request 更新时，如何确保另一个实例上的关注者能够及时收到通知，并在本地视图中反映出最新的状态变更？这涉及到联邦事件分发的一致性保证。AT Protocol 采用的是一种基于 CAR（Content Addressable aRchive）的增量同步机制，每个 repository 的变更被封装为 CAR 格式的数据块，客户端通过比较本地状态与远程状态的根哈希差异来拉取增量更新。这种设计在理论上能够实现高效且一致的分布式状态同步，但在实际网络中仍需处理分区容忍、冲突解决等问题。
实践路径：从原型到标准化的演进
当前阶段，Tangled 的联邦化实践仍处于早期原型验证期。根据其官方文档和公开讨论，Tangled 优先实现的是同一协议栈内的联邦互联，即不同 Tangled 实例之间的直接通信。对于与其他 forge 平台（如 Forgejo、Radicle）的互联，现阶段更多处于概念验证和接口设计阶段。一个可行的渐进路径是先在 AT Protocol 生态内建立足够的覆盖度，再通过桥接层逐步向外延伸。
桥接层的实现思路并不复杂：设计一组适配器（Adapter），将外部平台的 API 调用转换为 AT Protocol 消息，反之亦然。例如，当一个外部 forge 上的 Issue 创建事件触发时，桥接器将其转换为对应的 AT Protocol 记录并发布到联邦网络中；当 Tangled 用户对该 Issue 进行评论时，桥接器将消息推送回原始平台。这种双向往复的转换逻辑需要处理丰富的边缘场景，包括但不限于富文本格式的兼容、权限检查的委托、以及长链接的解析等。
从工程参数的角度看，当前可参考的联邦互联实现建议包括：消息队列的缓冲区大小建议不低于 1024 条，以防高并发场景下的消息积压；联邦同步间隔的默认值可设置为 30 秒至 5 分钟之间，具体取决于实例规模和网络条件；事件签名的哈希算法推荐使用 Blake3 以平衡安全性和性能；跨域认证的令牌有效期不宜超过 24 小时，应结合 refresh_token 机制实现无感知的会话延续。
展望：联邦化协作网络的形成
Tangled 的探索之所以值得关注，不仅仅因为它是一个新的代码托管平台，更因为它代表了一种自下而上的协议化思路：不试图用统一标准覆盖所有功能，而是先在一个具有足够弹性的底层协议之上生长出丰富的上层应用，再通过实践检验哪些交互模式值得标准化。这种演进路径在互联网的早期历史中曾反复出现，从 SMTP 到 HTTP，从 IRC 到 WebSocket，协议的生命力往往来源于真实场景的驱动而非事先的完美设计。
对于整个去中心化代码托管生态而言，Tangled 的联邦化实验提供了一种新的可能性：如果未来的开发者不再被锁定在单一平台，而是能够携带自己的身份和协作历史在不同 forge 之间自由流动，那么整个开源协作网络的面貌将会发生根本性变化。这种变化不会一蹴而就，但 Tangled 正在用行动表明，联邦化的代码协作不再是理论设想，而是正在到来的工程现实。
资料来源：Tangled 官方文档（docs.tangled.org）及 AT Protocol 规范概述（atproto.com）。