Radicle: Autonome Code-Schmiede

 (radicle.xyz)
1 Punkte von GN⁺ 2026-01-25 | 1 Kommentare | Auf WhatsApp teilen
  • Radicle ist ein auf Git aufgebautes dezentrales Open-Source-Netzwerk für kollaborative Code-Arbeit, in dem Repositories ohne zentralen Server direkt zwischen Peers repliziert und verwaltet werden
  • Alle Daten und soziale Artefakte werden mit Public-Key-Kryptografie signiert, sodass Authentizität und Urheberschaft verifiziert werden können
  • Nutzer können ihren eigenen Node betreiben, um eine zensurresistente Kollaborationsumgebung aufrechtzuerhalten, und auch ohne Internetverbindung im Local-first-Modus arbeiten
  • Über Collaborative Objects (COBs) werden Funktionen wie Issues, Diskussionen und Code-Reviews als Git-Objekte umgesetzt, die Entwickler flexibel erweitern können
  • Die modulare Architektur aus CLI, Web und TUI macht die Plattform zu einer hochgradig erweiterbaren Code-Schmiede, für die sich unterschiedliche Clients entwickeln und austauschen lassen

Übersicht (Synopsis)

  • Radicle ist ein Peer-to-Peer-Stack für Code-Zusammenarbeit auf Git-Basis, der sich von zentralisierten Code-Hosting-Plattformen dadurch unterscheidet, dass es keine einzelne kontrollierende Instanz gibt
    • Repositories werden verteilt zwischen Peers repliziert, und Nutzer behalten die vollständige Kontrolle über ihre Daten und Workflows
  • Es wird als Open Source bereitgestellt und kann unter den Lizenzen MIT und Apache 2.0 frei genutzt werden
  • Das Haupt-Repository hat die Kennung rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

Installation und Einstieg

  • Die Installation ist in der Shell mit folgendem Befehl möglich:
    curl -sSLf https://radicle.xyz/install | sh
  • Alternativ kann direkt aus dem Quellcode gebaut werden
  • Derzeit läuft es nur unter Linux, macOS und BSD-Systemen
  • Mit dem Client Radicle Desktop steht auch eine grafische Kollaborationsumgebung zur Verfügung
Anzeige

Funktionsweise (How it works)

  • Ein kryptografisches Identitätssystem stellt die Integrität von Code und sozialen Daten sowie die Authentifizierung der Urheber sicher
  • Git wird für eine effiziente Datenübertragung zwischen Peers genutzt
  • Ein benutzerdefiniertes Gossip-Protokoll dient zum Austausch von Repository-Metadaten

Datensicherheit und Persistenz

  • Alle sozialen Artefakte werden in Git gespeichert und mit Public-Key-Kryptografie signiert
  • Radicle verifiziert automatisch die Authentizität der Daten und die Identität der Urheber

Autonomie und Zensurresistenz

  • Nutzer können ihren eigenen Node selbst betreiben und so eine Kollaborationsumgebung ohne Abhängigkeit von Dritten aufrechterhalten
  • Das Netzwerk ist als resiliente und zensurresistente Struktur konzipiert

Local-first

  • Es bietet jederzeit verfügbare Funktionen, auch ohne Internetverbindung
  • Nutzer besitzen ihre Daten selbst, und Verschieben, Backup und Zugriff sind unkompliziert
Anzeige

Erweiterbarkeit und Weiterentwicklung

  • Über Collaborative Objects (COBs) werden Funktionen wie Issues, Diskussionen und Code-Reviews als Git-Objekte umgesetzt
  • Entwickler können COBs erweitern, um neue Kollaborationsabläufe aufzubauen

Modulares Design (Modular by Design)

  • Der Radicle Stack besteht aus CLI, Web-Interface und TUI
    • Diese werden von Radicle Node und HTTP Daemon unterstützt
  • Jede Komponente ist austauschbar, und auch die Entwicklung anderer Clients ist möglich

Community und Mitwirkung

  • Radicle ist freie Open-Source-Software, zu der jeder Code beitragen kann
  • Die Community ist auf Zulip, Mastodon, Bluesky und Twitter aktiv
  • Feedback kann an feedback@radicle.xyz gesendet werden und wird automatisch im Zulip-Kanal #feedback veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-25
