{"id":153580,"date":"2026-01-15T11:12:28","date_gmt":"2026-01-15T09:12:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-6"},"modified":"2026-01-15T11:12:28","modified_gmt":"2026-01-15T09:12:28","slug":"opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-6","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-6","title":{"rendered":"Die dezentralisierte Plattform f\u00fcr gemeinsame Entwicklung Radicle 1.6 wurde ver\u00f6ffentlicht.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die Ver\u00f6ffentlichung der P2P-Plattform Radicle 1.6 ist da. Diese Plattform zielt darauf ab, einen dezentralisierten Service f\u00fcr die gemeinsame Entwicklung und Speicherung von Code zu schaffen, der mit GitHub und GitLab vergleichbar ist, jedoch nicht an spezifische Server gebunden ist, zensurfrei funktioniert und die Ressourcen der Teilnehmer des P2P-Netzwerks nutzt. Die Plattform unterst\u00fctzt g\u00e4ngige Elemente der sozialen Interaktion unter Entwicklern, wie Issues, Patches und Code-Reviews. Die Entwicklung des Projekts erfolgt in Rust und wird unter den Lizenzen Apache 2.0 und MIT ver\u00f6ffentlicht. Bereitstellungen sind f\u00fcr Linux und macOS vorbereitet. Zus\u00e4tzlich werden ein Desktop-Client, ein Webinterface und ein Konsoleninterface entwickelt. <\/p>\n

Radicle erm\u00f6glicht es, bei der Entwicklung und Verteilung von Code unabh\u00e4ngig von zentralisierten Plattformen und Unternehmen zu sein, deren Bindung zus\u00e4tzliche Risiken mit sich bringt (wie z.B. einen einzelnen Ausfallpunkt, das Unternehmen k\u00f6nnte schlie\u00dfen oder die Nutzungsbedingungen \u00e4ndern). Zur Verwaltung des Codes in Radicle wird das gewohnte Git verwendet, erg\u00e4nzt durch Mittel zur Definition von Repositories in einem P2P-Netzwerk. Alle Daten werden in erster Linie lokal gespeichert (Konzept \"local-first\") und sind stets auf dem Computer des Entwicklers verf\u00fcgbar, unabh\u00e4ngig vom Zustand der Netzwerkverbindung. <\/p>\n

Die Teilnehmer gew\u00e4hren Zugang zu ihrem Code und verwandten Artefakten, wie z.B. Patches und Diskussionen \u00fcber Fehlerbehebungen (Issues), die lokal gespeichert und auf Knoten anderer interessierter Entwickler, die mit dem gemeinsamen dezentralen P2P-Netzwerk verbunden sind, repliziert werden. Dadurch entsteht ein globales, dezentrales Git-Repository, dessen Daten auf verschiedenen Systemen der Teilnehmer repliziert und dupliziert sind. <\/p>\n

F\u00fcr die Identifizierung benachbarter Knoten in einem P2P-Netzwerk wird das Gossip-Protokoll verwendet, w\u00e4hrend das Heartwood-Protokoll, basierend auf Git, f\u00fcr die Replikation von Daten zwischen den Knoten zust\u00e4ndig ist. Da das Protokoll auf Git basiert, l\u00e4sst sich die Plattform problemlos in bestehende Git-Entwicklungstools integrieren. Zur Identifikation der Knoten und zur Validierung der Repositories kommt eine kryptographische Methode auf Basis von Public-Key-Kryptographie zum Einsatz, ohne dass Benutzerkonten erforderlich sind. Die Authentifizierung und Autorisierung erfolgt ebenfalls auf Basis von Public Keys, ohne zentrale Zertifizierungsstellen. Server<\/a>. <\/p>\n

Jedes Repository in einem P2P-Netzwerk besitzt eine eindeutige Identifikation und ist selbstzertifizierend, d.h. alle Aktionen im Repository, wie das Hinzuf\u00fcgen von Commits und das Hinterlassen von Kommentaren zu Issues, werden vom Eigent\u00fcmer mit einer digitalen Signatur versehen. Diese erm\u00f6glicht es, die Integrit\u00e4t der Daten auf anderen Knoten zu \u00fcberpr\u00fcfen, ohne zentrale Zertifizierungsstellen einzusetzen. Um auf das Repository zuzugreifen, reicht es aus, wenn sich mindestens ein Knoten online befindet, der eine replizierte Kopie davon hat. <\/p>\n

Knoten in einem P2P-Netzwerk k\u00f6nnen sich f\u00fcr bestimmte Repositories anmelden und Updates erhalten. Es ist m\u00f6glich, private Repositories zu erstellen, die nur f\u00fcr bestimmte Knoten zug\u00e4nglich sind. Zur Verwaltung und zum Besitz eines Repositories wird das Konzept der \u201eDelegierten\u201c (delegates) verwendet. Ein Delegierter kann ein einzelner Benutzer, ein Bot oder eine Gruppe sein, die mit einer speziellen ID verkn\u00fcpft ist. Delegierte k\u00f6nnen Patches in das Repository einpflegen, Issues schlie\u00dfen und Zugriffsrechte auf das Repository festlegen. Es k\u00f6nnen mehrere Delegierte mit jedem Repository verkn\u00fcpft sein. <\/p>\n

Radicle-Repositories werden auf den Systemen der Benutzer als gew\u00f6hnliche Git-Repositories gespeichert, in denen zus\u00e4tzliche Namensr\u00e4ume f\u00fcr die Speicherung von Peer- und Fork-Daten vorhanden sind, mit denen aktuell gearbeitet wird. Diskussionen, vorgeschlagene Patches und Komponenten zur Organisation von Reviews werden ebenfalls in Git-Repositories als gemeinsame Objekte (COB \u2014 Collaborative Objects) gespeichert und zwischen den Peers repliziert. <\/p>\n

In der neuen Version: <\/p>\n