过去二十年间，代码托管平台充当了开发者协作的核心枢纽：负责代码存储、变更审核及社区连接。这种集中化模式以便利换取了对第三方基础设施的依赖，包括正常运行时间保障、功能迭代及代码管理质量。
然而，中心化架构正面临挑战。Git 协议用于移动代码，电子邮件作为开放协议用于讨论，二者虽经时间考验，但用户体验往往受限。Tangled 旨在结合开放协议的持久性与自主托管的灵活性。
用户可在自有服务器上托管代码，同时保持与其他开发者的协作能力。其策略强调实用主义：自主托管 Git 仓库或 CI 运行器等组件，无论选择何种基础设施，均可通过标准协议与他人通信。
拥有基础设施控制权意味着可根据需求进行攻击面测试、扩展及定制。由于 Tangled 基于 AT 协议构建，开发者可创建自定义扩展、订阅数据流（Firehose），甚至编写完全定制的节点。例如，参考 mitchellh.com/tack 的案例，用户可利用轻量级 API 服务器构建专属的开发工厂。
代理工具（Agents）已使高度个性化软件的开发变得简单，Tangled 对此类工具具有良好兼容性。尽管软件工程未来形态尚不确定，但对开放协议和开发者自主权的坚持确保了平台的适应性。
界面重构
伴随本次发布，Tangled 采用了全新视觉设计。前端架构迁移至 Svelte，提升了加载速度与清晰度。字体方面，已从 Inter 更换为 Sans-serif 家族中的特定无衬线字体。
全球性能优化
此前，Tangled 的前端与后端由名为 appview 的单一 Go 单体应用承载，处理 AT 协议索引、缓存、非协议数据及 UI 渲染（使用 html/template + htmx）。该服务部署于瑞典中型服务器，依托 SQLite 数据库。对于远离瑞典的用户而言，50-100 毫秒以上的延迟影响了体验。
为解决此问题，团队开发了基于 Svelte 的新独立前端应用，并部署于边缘网络。后端核心替换为 Rust 编写的无磁盘、全内存索引服务 bobbin。Bobbin 在全球 11 个区域部署，确保各地用户获得优化的 API 响应与 UI 性能。
值得注意的是，bobbin 仅处理只读的 AT 协议数据。其余功能已拆分至新的支持服务集群。
数据模型革新与仓库所有权
数据模型经历重大调整，所有记录类型现统一在 org.tangled* 命名空间下，取代旧的 sh.tangled* 格式。
新组件 Knot2 采用 Rust 重写，提供自定义 Git 服务器及 SSH 服务器支持。随着 Knot2 引入，数据存储位置发生变更：Issue、Pull Request、评论、反应及标签均存储于 Knot 节点上。Commit 对象链仍保留在仓库本身，协作者、成员列表及屏蔽列表同样如此。
在此架构下，Knot 节点类似个人数据服务器（PDS）：持有签名记录及完整历史，涵盖仓库相关的所有数据，并通过标准 AT 协议 Firehose 同步。
这一设计将项目元数据视为代码的一部分，增强了项目的可移植性，使其不受托管位置限制。
为防止节点篡改用户言论，系统引入证书机制。每当用户在节点创建或编辑记录时，Web 应用会向用户的 PDS 写入一条 org.tangled.graph.attestation 记录，实现双向验证。
自主托管用户需遵循升级指南，将节点更新至 v1.20.0 版本。
组织账户功能
Tangled 现已支持组织账户。每个组织均为独立的 AT 协议账户，拥有专属 DID 和处理程序，托管于静默 PDS 实例。用户可通过新页面创建组织，获得
所有者可邀请成员加入，组织内任何成员均可代表组织创建或 Fork 仓库。如同个人账户，组织账户也可绑定自有域名。对于曾以个人账户模拟组织行为的用户，官方正在制定迁移方案。
Pull Request 流程改进
Pull Request 工作流经过全面重构。无论使用 Jujutsu (JJ) 还是 Git，用户均可提交和审查堆叠式 PR。Git 用户现支持版本间差异对比（原称为轮次/Rounds），JJ 用户则可在个人更改（Change）之间切换视图。
后续发布计划
本次发布并非终点。未来几周将陆续推出私有仓库支持、命令行接口（CLI）、多语言 SDK 以及针对代理的技能包。
