二十年里，forge 一直是中心化的
代码托管这件事，二十年来一直是“把代码放在别人家”：方便、好用、有生态，代价是可用性、功能和去留都取决于那家公司。Tangled 在官方博客里宣布了他们的答案——一个基于 AT Protocol 的联邦式代码托管平台，自称是第一个真正联邦化的 forge：你可以只自托管 Git 托管或 CI runner，也可以把 API 服务和界面一起搬回自己服务器，同时依然能和别人的实例正常协作。
博客把这段历史画成三步：2005 年是邮件加 Git，2010 年前后是 GitHub 加 Git，2025 年开始是 AT Protocol 加 Git。取舍很直白——邮件协议活得久但体验差，中心化平台体验好但依赖别人运营。联邦化的目标是把两头都拿回来：底层用开放协议，上层做出正常的产品体验。
拆掉单体：边缘前端加内存索引
Tangled 原来的架构是一个 Go 单体，叫 appview，用 html/template 加 htmx 渲染页面，数据放在一台瑞典中等服务器的 SQLite 里。问题很具体：只有距离瑞典五十到一百毫秒以内的用户才谈得上体验，而大多数用户不在那里。现在前端重写成 Svelte 部署到边缘，数据由新的 Rust 服务 bobbin 提供——一个无磁盘、纯内存的索引器，部署在 11 个以上区域。只读索引负责协议数据，其余功能分给一组新的配套服务。
把 issue 和 PR 存进仓库本身
这次改动里最值得看的是数据模型。issue、PR、评论、反应、标签，以及协作者、成员、黑名单，全部改为存放在 knot（他们的 Git 节点服务）上，和代码放在一起，形式是 COB——协作对象，本质上就是仓库里的一串 Git 对象，随 AT Protocol 的 firehose 同步。理由很朴素：一个项目的 issue 和 PR 本来就是项目的一部分，放在哪都该跟着代码走，这样迁移成本才低。
随之而来的是“节点会不会替我说话”的问题。他们的解法是双向验证：每次创建或编辑一条记录，网页端还会往你自己的 PDS 写一条 attestation 记录，指向那条记录的版本和背后的变更，两边对得上才算数。knot 本身也用 Rust 重写（knot2），Git 服务与 SSH 服务编在同一个二进制里。
组织账号与堆叠 PR
产品层面还补了几块。组织是真实的 AT Protocol 账号，有自己的 DID 和 handle，托管在 Tranquil PDS，默认给一个 name.tngl.sh 的地址，也可以换成自己的域名，无密码、可委托。PR 流程重做后，用普通 Git 的人也能提交和评审堆叠 PR，用 JJ 的还能在单个变更之间做 interdiff。自托管的人需要把 knot 升到 v1.20.0；私有仓库、命令行工具、各语言 SDK 和给智能体用的技能还在后面几周。
对小团队和客户项目的实际意义
这套东西最直接的提醒不是“要不要换平台”，而是数据归属该怎么设计。给客户做系统时，代码、需求、issue、评论常常散在不同服务商手里，客户想换供应商时才发现搬不动。Tangled 给出了一个可借鉴的结构：把协作数据当成仓库的一部分，用 Git 对象承载，天然带历史、可签名；再用一个独立索引层提供查询性能。
哪怕不用 AT Protocol，这个分层——真相在仓库，索引可重建——也值得写进架构文档。它同时回答了两个常被追问的问题：数据在谁手里，以及换掉服务商要多久。
评论交流
欢迎留下你的想法