Radicle: Eine Peer-to-Peer-Alternative zu GitHub auf Open-Source-Basis

Radicle-Heartwood-Protokoll & -Stack

• Radicle Heartwood ist die dritte Version des Radicle-Protokolls, eines Stacks für Peer-to-Peer-Code-Zusammenarbeit und -Publishing.
• Dieses Repository enthält die vollständige Implementierung von Heartwood, einschließlich der benutzerfreundlichen Kommandozeilenoberfläche (rad) und des Netzwerk-Daemons (radicle-node).
• Radicle wurde als sichere, verteilte und robuste Alternative entwickelt, um Code-Schmieden wie GitHub und GitLab zu ersetzen und dabei die Souveränität und Freiheit der Nutzer zu bewahren.

Installationsvoraussetzungen

• Linux oder ein Unix-basiertes Betriebssystem ist erforderlich.
• Git 2.34 oder höher ist erforderlich.
• OpenSSH 9.1 oder höher sowie ssh-agent sind erforderlich.

Installation aus Binärdateien

• curl und tar sind erforderlich.
• Um die neueste Binär-Release zu installieren, den folgenden Befehl ausführen: sh <(curl -sSf https://radicle.xyz/install)

Installation aus dem Quellcode

• Die Rust-Toolchain ist erforderlich.
• Innerhalb dieses Repositories kann der Radicle-Stack mit den folgenden Befehlen aus dem Quellcode installiert werden: cargo install --path radicle-cli --force --locked cargo install --path radicle-node --force --locked cargo install --path radicle-remote-helper --force --locked
• Alternativ ist auch eine Installation direkt von einem Seed-Node möglich: cargo install --force --locked --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \ radicle-cli radicle-node radicle-remote-helper

Ausführung

• Systemd-Unit-Dateien für den System-Daemon und den HTTP-Daemon werden im Ordner /systemd bereitgestellt. Sie können als Ausgangspunkt für weitere Anpassungen dienen.
• Außerdem enthalten beide Crates jeweils ein Dockerfile.
• Informationen zum Ausführen im Debug-Modus finden sich in HACKING.md.

Mitwirken

• Eine Einführung dazu, wie man zu Radicle beiträgt, findet sich in CONTRIBUTING.md und HACKING.md.

Lizenz

• Radicle wird unter den Bedingungen der MIT-Lizenz und der Apache License (Version 2.0) vertrieben.
• Weitere Details finden sich in LICENSE-APACHE und LICENSE-MIT.

Meinung von GN⁺

• Radicle ist eine dezentrale Plattform für kollaborative Codearbeit als Alternative zu zentralisierten Code-Hosting-Diensten und soll die Code-Souveränität der Nutzer stärken. Das ist besonders wertvoll, weil Entwickler dadurch Kontrolle über Dateneigentum und Privatsphäre erhalten.
• Das von Radicle bereitgestellte dezentrale Netzwerk ist nicht auf einen zentralen Server angewiesen und bietet dadurch den Vorteil, frei von Ausfällen einzelner Dienste oder Zensur zu sein. Gleichzeitig kann sich dies auf Stabilität und Geschwindigkeit des Netzwerks auswirken und damit die Nutzererfahrung negativ beeinflussen.
• Radicle ist ein Open-Source-Projekt, das sich durch Beiträge der Entwickler-Community kontinuierlich weiterentwickelt. Das bringt den Vorteil mit sich, dass auf technische Probleme oder neue Funktionswünsche schnell reagiert werden kann.
• Vor der Einführung von Radicle sollten die Kompatibilität mit bestehenden zentralisierten Diensten, die Sicherheitsanforderungen des Projekts sowie Hürden bei der Einführung im Team berücksichtigt werden.
• Andere Projekte mit ähnlichem Funktionsumfang sind etwa selbst gehostete Versionen von GitLab oder Open-Source-Alternativen wie Gitea, die es Nutzern ermöglichen, ihren Code auf dem eigenen Server zu verwalten.

[GN⁺]

Hacker-News-Kommentare

• Ein Grußwort eines Mitbegründers des Projekts mit einem Link zu einer Erklärung, wie das Protokoll funktioniert. Die Dokumentation ist noch in Arbeit.

  Hallo Hacker News, ich bin Mitbegründer dieses Projekts. Wenn ihr wissen wollt, wie das Protokoll intern funktioniert, fangt hier an: Radicle-Dokumentation. Die Dokumentation ist allerdings noch in Arbeit.

• Es wirkt gut für den Zweck des Projekts geeignet, aber git selbst ist bereits Open Source und P2P. Man kann sich ohne zusätzliche Binärdateien mit anderen Servern verbinden und Code direkt abrufen oder mergen. Was git fehlt, sind Code-Issues, Wiki, Diskussionen, GitHub Pages und vor allem ein Netzwerk von Entwicklerprofilen. Es braucht eine Möglichkeit, Projektmetadaten in .git selbst aufzunehmen, und möglicherweise separate Referenzen, um Wiki und Issues nicht zu vermischen.

  Dieses Projekt scheint gut auf seinen Zweck zugeschnitten zu sein, aber git selbst ist bereits Open Source und P2P. Ohne zusätzliche Binärdateien zu installieren, kann man sich mit anderen git-Servern verbinden und mit git-Befehlen Code direkt abrufen oder mergen. Was git fehlt, sind Code-Issues, Wiki, Diskussionen, GitHub Pages und vor allem ein Netzwerk von Entwicklerprofilen. Es braucht eine Möglichkeit, Projektmetadaten in .git einzubetten. Wahrscheinlich wären dafür unabhängige Referenzen wie git notes nötig. git-notes-Dokumentation

• Es ist sehr interessant, die Entwicklung von Radicle zu beobachten. Nach der Teilnahme an einem Workshop auf der Protocol Berg 2023 wirkt es so, als hätten sie etwas sehr Mächtiges und Neues aufgebaut. Besonders spannend ist, dass auch die kollaborative Seite des Protokolls lokal zuerst gedacht ist. Man kann Patches und Issues auch ohne Internet einreichen, und Teams sind nicht betroffen, wenn es bei GitHub Probleme gibt.

  Es war sehr spannend, die Entwicklung von Radicle in den letzten fünf Jahren zu verfolgen. Ich habe an dem Workshop auf der Protocol Berg 2023 teilgenommen und denke, dass sie etwas sehr Mächtiges und Neues aufgebaut haben. Besonders faszinierend ist, dass auch die kollaborative Seite des Protokolls nach dem Local-first-Prinzip entworfen wurde, sodass man selbst ohne Internet Patches und Issues einreichen kann und Teams nicht betroffen sind, wenn GitHub Probleme hat.

• Es gibt die Frage, warum sowohl die MIT- als auch die Apache-Lizenz verwendet werden. Ob die MIT-Lizenz nicht zusätzliche Verpflichtungen der Apache-Lizenz umgehen lässt, insbesondere die Klausel zur Patentlizenzgewährung. Da die MIT-Lizenz Patente nicht erwähnt, stellt sich die Frage, warum man dann nicht nur die MIT-Lizenz nutzt.

  Ich frage mich, warum sowohl die MIT- als auch die Apache-Lizenz verwendet werden. Das ist keine Kritik, und vielleicht liege ich falsch, aber erlaubt die MIT-Lizenz nicht, die zusätzlichen Verpflichtungen der Apache-Lizenz zu umgehen? Insbesondere die Klausel zur Gewährung von Patentlizenzen. Die MIT-Lizenz erwähnt Patente nicht, daher frage ich mich, warum man dann nicht einfach nur die MIT-Lizenz verwendet.

• Es gibt Zweifel, wie leicht normale Nutzer solche Repositories finden können. Es scheint keine robots.txt zu geben, daher müssten Suchmaschinen sie crawlen können. In Google und DDG tauchen zwar Ergebnisse auf, aber noch nicht weit oben. Das könnte sich verbessern. Ein integriertes Tool für CI-Unterstützung wäre ebenfalls interessant. Außerdem braucht es bessere Werkzeuge, um Pushes auf vertrauenswürdige Identitäten beschränken zu können. Abschließend wird ein Artefakt-Repository erwähnt. Radicle muss nicht alles lösen, vor allem weil das Teilen großer Binärdateien über ein verteiltes Netzwerk schnell zweckentfremdet werden könnte.

  Ich frage mich, wie leicht diese Repositories für normale Nutzer auffindbar sind. Es scheint keine robots.txt-Datei zu geben, also sollten Suchmaschinen sie crawlen können, und tatsächlich erscheinen bei Google und DDG Suchergebnisse. Sie stehen noch nicht weit oben, aber ohne Site-Filter könnte sich das Ranking verbessern. Ein Tool zur Integration von CI-Unterstützung wäre ebenfalls interessant. Es braucht bessere Werkzeuge, um Pushes auf solche von vertrauenswürdigen Identitäten zu beschränken. Und schließlich noch ein Hinweis auf ein Artefakt-Repository: Radicle muss nicht alles lösen. Gerade das Teilen großer Binärdateien über ein verteiltes Netzwerk könnte schnell für unerwünschte Zwecke missbraucht werden.

• Glückwünsche zum Release sowie Begeisterung darüber, das Projekt über längere Zeit begleitet und reifer werden gesehen zu haben. Außerdem die Frage, wie Projekte von GitHub migriert werden und ob es während des Testens einen Mirror-Modus gibt.

  Glückwunsch zum Release! Es ist wirklich spannend, dieses Projekt zu verfolgen und zu sehen, wie stark es gereift ist. Wie lassen sich bestehende Projekte auf GitHub derzeit migrieren? Gibt es während des Testens einen Mirror-Modus?

• In der Dokumentation steht, dass man nur Repositories veröffentlichen sollte, die einem selbst gehören oder die man verwaltet, und dass man sich mit anderen Administratoren abstimmen soll, um keine doppelten Repository-Identitäten zu initialisieren. Allerdings ist es wahrscheinlich, dass Leute die Doku nicht lesen oder nicht darauf achten und solche Hinweise ignorieren. Auf der Startseite wird erklärt, wie man Code pusht, aber dieser wichtige Hinweis steht nur im Benutzerhandbuch, was problematisch sein könnte.

  In der Dokumentation wird erwähnt, dass man nur Repositories veröffentlichen sollte, die einem gehören oder die man verwaltet, und dass man mit anderen Administratoren kommunizieren soll, damit keine doppelten Repository-Identitäten initialisiert werden. Aber wahrscheinlich lesen Leute die Dokumentation nicht oder achten nicht darauf und ignorieren solche Aufforderungen. Auf der Homepage wird erklärt, wie man Code pusht, aber dieser wichtige Hinweis ist nur im Benutzerhandbuch zu finden, was problematisch sein könnte.

• Es gibt den Wunsch nach einer genauen Definition von Begriffen wie "peer to peer" oder "distributed". Solche Begriffe können sehr vage werden, wenn sie als Buzzwords verwendet werden.

  Ich wünschte, die Leute würden Begriffe wie "peer to peer" oder häufiger "distributed" genauer definieren. Diese Begriffe können sehr vage werden, wenn sie als Buzzwords benutzt werden.

• Glückwünsche zum Release, verbunden mit der Erinnerung an ein ähnliches Projekt, das statt git pijul verwendet: nest.pijul.com.

  Glückwunsch zum Release! Das erinnert mich an ein ähnliches Projekt, nest.pijul.com, das statt git pijul verwendet.

• Eine themenfremde Bemerkung, die an NESticle erinnert.

  Off-topic: Das erinnert mich an NESticle. NESticle-Wiki