GitLab 的 ActivityPub 架构蓝图

与 ForgeFed 及现有 forge 的关系

• 有些人惊讶于 GitLab 的蓝图没有提到 ForgeFed、Forgejo、Gitea 等一直在推进可互操作联邦的项目。
• 也有人指出 GitLab 的一个 epic 讨论表明他们知晓此事，并且很可能最终会支持 ForgeFed。
• 有人担心 GitLab 可能会构建一个以 GitLab 为中心的网络，但 epic 中一条相关评论显示，他们的目标是互操作性，而不是一种专有替代方案。
• 一点说明：epic 里那条与 ForgeFed 相关的评论来自社区贡献者，而不是 GitLab 员工。

电子邮件 + git vs web forge vs ActivityPub

• 一个主要讨论串在辩论 email+git（Linux 风格）与现代 forge（GitHub/GitLab 等）之间的优劣。
• 支持 forge 的论点：更丰富的 UX、CI 集成、更好的审查工具（行内评论、解决状态）、更好的可发现性、标签/标记，以及对社交约定的依赖更少。
• 支持 email 的论点：开放、联邦式标准；功能强大且可定制的客户端；良好的线程和讨论结构；不依赖任何单一 forge。
• 一些人说 email 工作流很痛苦、容易出错，而且难以扩展；另一些人则认为问题主要在于客户端太差以及缺乏工具支持。
• Linux 内核的 email 工作流被提到在规模扩大后难以应付，并且有人提及 kernel 工具（例如 lore、b4）试图弥补 email 的局限。

ActivityPub vs “直接用 email/git”

• 有些人希望工具本应建立在 email 之上，而不是发明新的协议栈。
• 也有人反驳说，一旦你构建了复杂的工具和元数据层，本质上就已经有了一个新协议，因此直接使用 ActivityPub/HTTP 更干净。
• ActivityPub 被认为可以为补丁/issue 提供结构化数据，避免 email 里临时拼凑的约定，以及 forge 之间定制化的 email 桥接。

去中心化、锁定效应与 GitHub

• 很多人对“代码领域的 fediverse”感到兴奋：可以在不同实例之间打开 issue/MR，而无需额外账户。
• 这被视为一种削弱 GitHub 网络效应锁定的方式，让项目能够迁移，同时保持协作开放。
• 但人们仍怀疑 GitHub 是否会实现 ActivityPub；大多数人认为，只有在强烈的竞争或监管压力下它才可能发生。

权限与隐私

• 在 GitLab 的蓝图中，联邦化私有资源被描述为非目标。
• 有人指出 ActivityPub 确实支持已认证请求，并且原则上可以处理跨实例权限。
• 隐私有限：没有端到端加密；实例管理员可以看到直接消息。