Hacker-News-Kommentare

  • Ich hatte den Eindruck, dass im Einleitungstext von Radicle nicht klar wird, worin genau der Unterschied zu self-hosted Git besteht
    Wenn es eine Alternative wie Gitea oder Forgejo ist, wäre es gut, kurz zu erklären, welche Funktionen über Git hinaus hinzukommen

    • Nach dem Lesen der Einführung wirkte es auf mich wie local-first Git für Teams
      Ich habe es als ein Werkzeug verstanden, mit dem man ohne das Chaos des Austauschs von E-Mail-Patches zusammenarbeiten kann
      Da ich Gitea oder Forgejo nicht kenne, helfen mir Vergleiche damit eher nicht
    • Ich finde die bisherige Zusammenfassung völlig ausreichend
      Dass Git im ersten Satz ausdrücklich erwähnt wird, macht es klar
      Die Landingpage von Forgejo vermeidet dagegen sogar die Erwähnung von Git oder Source Control und ist dadurch eher verwirrend
    • Radicle ist eine dezentrale Alternative zu GitHub
      Es bietet wie Forgejo/Gitea/GitLab die Möglichkeit zum lokalen Hosting, läuft aber auf einem P2P-Netzwerk, ist dadurch ausfallsicher und ermöglicht dezentrales Hosting öffentlicher Projekte
    • AD: Wir sind ein Open-Source-Projekt und freuen uns über Vorschläge oder Patches
      Es wäre gut, wenn du direkt einen Vorschlag machen könntest, wie man es besser formulieren sollte
    • Nach dem, was ich auf der Seite gesehen habe, wirkt es wie ein dezentralisiertes GitHub, auf dem Teams zusammenarbeiten können, ohne dass das Unternehmen Zugriff auf den Code haben muss

  • Ich freue mich über den Versuch, eine neue Social Forge zu bauen
    Schon dass solche Projekte Druck auf GitHub und GitLab ausüben, sich zu verbessern, ist wertvoll
    Laut FAQ versucht Radicle, das Vertrauensproblem in Git mit einem identitätsbasierten System auf PKI-Basis zu lösen
    Trotzdem bleibt am Ende die Frage bestehen, „wessen Identität man vertrauen soll“

    • AD: Jedes Repository wird über signierte Identitätsdokumente der Delegates verwaltet
      Derzeit gibt es eine 1:1-Zuordnung zu SSH-Schlüsseln, aber wir arbeiten an einer Erweiterung auf Gruppenidentitäten
      Das ist keine perfekte Lösung, bietet aber über kryptografische Identität eine Struktur, die sich „von etwas Vertrauen zu mehr Vertrauen“ erweitern lässt
      Letztlich wird Vertrauen wie zwischen Menschen über soziale Verbindungen verteilt
    • Vertrauen muss über andere Kanäle oder Code-Reviews aufgebaut werden
      Sobald Vertrauen entstanden ist, kann man nach anderen Repositories mit derselben DID suchen
      Wenn es mehrere Versionen gibt, wählt man einfach ein Repository aus einer vertrauenswürdigen Quelle oder mit aktiver Entwicklung

  • Durch den Umgang mit kleinen Sysadmin-Gruppen, die alte Internetdienste wie IRC oder Gopher betreiben, denke ich öfter über die Nicht-Löschbarkeit von P2P-Systemen nach
    Ich frage mich, was man tun soll, wenn man versehentlich personenbezogene Daten veröffentlicht oder Inhalte hochlädt, die später durch Gesetzesänderungen problematisch werden
    Es gibt auch gefährliche Situationen wie den Fall der festgenommenen Funkamateure in Belarus
    Das heißt nicht, dass P2P deshalb schlecht ist, aber das Löschproblem bleibt weiterhin schwer lösbar

    • Auch alte Usenet-Beiträge sind größtenteils bis heute erhalten
      Selbst auf GitHub ist es bei hochgeladenem Code mit geheimen Schlüsseln oft schon zu spät
      P2P schafft weniger ein neues Problem, sondern macht ein bestehendes nur sichtbar
    • Man muss die Realität anerkennen, dass veröffentlichte Inhalte faktisch dauerhaft sind
      Eine verzögerte Veröffentlichung, bei der man wie bei E-Mail die Veröffentlichung innerhalb einer bestimmten Frist zurückziehen kann, wäre sinnvoll
    • AD: Wir sind uns des Problems bewusst und arbeiten daran, die Standardeinstellungen sicherer zu machen
      Auf Netzwerkebene diskutieren wir auch eine Funktion zum Verwerfen von Inhalten
    • Auch zentralisierte Systeme sind nicht vollkommen sicher
      Betreiber können Löschungen manipulieren oder Inhalte an Regierungen melden
      Rechtliche Probleme hängen letztlich von der Fairness des politischen Systems ab
    • Auch bei zentralisierten Diensten können Inhalte heruntergeladen werden, daher ist vollständiges Löschen unmöglich

  • Frage nach dem Unterschied zu Tangled

    • Radicle hat eine local-first-Architektur, bei der Nutzer ihren eigenen Node selbst betreiben
      Alle Vorgänge wie Issues oder Patch-Reviews finden im lokalen Datenspeicher statt, ohne Server-Roundtrips
      Das Netzwerk greift nur beim Synchronisieren ein
      Tangled dagegen hat eine föderierte Struktur auf Basis des AT Protocol und hängt praktisch von zentralisierten Servern (AppView) ab
      Architektonisch ist es ein Client-Server-System
    • Tangled vermittelt über das AT Protocol zwischen mehreren Git-Servern („knots“)
      Bei Radicle gibt es kein Serverkonzept, alle Nodes sind gleichberechtigt
      Einige Nodes können höchstens zusätzlich als HTTP-Server laufen, um den Zugriff per Browser zu erleichtern

  • Laut FAQ kann bei Radicle jeder Node Missbrauch und illegale Inhalte nach eigener Richtlinie blockieren
    Außerdem werden private Repositories zwischen vertrauenswürdigen Peers unterstützt
    Die Daten sind nicht verschlüsselt, werden aber durch selektive Replikation nicht im gesamten Netzwerk offengelegt
    FAQ-Link

  • Ich finde, auf der Homepage sollte es ein Gateway geben, über das man auf einen Index öffentlicher Repositories zugreifen kann
    So könnte man das gesamte Netzwerk durchsuchen
    Mit einem solchen Index hätte es das Potenzial, GitHub zu ersetzen

    • Unter search.radicle.xyz kann man nach öffentlichen Repositories suchen
      Ich weiß nur nicht, ob von der Homepage aus ausdrücklich dorthin verlinkt wird

  • Radicle ist wirklich ein großartiges Projekt
    Ich betreibe seit einigen Monaten einen Node, nutze es aber noch nicht als Hauptsystem
    Ich glaube, dass eine P2P-Forge die Zukunft des Web ist

    • AD: Danke fürs Mitmachen, ich betreibe ebenfalls einen permissiven Seed-Node
      Schon die Teilnahme ist eine Stimme dafür
    • AD: Mich würde interessieren, warum du es noch nicht als Hauptsystem nutzt

  • Jedes Mal, wenn ein Projekt auf GitHub gesperrt wird, denke ich: „Dafür hätte man Radicle nutzen sollen“
    Wenn man einen Node hinter Tor betreibt, kann man sich auch rechtlichem Druck entziehen

    • Ich frage mich, ob man einen Node gleichzeitig in mehreren Netzwerken sichtbar machen kann (Tor, i2p, Clearnet, Yggdrasil usw.)
      Einige Projekte hatten in der Vergangenheit bei solchen Setups Probleme

  • Ich frage mich, wie ein permissiver Seeder gegen das Hochladen großer Binärdateien geschützt wird
    Wenn alle Issues und Diskussionen gespeichert werden, könnte das Repository sehr groß werden
    Es scheint eine Funktion für partielle Replikation zu brauchen, ähnlich wie shallow clone in Git

  • Frage nach dem Unterschied zu Forgejo (ForgeFed-Protokoll)

    • Radicle ist vollständig P2P-basiert, ohne Konzept von Servern oder Instanzen
      Jeder Node läuft mit demselben Prozess, und Benutzerkonten sind selbstzertifizierend
      Forgejo ist dagegen eine föderierte Struktur, bei der Server über ActivityPub miteinander kommunizieren
      Man kann es etwa so vergleichen: GitHub : Forgejo = Twitter : Mastodon, und Dateifreigabe : BitTorrent = Softwareentwicklung : Radicle
      Radicle verwaltet Referenzen nicht über einen zentralen Server, sondern über kryptografische Namespaces auf Projektebene
      Auch die Zugriffskontrolle basiert nicht auf Servern, sondern auf Benutzeridentitäten