Radicle: The Sovereign Forge

Original Article ↗ Hacker News Discussion ↗

Architecture & Core Concepts

  • Radicle is a peer-to-peer, local‑first code collaboration stack built on Git.
  • Every user runs a node; there is no server/client distinction—“seed” nodes are just nodes with permissive seeding policies.
  • Nodes only store/seed what their policies allow; by default you only seed what you explicitly choose, not arbitrary network content.
  • Issues, discussions, and reviews are modeled as “collaborative objects” stored as signed Git objects that replicate with the repo.

Collaboration Model & UX

  • “Pull requests” are represented as “patches”: a namespace-based mechanism where your cloned fork becomes your personal Git namespace.
  • Some find the term “patches” confusing vs Git’s single-commit patches, and suggest “patchsets”.
  • Collaborative objects are implemented as CRDTs, so non-code artifacts converge automatically; source code conflicts are still resolved manually like normal Git.
  • There’s interest in better UI for reviewing patches and in extending the web app from read-only to multi-user write, without server-side key custody.

Performance, Sync & Networking

  • Contributors report very low convergence times on well-seeded repos (sub-second to a few seconds across many nodes).
  • Users can check replication with rad sync status, configure how many nodes must acknowledge a sync, and define especially important peers.
  • Works over IPv6, Tor, Yggdrasil, and clearnet; multi-network setups are possible with appropriate routing.
  • Offline and air-gapped transfer is possible by copying Git storage or using git bundle, though UX is manual.

Moderation, Abuse & “Forgetting”

  • Each node decides what to seed; permissive seeders can be selective or block abusive repos/peers.
  • Private repos are supported via selective replication (not encryption at rest).
  • “Forgetting” and revocation are recognized as hard problems; planned approach is cooperative deletion signals plus safer defaults, but true erasure can’t be guaranteed in a P2P or even centralized world.
  • There is interest in integrating secret scanners to prevent accidental credential pushes.

Trust, Identity & Discovery

  • Repos are governed by identity documents signed by delegate keys (currently SSH-style keys).
  • Radicle doesn’t solve “who to trust” from zero; it aims to make continued trust in known identities stable.
  • Discussion notes parallels with PGP/Web-of-Trust vs PKI: users may still fall back to TOFU and social signaling.
  • Public repo discovery is available via a search gateway, though some want a more prominent, global index.

Comparisons & Ecosystem

  • Versus Tangled: Radicle is fully P2P/local-first; Tangled is built on AT Protocol with client–server “knots” and a central AppView.
  • Versus Forgejo/ActivityPub: Forgejo federates servers; Radicle has no servers or user databases—identities are self-certifying.
  • Some see Radicle as a P2P GitHub/forge; others stress it is “just Git” compatible, with HTTP bridges and mirroring to GitHub/sourcehut via normal remotes.
  • CI exists via an event socket and external brokers; early adopters have custom integrations.

Funding & Governance

  • Radicle is governed by a Swiss non-profit foundation and funded by a separate crypto-oriented organization, but the current protocol is blockchain‑free and usable without any tokens.
  • Debate centers on sustainability of “non-monetizable” P2P forges vs trust risks from VC/crypto funding; proponents frame Radicle as a free software project that can survive on donations and institutional support.