We need a federation of forges

Original Article ↗ Hacker News Discussion ↗

Calls to reduce reliance on GitHub are reviving interest in “federated forges” — code hosting platforms that interoperate instead of centralizing projects, identities, and collaboration tools in one company’s hands. Commenters examine Tangled, a new VC‑funded git forge built on the AT Protocol, debating its technical merits (federated identity, issues and PRs, Jujutsu support) versus alternatives like ForgeFed, Radicle, mailing‑list workflows, and simply mirroring git repos. Many like the idea of shifting power away from single providers, but are skeptical about new protocols, spam and moderation challenges, cold‑start problems, and the long‑term incentives of venture-backed platforms.

Jujutsu / developer experience

  • Some praise jujutsu (jj) as a git-compatible VCS with lower cognitive load: unified “undo,” first-class conflicts, cheap branching, no separate stash/index.
  • Others find jj’s anonymous branches and revset syntax mentally heavy; feel it optimizes for people who “live in source control” rather than casual “snapshot” users.
  • Counterpoint: complex examples are cherry-picked; most daily use is simpler, and revsets are optional and aliasable.

Why federated forges if git is already distributed?

  • Many note git itself is decentralized; the missing piece is the “forge layer”: issues, PRs, reviews, CI, permissions, social graph, discoverability.
  • Federation is seen as protection against single points of failure, legal takedowns, policy changes, and outages on central forges.
  • Skeptics argue: mirroring repos and self-hosting CI/issue trackers is enough; “forge federation” may overcomplicate things and worsen spam.

Protocols: ATProto vs ActivityPub vs “just the web/email/git”

  • Strong debate on protocol choice:
    • ActivityPub likened to email-style server-to-server messaging; criticized for unclear federated auth/permissions and slow progress (ForgeFed).
    • ATProto framed as “web-shaped”: user-owned personal data servers (PDS) plus independent app views aggregating data; easier migration and cross-app reuse.
  • Some argue the open web, OAuth/IndieAuth, RSS/Atom, or git-over-email already cover most needs; others want richer, queryable, CRDT-friendly or actor-style data models.
  • Concerns raised about ATProto’s PQ-crypto readiness and potential future centralization around a few large providers.

Tangled-specific reactions

  • Enthusiasm:
    • Integrated with ATProto social graph: shared identity, “face to commits,” and unified login across apps.
    • Supports self-hosted git servers (“knots”) and CI runners (“spindles”) while sharing issues/PRs/comments via the network.
    • Perceived as simpler and more focused than GitHub, with features like static site hosting.
  • Skepticism:
    • VC funding (including crypto-focused) triggers fears of future “enshittification,” rug-pulls, license changes, or AI training on repos.
    • Lack of clear monetization plan and long-term governance worries some; calls for explicit business model and community safeguards.
    • Naming/jargon (“knot,” “tanglers”) and current lack of private repos put some off.

GitHub’s problems and competitive landscape

  • Multiple comments cite poor uptime, serious vulnerabilities, complex/fragile Actions security, and AI/Copilot focus while core reliability suffers.
  • Others note GitHub’s massive, AI-driven load growth makes scaling uniquely hard; doubt ideological alternatives can match its reliability at that scale.
  • Alternatives mentioned: Radicle (gossiping git), Forgejo/Codeberg (ActivityPub federation roadmap), SourceHut (email-based workflow), GitSocial (everything in git), fossil, and Nostr/GRASP-based git hosting.

Federation challenges and open questions

  • Spam and moderation seen as the hardest problem; suggestions range from web-of-trust to blocklists to “top-down” app views.
  • Cold start: users either join big servers (re-centralization) or small ones with no visibility. ATProto’s aggregation layer is proposed as one answer.
  • Some propose different direction entirely: richer git-native artifacts (fossil-style), or a standard, transport-agnostic SDLC API schema instead of protocol-level federation.