Tangled Code Forge: 基于 AT Protocol 的联邦式 Git 协作

去中心化代码协作

Tangled 将自己定位为 GitHub 或 GitLab 等中心化代码托管平台的联邦式替代方案。通过利用 AT Protocol，Tangled 允许开发者托管自己的代码、CI 运行器和 API 服务器，同时保持在统一且可互操作的网络中。这种方法旨在通过确保项目数据（包括 Issue、Pull Request 和评论）保持可移植性并由仓库所有者控制，从而解决供应商锁定问题。

架构重构与性能提升

最新版本引入了重大的架构调整，以改善全球性能。此前，Tangled 依赖于一个同时处理后端和 UI 的 Go 语言单体应用。新架构将这些组件解耦：

• 前端： 一个部署在边缘的新 Svelte 前端。
• 索引器： 一个名为 bobbin 的无磁盘内存索引服务，使用 Rust 编写，部署在 11 个以上的全球区域以降低延迟。
• Knot2： 一个重写的基于 Rust 的服务器，捆绑了自定义 Git 服务器和 SSH 服务器，作为仓库的主要宿主。

协作对象 (COBs)

Tangled 引入了一种新的数据模型，其中 Issue、Pull Request、评论和反应直接作为协作对象 (COBs) 存储在 Git 仓库中。这些记录以 Git 对象链的形式存储，确保项目的元数据与源代码紧密关联。为了确保数据完整性并防止未经授权的修改，系统使用了 org.tangled.graph.attestation 记录，允许在 Knot 服务器和用户的个人数据服务器 (PDS) 之间进行双向验证。

组织与工作流更新

组织现在作为 AT Protocol 的一等公民得到支持。每个组织都会获得自己的 DID 和 handle，从而实现委托式的无密码访问管理。此外，该平台还彻底改进了其 Pull Request 流程，以支持 Git 和 Jujutsu 用户的堆叠式 PR (stacked PRs)，包括用于审查版本间变更的 interdiff 支持。

社区反馈与讨论

尽管社区对该项目的目标表示了热情，但早期反馈也指出了几个需要改进的领域和技术担忧：

• 用户体验挑战： 一些用户指出，虽然 UI 有所改进，但缺乏明确的“评论”按钮等标准交互，导致代码审查时产生困惑。
• 联邦可靠性： 一个普遍的担忧是自托管节点停机对可发现性的影响。与 ActivityPub（内容通常在实例间复制）不同，用户指出如果特定的“Knot”服务器离线，相关的代码或 Issue 可能会暂时无法访问。
• 技术障碍： 早期测试者报告了仓库克隆和路径验证方面的问题。此外，一些用户请求支持 SHA256 Git 仓库，并指出行业正在逐渐从 SHA1 过渡。

关于协议的选择，一些社区成员质疑为什么选择 AT Protocol 而不是 ActivityPub，尽管支持者认为现有的 AT Protocol 生态系统为社交和协作数据提供了坚实的基础。