We need a federation of forges

Original Article ↗ Hacker News Discussion ↗

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.