Tangled：跑在 AT Protocol 上的去中心化社交 Git 平台

Tangled（官网 tangled.org，源码 tangled.org/core，运营主体 Tangled Labs Oy）是一个仍标着 alpha 的去中心化代码托管与协作平台：用户用 AT Protocol 账号登录，代码可以放在自己的轻量服务器（knot）上，tangled.org 的 appview 只是汇聚全网的一个”视图”。它把 Jujutsu 堆叠 PR、信任背书（vouch）与 Nix/QEMU CI（spindle）打包在一起，主张”开发者拥有自己的代码、社区自治、编码重新变得社交且有趣”。本文基于官方文档、官方博客与源码仓库一手资料梳理。

一、背景：中心化 Forge 的三个痛点

GitHub 一类中心化代码 forge 把身份、仓库、评审、CI、社交关系都锁在同一服务商内：账号可被封、数据不可携带、涨价或改策略时用户没有议价权。去中心化方案此前有两条路线——ActivityPub 式联邦（如 Forgejo）与 Radicle 式纯 P2P。Tangled 文档自述其路线是”取两者之长”，采用为去中心化社交应用设计、带中心化身份（DID）的 AT Protocol（Bluesky 同一协议）：身份可携带，代码分布在各 knot，appview 负责聚合。

二、核心概念：PDS、knot 与 appview

• PDS（Personal Data Service）：账号提供方。已有 Bluesky 等 AT 账号可直接用原 handle 登录；在 Tangled 注册则分配 user.tngl.sh 形式的 handle。
• Knot：轻量、headless 的 Git 托管服务器，支持单租户或多租户，官方定位是”家用树莓派到大社区服务器都能跑”。默认提供免费托管 knot，也可自托管。
• Appview：tangled.org 本身是一个汇聚视图，让用户无缝访问克隆分布在不同 knot 上的仓库，并跨服务器提交 PR 与 issue。

三、技术机制：knot、spindle、堆叠 PR、信任网

3.1 Knot：Go 编写的自托管 Git 服务

按自托管文档，knot 主程序用 Go 构建（go build -o knot ./cmd/knot，需 CGO），核心子命令 knot server（主进程）、knot guard（SSH over Git 的基于角色访问控制）、knot keys（按 DID 拉取 SSH 公钥，经 sshd 的 AuthorizedKeysCommand 动态鉴权）。仓库与 SQLite 数据库默认落在 git 用户目录，前置 Nginx/Caddy 反代并经 /events 转发 WebSocket；官方提供 NixOS 模块，Docker 方案由社区维护（@tangled.org/knot-docker）。注册自己的 knot 时，服务器所有者 DID 写在环境变量里，最终在 PDS 上写一条记录宣告 knot 存在。

3.2 Spindle：Nix 与 microVM 双引擎 CI

CI 流水线叫 spindle，工作流 YAML 放在仓库根目录 .tangled/workflows/。触发条件 when 支持 push（branch/tag glob）、pull_request、manual、schedule（五段 cron + IANA 时区，支持 H 哈希错峰，离线期间的计划任务不补跑，最小间隔默认 5 分钟，并发默认 4）。引擎两种：

• nixery：经 Nixery 从 Nixpkgs 拉依赖；
• microvm（2026-06-16 博客发布）：每个工作流独占一个 QEMU microVM，可用 NixOS 镜像在 YAML 里直接声明服务（如 PostgreSQL 建库建用户）、开启 Docker-in-VM，也支持 Alpine 等非 NixOS 镜像；客户机里的 Rust 小 agent shuttle 启动后经 vsock 主动回连 spindle，以非特权用户执行步骤并回传 stdout/stderr 与退出码；依赖、服务与 Nix derivation 进入 Nix 缓存，第二次运行不必重建。官方注明当前只支持 QEMU，架构上预留了 firecracker 等 runner。

3.3 堆叠 PR 与 Jujutsu interdiff 评审

传统 GitHub 式评审被官方称为”diff-soup”：作者用追加提交回应 review，多次 force-push 后无法一眼看出”哪次修改回应了哪条意见”，还污染 git blame。Tangled 原生支持 Jujutsu（jj）的稳定 change-id：rebase 会改变 SHA 但 change-id 不变，因此可以把一串改动作为 stacked PRs 逐个提交（类似 Gerrit 的关系链），评审者看到的是两轮之间的 interdiff 而不是整团新 diff，并按轮次推进。

