Gleam 现已上线 Tangled

原文 ↗ Hacker News 讨论 ↗

Gleam 编程语言在 Tangled 上出现了一个新的镜像；Tangled 是一个由风投支持、基于 ATProto 的 Git 托管平台，这引发了围绕 GitHub 去中心化替代方案的讨论。评论者权衡了 Tangled 对联邦、自托管、基于 Nix 的 CI 以及存储与身份分离的承诺，与其当前短板之间的差距，包括功能缺失、令人困惑的注册流程、漏洞，以及对类似 Bluesky 的身份验证的依赖。这场交流凸显了关于可持续性、商业模式，以及社交化、联邦式代码托管平台是否真能匹配 GitHub 生态和可靠性的更广泛问题。

Tangled 是什么以及它如何工作

  • 被描述为一个建立在 ATProto（与 Bluesky 相同的协议）之上的去中心化 GitHub 类代码托管平台。
  • 将 git 存储（“knots”）与身份和社交数据（ATProto PDS）分离。
  • Gleam 仓库现在已镜像到那里；项目仍保留在 GitHub 上。

联邦、身份与自托管

  • Tangled 可跨多个实例联邦；用户可以运行自己的 knots、CI 运行器（“spindles”）以及 appviews（“bobbin”）。
  • 一些评论者起初认为它不能自托管；另一些人则指出博客文章和第三方部署证明它可以。
  • ATProto 负责身份；用户可以自托管 PDS，并不严格依赖 Bluesky 或 Tangled 的基础设施。

与其他代码托管平台相比的功能集

  • 与 Codeberg/Forgejo/Gitea 相比：Tangled 更新，缺少私有仓库和受保护分支，但有一些人更喜欢其 UI。
  • 与 Radicle 相比：Radicle 更专注于协议/数据；Tangled 更专注于开源社区的社交/身份。
  • 提到的独特功能包括：联邦、原生堆叠式 PR，以及 vouching 系统。

CI 与 Nix 优先设计

  • CI 基于 Nix 和 microVM；“spindles” 通过可插拔引擎运行流水线。
  • Bridge 引擎可以与其他 CI 系统集成，但有人指出更深度的 UI 集成（例如在 MR 中显示测试报告）仍然缺失。

Issues/PR 的数据模型争议

  • 当前/早期设计将 issue 和 PR 评论绑定到评论者的 PDS，而不是仓库本身，这被一些人视为“根本性缺陷”。
  • 维护者表示这一点正在重设计：issues/PR 将通过协作对象（“COB”）系统归属于仓库。

用户体验与稳定性

  • 多人反馈注册/登录流程有摩擦、ATProto handle 格式令人困惑、密码管理器有问题；也有人直接遇到注册错误。
  • 有关于新建仓库出现短暂 404，以及网络问题（仅 IPv6 的 knots 需要 IPv4/NAT 变通方案）的报告。
  • 也有人表示使用现有 Bluesky handle 登录很顺畅。

融资、商业模式与信任

  • Tangled 由风投支持，种子轮规模可观；一些人担心缺乏清晰商业模式，以及对托管仓库代码进行训练的可能性。
  • 猜测的变现路径包括：托管、CI、二进制缓存、PDS 托管和 SLA 的付费层。
  • 有人认为风投融资“无关紧要”，因为一切都是开源且可自托管；批评者则认为它仍会塑造激励。

对 Bluesky/ATProto 的依赖与审核

  • 担忧点：如果 Bluesky 审核/封禁某个账号，用户可能会失去对其代码/身份的访问。
  • 反驳观点：
    • 审核标签通常不会阻止登录。
    • 用户可以迁移到其他 PDS 或自托管；身份由 DID 和 PDS 控制，而不只由 Bluesky 控制。
    • 除非 PDS 本身删除账号，否则 Tangled 的审核独立于 Bluesky 的审核。
  • 但也有人仍认为，把源代码管理绑定到社交登录提供方，对“任务关键型”用途来说很危险。

认知、命名与背景

  • 许多不了解 “Gleam” 和 “Tangled” 的读者觉得标题晦涩，甚至像是讽刺。
  • 也有人回应说 HN 读者可以点进去或搜索；页面和之前的帖子提供了背景。
  • 整体情绪复杂：对联邦/ATProto 既有好奇和兴奋，也有对复杂性、流行术语以及现实可靠性的怀疑。