- Radicle Heartwood ist die dritte Implementierung des Radicle Protocol und bietet einen Peer-to-Peer-Stack für kollaborative Code-Arbeit und Veröffentlichung ohne zentrale Code Forge
- Das Repository enthält das von Entwicklern direkt verwendete Kommandozeilen-Tool
rad sowie den Netzwerk-Daemon radicle-node
- Es ist als Ersatz für Code Forges wie GitHub und GitLab konzipiert und verfolgt Sicherheit und Dezentralisierung sowie den Erhalt von Nutzersouveränität als Kernziele
- Die Installationsumgebung erfordert Linux oder ein Unix-artiges Betriebssystem, Git 2.34 oder höher sowie OpenSSH 9.1 oder höher einschließlich
ssh-agent
- Sowohl die Installation per Binärdatei als auch aus dem Rust-Quellcode wird unterstützt, aber Feedback-E-Mails werden automatisch im öffentlichen Zulip-Kanal veröffentlicht, wodurch Name und E-Mail-Adresse offengelegt werden können
Was Radicle Heartwood bietet
- Heartwood ist die dritte Iteration des Radicle Protocol und ein vollständiger Stack für Peer-to-Peer-Code-Zusammenarbeit und Veröffentlichung
- Das Repository enthält die Hauptkomponenten, die für die Heartwood-Implementierung benötigt werden
rad: benutzerfreundliche Kommandozeilenoberflächeradicle-node: Netzwerk-Daemon
- Radicle wurde als Alternative zu Code Forges wie GitHub und GitLab entwickelt
- Ziel sind Sicherheit, Dezentralisierung sowie der Erhalt von Nutzersouveränität und Freiheit
- Allgemeine Informationen gibt es auf der Radicle home page
- Projektgespräche sind im Zulip chat möglich
- Wie Radicle funktioniert, ist im Protocol Guide ausführlich beschrieben
Installation und Ausführung
- Die Installationsanforderungen sind wie folgt
- Linux oder ein Unix-basiertes Betriebssystem
-
Git 2.34 oder höher
- OpenSSH 9.1 oder höher einschließlich
ssh-agent
- Für die Binärinstallation werden
curl und tar benötigt; die neueste Release wird mit folgendem Befehl installiert
curl -sSf https://radicle.dev/install | sh
- Binärdateien können auch auf der Seite [download](https://radicle.dev/download) heruntergeladen werden
- Für die Installation aus dem Quellcode wird die **Rust-Toolchain** benötigt; im Repository werden dazu die folgenden Befehle ausgeführt
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
- Die Installation direkt von einem Seed-Node ist ebenfalls möglich
cargo install --force --locked --root ~/.radicle \
--git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
- Die **systemd-Unit**-Dateien für den Node befinden sich im Ordner `/systemd` und können als Ausgangspunkt für weitere Anpassungen dienen
- Für die Ausführung im Debug-Modus siehe [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md)
Feedback, Beiträge, Lizenz
- Feedback kann über
rad issue, Zulip oder an feedback@radicle.dev gesendet werden
- Per E-Mail gesendetes Feedback wird automatisch im öffentlichen #feedback-Kanal von Zulip veröffentlicht
- Während der Veröffentlichung wird der
From-Header offengelegt, der in der Regel Name und E-Mail-Adresse enthält
- Hinweise zum Beitragen finden sich in CONTRIBUTING.md und HACKING.md
- Radicle wird unter den Bedingungen der MIT-Lizenz und der Apache License 2.0 vertrieben
- Details finden sich in LICENSE-APACHE und LICENSE-MIT
1 Kommentare
Hacker-News-Meinungen
Ich bin Mitgründer von Radicle. Wer wissen will, wie das Protokoll intern funktioniert, sollte zuerst die Dokumentation lesen: https://docs.radicle.xyz/
Die Dokumentation ist noch in Arbeit.
Wenn es im Kern eine P2P-Filesharing-App ist, frage ich mich, in welchem Teil des Protokolls Missbrauch behandelt wird. Sonst sehe ich nicht, worin der Unterschied zu früheren Filesharing-Apps wie BitTorrent oder Winny besteht, mit denen urheberrechtlich geschützte Inhalte wie Filme, Musik oder Software beliebig geteilt wurden. Ein paar böswillige Nutzer könnten das Ganze ruinieren; außerdem frage ich mich, ob man „private“ Netzwerke abtrennen kann, damit man sicher sein kann, an nichts Illegalem beteiligt zu sein.
Auf Crunchbase steht, dass 12 Millionen Dollar investiert wurden, also wird es vermutlich einen Monetarisierungsplan geben.
Bei der Art von Projekten, bei denen ich helfe, könnte das ein K.-o.-Kriterium sein. Der Code scheint in Rust geschrieben zu sein; ich frage mich, ob MS-Windows-Support geplant ist. Mac OS zählt doch wohl als Unix-artig, oder? Selbst wenn es keinen offiziellen Windows-Support gibt: Wäre ein MSYS2-Port möglich?
Als Hintergrund: Ich bin nicht in einer Position, Entscheidungen wie die Auswahl von Dienstleistern zu treffen, habe aber mit einer quasi staatlichen Organisation zu tun, die eine beträchtliche Open-Source-Codebasis auf GitHub liegen hat. Gelegentlich habe ich die Möglichkeit, bestimmte Ideen vorzuschlagen, aber ob sie übernommen werden, liegt nicht in meiner Hand. Diese Organisation ist stark motiviert, Resilienz gegenüber den Richtlinien privater Anbieter aufzubauen und auch „gute Dinge“ wie Nachhaltigkeit oder breite Zugänglichkeit zu fördern. Als typische europäische Regierungsorganisation steht GitHub mit solchen Richtlinien im Konflikt.
Es gibt auch andere Behörden, die Archivierung oder Netzwerkunterstützung übernehmen, aber ihnen fehlt die Kompetenz oder sie arbeiten noch nach alten Mustern und tappen häufig in Fallen, die Anbieter aufgestellt haben. Zum Beispiel hat ein Archivierungsdienst DataBricks vollständig übernommen, ohne zu wissen, dass es ein kommerzielles Closed-Source-Produkt ist. Deshalb erwarte ich eher nicht, dass diese Organisation Self-Hosting-Lösungen gut nutzen wird; eine dezentrale Lösung wirkt attraktiver. Ein Werkzeug, das auf den wichtigsten PC-Umgebungen der breiten Öffentlichkeit nicht läuft, können wir jedoch nicht verwenden.
Außerdem würde mich interessieren, welches Maß an Adoption ihr früher bzw. heute erwartet habt und ob die tatsächlichen Ergebnisse diesen Erwartungen entsprochen haben.
Es war interessant zu beobachten, wie sich Radicle in den letzten etwa fünf Jahren entwickelt hat. Ich habe am Workshop auf der Protocol Berg 2023 teilgenommen und denke, dass sie etwas ziemlich Leistungsfähiges und Neues gebaut haben.
Besonders spannend ist, dass selbst die Kollaborationsfunktionen local-first sind. Man kann Patches und Issues auch ohne Internet einreichen, und nicht jedes Mal, wenn GitHub Probleme hat, muss das ganze Team auf HN herumhängen.
Für seinen Zweck wirkt es wie ein gutes Projekt, aber ich denke, Git selbst ist bereits Open Source und P2P. Man muss Binaries nicht per
sh <(curl)beziehen; man kann sich mit einem anderen Git-Server verbinden und den Code direkt mit Git-Befehlen holen oder mergen.Was Git fehlt, sind Code-Issues, Wikis, Diskussionen, GitHub Pages und vor allem ein Netzwerk von Entwicklerprofilen. Es braucht eine Möglichkeit, Projektmetadaten in
.gitselbst abzulegen, ohne dass Quellcode-Commits mit Wikis oder Issues vermischt werden. Unabhängige Referenzen wiegit noteskönnten dafür vielleicht funktionieren.https://git-scm.com/docs/git-notes
Zum Beispiel gibt es keine Möglichkeit zu verifizieren, dass ein mit
git cloneerhaltenes Repository tatsächlich das Repository ist, das ich angefordert habe. Deshalb muss man von einer vertrauenswürdigen Quelle klonen, also von einem bekannten Server. Das passt nicht zu praktikablem P2P.Radicle löst dieses Problem, indem es stabile Repository-Identifier[0] vergibt, die lokal verifizierbar sind, und ermöglicht so, dass nicht vertrauenswürdige Akteure ein Repository bereitstellen können.
[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
Auf Mobilgeräten kann man über die Buttons am unteren Rand des Originallinks Tabs für Issue-Tracking, Pull Requests usw. sehen.
Soweit ich mich erinnere, hat Gerrit früher Code-Reviews in Git gespeichert.
In der Dokumentation steht, „es ist wichtig, nur Repositories zu veröffentlichen, deren Eigentümer oder Maintainer man ist, und sich mit anderen Maintainern abzustimmen, damit keine doppelten Repository-Identifikatoren entstehen“.
Ich habe schon erlebt, dass Leute meinen Code nehmen und auf GitHub hochladen, und ich habe oft gesehen, dass selbst Hinweise in Produktdokumentation oder Zwischen-UI wie „Bitte tun Sie X nicht, sonst entstehen Probleme für andere Nutzer“ von niemandem gelesen, bedacht oder beachtet werden – stattdessen machen sie sofort X. Deshalb glaube ich, dass viele diese Bitte in der Dokumentation nicht befolgen werden; zumal die Homepage nur erklärt, wie man Code pusht, während diese „wichtige“ Bitte in einem Benutzerhandbuch steht, das kaum jemand liest.
Ziemlich besorgniserregend ist, dass das vernünftig wirkende Verhalten, einfach den Open-Source-Code, an dem man arbeitet, gemäß den Anweisungen auf der Homepage zu pushen, aufgrund des Protokolls und der Speicherweise mit der Zeit etwas Wichtiges durcheinanderbringen oder verwirren könnte.
Auf GitHub kann man über die Zahl der Sterne zusätzliches Vertrauen gewinnen; das entsprechende Signal bei Radicle ist die Zahl der Seeds eines bestimmten Repositories.
An einem normalen Computertag sieht man Dutzende Hinweise und nutzt ebenfalls Dutzende Tools. Wenn man bedenkt, wie lange es dauern würde, all diese Hinweise zu lesen und die gesamte Dokumentation aller Tools sorgfältig durchzugehen, wäre das viel zu zeitaufwendig.
Deshalb ist es viel besser, sie nicht zu lesen und stattdessen Heuristiken zu verwenden. Wenn man zum Beispiel ein Dokument mit ungespeicherten Änderungen schließt, weiß man, dass der Dialog wohl „Verwerfen?“ fragt, also muss man ihn nicht lesen. Das ist etwas Gutes.
Fazit: Software muss unter der Annahme entworfen werden, dass Menschen sich so verhalten. Meistens ist das möglich. Wenn es ein konkretes Beispiel gibt, könnte ich vermutlich eine bessere Lösung vorschlagen als „darum bitten und hoffen, dass es gelesen wird“.
Glückwunsch zum Release. Ich verfolge dieses Projekt schon länger, und es ist wirklich spannend zu sehen, wie sehr es gereift ist. Ich frage mich, wie man Projekte, die derzeit auf GitHub liegen, am besten umzieht. Außerdem würde mich interessieren, ob es einen Mirror-Modus gibt, den man ausprobieren kann.
cron-Job einzurichten, der stündlich von GitHub holt und nach Radicle pusht.git pull github mastergit push rad masterIch frage mich, wie auffindbar diese Repositories für normale Nutzer sein werden. https://app.radicle.xyz/robots.txt scheint es nicht zu geben, also dürfen Suchmaschinen offenbar crawlen; tatsächlich liefern Google und DDG bei der Suche nach
site:app.radicle.xyzErgebnisse.Ohne Site-Filter tauchen sie noch nicht weit oben auf, aber das Ranking könnte sich verbessern.
Es wäre auch schön, Tools für CI-Support und -Integration zu haben. Letztlich wäre es wohl eine Schleife wie
while true; do wait_repo_update; git pull && ./run_ci.sh; done, aber es braucht eine bessere Form, die sich auf Pushes vertrauenswürdiger Identifikatoren beschränken lässt.Schließlich braucht es auch ein Repository für Artefakte. Allerdings muss Radicle vielleicht nicht alles lösen. Insbesondere ein verteiltes Netzwerk zum Teilen großer Binärdateien würde vermutlich ziemlich schnell für unerwünschte Zwecke genutzt.
app.radicle.xyzsollten Crawlern wohl erlauben, die gesamte Repository-Menge des Netzwerks zu indexieren.Ich wünschte, Leute würden klar definieren, was „P2P“ oder, wie man häufiger sagt, „dezentral“ genau bedeutet. Im Moment ist es zu einem viel zu vagen Buzzword geworden, das für alles Mögliche verwendet werden kann.
Ein P2P-System ist daher ein System, in dem alle Teilnehmer „gleiche Rechte im Netzwerk“ haben. Normalerweise bedeutet das auch, dass alle dieselbe Software ausführen.
[0]: https://en.wikipedia.org/wiki/Peer-to-peer
Dass die Installationsanleitung
curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | shlautet, hat meine Erwartungen sofort an curl-bash-Müll zerschellen lassenDiese Art der Installation ist ein starkes Signal für gedankenlose Entwicklung. Wenn dieses Projekt groß wird, werden wir wohl eine Sicherheitskatastrophe erleben. Ich hoffe, dass irgendwann eine „Open-Source-P2P-GitHub-Alternative“ erscheint, die nicht mit der schlechtesten Installationsmethode überhaupt beginnt
Die Risiken von Pipe-Installern sind vielen Menschen gut bekannt. Nach dieser Logik müsste man Homebrew [1](GitHub mit über 38.000 Sternen), PiHole [2](über 46.000), Chef [3], RVM [4] und zahllose Open-Source-Projekte verwerfen, die einen einstufigen Auto-Installer verwenden, der in
bashgepiped wirdEine vernünftigere Reaktion wäre, mit den Entwicklern zusammenzuarbeiten, damit die Dokumentation alternative Installationsmethoden anbietet oder die Risiken besser erklärt, statt mit Kanonen auf Spatzen zu schießen
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
[4] https://rvm.io/rvm/install
Was das Problem mit abgebrochenen Übertragungen angeht: Solange es auf dem System keinen gefährlichen Befehl gibt, der auf
^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?)passt, ist das Skript sicherWenn man das erledigt hat, frage ich mich, was der Unterschied dazu ist, nur das Skript bereitzustellen, aber keinen Ausführungsbefehl. Wenn man es prüfen möchte, kann man das Skript herunterladen und separat ausführen. Ich meine, es gab eine Möglichkeit zu erkennen, ob ein Skript gepiped oder heruntergeladen wurde, aber bei so einem kleinen Skript dürfte das wohl nicht funktionieren
[0] https://files.radicle.xyz/latest/
[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
Ich habe das Gefühl, dass ich jedes Mal von Radicle höre, wenn der Kryptomarkt steigt. Nutzt das jemand ernsthaft?
Das wurde ja sofort downgevotet. Ich frage ernsthaft: Ich würde gern wissen, wie viel Budget in Radicle geflossen ist, wie viele Leute daran gearbeitet haben und wer es nutzt
Ich arbeite in der Kryptobranche und hatte denselben Eindruck. Zuletzt habe ich in der letzten Hausse von Radicle gehört, und während des Bärenmarkts war es still. Alle sagen, der Bärenmarkt sei zum Bauen da, und Radicle ist eindeutig ein Entwickler-Tool, was ziemlich seltsam ist
Ich frage mich, ob geplant ist, den Anwendungsfall zu unterstützen, ein Repository nur einer bestimmten Menge von Nodes bereitzustellen. Es dürfte Leute geben, die nicht auf GitHub sein wollen, aber privat zusammenarbeiten möchten
Allerdings ist es im Ruhezustand nicht verschlüsselt, daher kann es nicht auf Zwischen-Nodes gespeichert werden, die nicht zur Vertrauensmenge gehören