3.4 Vouch 信任网：对抗 LLM 垃圾贡献

2026-05-01 上线的 vouch/denounce 机制针对”LLM 让提交门槛降到极低、产出看似正确实则微妙错误的 uncanny valley 提交”。背书记录公开写在个人 PDS 上，appview 聚合后在 issue、PR 及评论处显示帽子图标：

官方明确的设计克制：可见性做了衰减（attenuation）——只能看到自己和自己圈子的决定；被 denounce 当前没有任何拦截后果，只是红色警示标签。作者规划中的后续是背书随时间衰减、以及把合并的 PR 作为背书证据链挂载。

四、关键数据与口径

口径偏差： 1.6k star 等计数是 Tangled 自己 forge 上的自报值，不在 GitHub 生态内，不能与 GitHub star 直接比较；“免费托管与 CI”是当前 alpha 期政策，官方未承诺永久免费。

五、官方承认的边界（nuance）

1. 迁移工具缺失：快速开始文档明确，目前没有迁移 GitHub/GitLab/Bitbucket 的 issue 与 PR 的工具，只能 git remote set-url 搬走提交历史、分支与标签，讨论数据留在原平台；
2. alpha 阶段：所有版本号带 alpha，功能与策略可能调整；
3. denounce 无强制力：被红标用户仍可提交，帽子只是信息提示，官方写明”后果未来可能改变，现在没有”；
4. CI runner 单一：microVM 当前只支持 QEMU，firecracker 等只是预留；
5. 计划任务不补跑：spindle 离线期间错过的 schedule 不会回放。

六、适用与不适用

适合： 认同 AT Protocol、希望账号与代码可携带的个人与小社区；已经在用 Jujutsu、想要原生 stacked PR/interdiff 的团队；想把 CI 跑在自己硬件上、接受 Nix 声明式环境的工程团队；需要对贡献者做圈子内信誉标记的开源维护者社群。

不适合： 要求把 GitHub issue/PR/CI 历史整体平移的团队（官方无迁移工具）；依赖成熟市场集成（第三方 SaaS、GitHub Actions 生态）的企业；需要封禁恶意用户等强治理能力的社区（denounce 目前仅标签）。

七、客观分析：优势与局限

优势：

1. 身份与数据可携带：AT 账号 + 自有 knot 从协议层避免厂商锁定，这是相对 GitHub 的根本差异；
2. 评审模型先进：change-id + interdiff + stacked PR 直击大 PR 评审痛点，比 range-diff 启发式匹配可靠；
3. CI 设计现代：microVM 隔离 + Nix 缓存 + vsock 回连，安全与复现性兼顾，且全组件可自托管；
4. 信任网克制落地：只做信号不做惩罚，避免了信誉系统常见的武器化问题。

局限：

1. 生态成熟度差距大：alpha、无迁移工具、第三方集成稀少，迁移惯性成本高（Koala 点评亦指出此点）；
2. 学习曲线叠加：AT Protocol + Jujutsu + Nix/microVM 三套新概念同时上手，门槛高于普通 forge；
3. 治理能力弱：denounce 不阻断、无封禁/限流的公开说明，社区自治规则尚未成型；
4. 热度集中在自报系统：缺少独立第三方采用度数据。

八、谁该关注

关注去中心化代码协作走向的开发者、Jujutsu 早期用户、以及希望把 CI 与代码托管都收归自有基础设施的小团队，值得把 Tangled 作为观察对象跟踪；企业级迁移则应等待正式版与迁移工具出现后再评估。

参考来源

• Tangled 官网
• Tangled 文档首页（协议定位与 knots 概念）
• Knot 自托管指南
• Spindles CI 文档
• 官方博客：Jujutsu on Tangled（堆叠 PR，2025-06-02）
• 官方博客：Combat LLM spam by building a web of trust（2026-05-01）
• 官方博客：Tangled CI runs on microVMs（2026-06-16）
• 源码仓库 tangled.org/core（MIT）
• Koala 项目库条目 1504：Tangled