GitHub宕机之后：代码托管的"去中心化"解法

「中心化系统总会崩溃，只有邮件、Git和IRC能经得住时间考验。」——Tangled团队这句话，放在GitHub频繁出事的2024年，格外刺耳。

全球90%的开源软件依赖单一平台，这不是技术选择，是风险累积。Tangled想做的，是用一套新协议让代码协作回归分布式本质。

一、代码协作的协议演进史

代码协作从来依赖两条线：传代码的协议，聊事情的协议。

第一代是邮件工作流：Git传代码，邮件沟通。补丁通过邮件列表飞来飞去，Linus Torvalds至今仍在用这套。

第二代是GitHub模式：Git传代码，GitHub网站承载全部社交功能——Issue、Pull Request、评论、Star。体验统一了，代价是数据锁死在一家平台。

第三代出现两个分支。ForgeFed项目尝试用ActivityPub（去中心化社交协议）替代GitHub的通信层；Tangled则押注AT协议，走另一条路。

二、Tangled的解法：Git+AT协议

Tangled的核心设计叫「knots」——分布式Git服务器节点。每个knot独立运行，但通过AT协议互相同步事件。

这意味着：你可以在自己的服务器上push代码，然后向另一个完全独立的服务器上的仓库发起Pull Request。跨站fork、跨站协作成为原生功能，不需要任何平台账号。

AT协议在这里的角色是「认证事件传输」：Issue状态变更、PR合并、协作者邀请、SSH公钥分发，这些元数据走AT；代码本身仍走Git，不碰。

社交功能也被纳入：事件时间线、关注关系、Star标记，即将上线的「vouch」（背书/担保）机制——这些让开源协作保持「有趣和社交」，同时数据归属清晰。

三、为什么是现在

GitHub的稳定性问题只是导火索。更深层的矛盾是：开源基础设施的「单点故障」风险被长期忽视。

微软收购GitHub后，政策变动、区域封禁、服务中断的频次在增加。对依赖GitHub Actions持续集成的团队来说，一次宕机意味着流水线全面停摆。

Tangled的邮件列表式体验，本质是把「平台风险」拆成「节点风险」。单个knot宕机不影响全网，就像单个邮件服务器崩溃不会杀死整个邮件系统。

四、未解决的硬问题

去中心化方案从来不缺理想，缺的是用户迁移成本。

GitHub的生态护城河包括：Actions工作流、Codespaces云端开发、Copilot代码补全、Issues与PR的深度集成。Tangled目前只解决「代码+基础协作」，高级功能空白。

另一个现实：邮件工作流从未真正死亡，但也从未成为主流。开发者用脚投票，选的从来不是「最正确」的技术，是「最省事」的体验。

Tangled团队自己也承认，目标是「让代码协作仍然有趣和社交」——这句话的潜台词是，去中心化不能等于用户体验降级。

五、协议战争的终局猜想

ForgeFed和Tangled代表了两种哲学。ActivityPub是W3C标准，生态更广但复杂度更高；AT协议由Bluesky团队设计，更轻量，但尚未经历大规模验证。

两者竞争的不只是技术实现，是「去中心化代码协作」的定义权。最终可能像Git本身一样——协议统一，实现多元；也可能像即时通讯一样，碎片化成孤岛。

对普通开发者来说，最务实的观察指标只有一个：有没有主流项目开始双轨运行——GitHub为主，knot为辅。这个信号出现时，才是范式转移的真正起点。

毕竟，IRC活了三十五年，不是因为比Slack好用，是因为总有人需要一条不需要注册、不会被封禁的后备通道。Tangled想做的，大概是Git世界的那个后备通道——平时没人想起，出事时救命。