Gitlab's ActivityPub architecture blueprint
GitLab’s blueprint for adding ActivityPub-based federation to its platform is prompting debate over how software forges should interoperate and whether this will help break today’s GitHub-centric network effects. Commenters weigh the benefits of an open, federated model—where issues and merge requests can flow across GitLab, Gitea, Forgejo, and others—against existing workflows based on email patches or centralized web UIs. Questions center on standards alignment with efforts like ForgeFed, the practicality of permissions and privacy across instances, and whether major players such as GitHub are likely to adopt similar protocols.
Relation to ForgeFed and existing forges
- Some are surprised GitLab’s blueprint doesn’t mention ForgeFed, Forgejo, Gitea, etc., which have been working on interoperable federation.
- Others point to a GitLab epic discussion indicating awareness and likely eventual ForgeFed support.
- There is concern GitLab could build a GitLab-centric network, but a linked comment in the epic suggests they aim for interoperability, not a proprietary alternative.
- One note: the ForgeFed-related comment in the epic is from a community contributor, not GitLab staff.
Email + git vs web forges vs ActivityPub
- A major thread debates email+git (Linux-style) versus modern forges (GitHub/GitLab/etc.).
- Pro-forge arguments: richer UX, CI integration, better review tools (inline comments, resolutions), discoverability, labels/tags, and less reliance on social conventions.
- Pro-email arguments: open, federated standard; powerful, customizable clients; good threading and discussion structure; independence from any single forge.
- Several people say email workflows are painful, error-prone, and scale poorly; others say the pain is mostly bad clients and lack of tooling.
- Linux kernel’s email workflow is cited as struggling under scale, and there are references to kernel tooling (e.g. lore, b4) that try to patch over email’s limits.
ActivityPub vs “just use email/git”
- Some wish tooling had been built on top of email instead of inventing a new protocol stack.
- Others counter that once you build sophisticated tooling and metadata layers, you effectively have a new protocol anyway, so using ActivityPub/HTTP is cleaner.
- ActivityPub is seen as allowing structured data for patches/issues, avoiding ad-hoc email conventions and bespoke email bridges between forges.
Decentralization, lock-in, and GitHub
- Many are excited about “a fediverse for code”: being able to open issues/MRs across instances without extra accounts.
- This is viewed as a way to erode GitHub’s network-effect lock-in by letting projects move while keeping collaboration open.
- Skepticism remains about GitHub ever implementing ActivityPub; most think it would only happen under strong competitive or regulatory pressure.
Permissions and privacy
- Federation of private resources is described as a non-goal in GitLab’s blueprint.
- Some note ActivityPub does support authenticated requests and could, in principle, handle cross-instance permissions.
- Privacy is limited: no end-to-end encryption; instance admins can see direct messages.