切换 Git 仓库的托管服务商，只需敲下一行 git remote set-url origin。命令执行只需几十毫秒。但在完成切换后，维护者会发现自己依然离不开原平台。代码提交记录迁走了。但积累数年的 issue、PR 与审查对话，全留在了中心化数据库里。
2026 年 10 月 30 日，芬兰团队 Tangled Labs 发布了联邦代码 forge。该项目将 issue 与 PR 封装为 Git 内部对象。系统通过 AT Protocol 提供去中心化验证服务。团队试图打破数据垄断，将协作历史的管理权交还给仓库。
回顾协作工具演进史，2005 年诞生的 Git 依靠邮件列表协同。代码流转与技术讨论直接运行在开放协议之上。2009 年 GitHub 依靠 Web 界面带来了操作便利，但也把开发者锁死在集中式服务之中。Tangled 试图在开放协议的长久生命力与现代界面的易用性之间取得平衡。
迁移远端只需 3 秒，拷走协作历史耗时数年
开源项目的迁移成本并不在源码文件。真正的锁定，来自围绕代码产生的人类协作上下文。现存平台普遍将 issue 和 PR 视作私有资产，存储在各自的关系数据库里。一旦团队决定脱离现有生态，跨平台迁移工具往往只能导出扁平的 JSON 文件。原有的提交引用关系与交互上下文由此丢失。
协作记录与代码载体割裂后，中心化平台的网络效应便牢牢绑定了社区。即便外部主机提供了更廉价的算力，维护者也无法轻易转移项目。解除锁定的核心，在于让协作元数据获得与代码提交等同的便携属性。
重写单体架构：Rust 内存索引服务进驻 11 个全球节点
在本次重构之前，旧版 Tangled 采用了基于 Go 语言的单体架构 appview。该服务集成 SQLite 数据库与 HTML 模板渲染，运行在瑞典的一台中型服务器上。对于网络往返时延在 50 至 100 毫秒以外的全球开发者，页面加载的卡顿感十分明显。单节点 SQLite 架构难以支撑跨大洲的高并发读写。
为了支撑全球范围的联邦协作，团队将前端迁移至边缘部署的 Svelte 框架。后端核心索引组件 bobbin 则使用 Rust 重写，采用无磁盘的纯内存只读设计。只读索引与状态持久化分离，降低了边缘查询节点的运维复杂度。
图：Tangled 官方发布的联邦代码 forge 架构设计与版本发布图景。来源：Tangled 官方博客
目前 bobbin 已在超过 11 个全球区域完成部署。它专门负责处理 AT Protocol 协议数据检索与缓存加速。写入请求与协议外的杂项逻辑被剥离给独立的后端集群。架构切分让全球开发者能够以毫秒级延迟查询状态。
协作记录写入 Git 对象链，代码迁到哪里讨论跟到哪里
伴随架构迭代，系统底层的通信词表从旧有的 sh.tangled.* 切换为 org.tangled.* 规范。核心节点服务升级为基于 Rust 编写的 knot2。单个可执行文件中内嵌了自研的 Git 服务与 SSH 服务。自托管维护者必须同步升级至 v1.20.0 版本。双协议打包进单一程序，压缩了私有节点的部署成本。
在 knot2 的数据体系中，issue、PR、评论及标签均被封装为协作对象（COB）。这些协作对象直接作为 Git 对象链存放在仓库内部。协作对象与源代码提交共享同一套底层版本机制。 项目成员名单与黑名单规则同样采用该机制持久化。
代码存放在哪里，围绕代码产生的一切讨论就跟到哪里。开发者克隆代码仓库时，也同步拉取了完整的项目治理记录。各个 knot 节点因此扮演了类似个人数据服务器（PDS）的角色。节点通过标准 AT Protocol 事件流向全网广播签名快照。
引入双向签名存证，阻断伪造审查记录
去中心化架构必须面对恶意节点的信誉挑战。如果节点全权代管写入，恶意服务器就能在本地篡改评论，甚至冒充开发者发言。Tangled 通过引入 attestation 双向存证机制来化解这一信任危机。
用户每次在 knot 节点创建或修改记录，网页端会同步向自有的 PDS 写入一条 org.tangled.graph.attestation 数据。该存证记录明确锁定当前操作的版本编号与 COB 变更哈希值。双向校验机制确保第三方节点无法在未经授权时伪造审查结论。
在团队管理层面，组织账号被实现为标准的 AT Protocol 账号。它们拥有专属的去中心化标识符（DID）与域名句柄。这些组织账号托管在 Tranquil PDS 实例上，采用免密码的委托授权机制运作。创建者可以直接分配成员权限，也可以将默认的 tngl.sh 后缀替换为自有域名。
代码审查流程同样进行了重构，全面支持堆叠式拉取请求（Stacked PR）。无论使用 Jujutsu 还是原生 Git，系统都能针对不同轮次展示提交差异。高级版本控制工具接入 Web 界面，优化了渐进式审查体验。
图：基于 Svelte 重构的 Tangled Web 界面与多分支堆叠审查流。来源：tangled.org 站点截图
解绑中心化数据库，却把同步与治理难题留给节点
Tangled 的分层托管方案给开发者带来了极高的自由度。团队既可以仅自建 Git 存储或 CI 执行器，也可以全量托管 API 服务与 Web 前端。已有社区成员基于 Cloudflare Workers 与 Artifacts 构建出无服务器化的定制 knot 节点。这种高扩展性也让平台天然具备对接 AI agent 工具链的潜力。
但这套理想主义架构依然需要跨过严酷的工程现实。将海量文本讨论与状态标记塞进 Git 对象链，会推高仓库的存储开销。仓库体积随时间持续膨胀，克隆操作的网络损耗也会被放大。
并发冲突与数据一致性是另一道未解难题。Git 依赖 DAG 记录历史，缺乏关系型数据库毫秒级的行锁支持。多位协作者并发更新同一标签时，冲突消解机制将面临考验。
内容治理成本同样从中心平台转移到了去中心化节点。GitHub 依靠内部风控模型与人工团队过滤垃圾提问与自动化刷屏。在开放的 AT Protocol 事件流中，恶意请求的拦截压力由各个 knot 节点自行承担。
中心化平台的壁垒，本就建立在对协作历史的排他性占有之上。代码提交本可自由流转。但中心化平台掌控了协作记录与身份，将项目牢牢锁在私有云端。Tangled 迈出的这一步，证明了协作元数据可以回归代码仓库的物理边界。去中心化协作能否改变开源格局，取决于额外的运维与一致性成本。 只有这些开销被普通团队长期承受，联邦模式才能真正立足。
参考链接：
- Tangled 官方博客发布公告：The federated code forge
- Tangled 官方文档：架构设计与自托管指南
