Die Version 1.6 der P2P-Plattform Radicle wurde ver\u00f6ffentlicht, die darauf abzielt, einen dezentralen Service f\u00fcr die gemeinsame Entwicklung und Speicherung von Code zu schaffen, der \u00e4hnlich wie GitHub und GitLab funktioniert, jedoch nicht an bestimmte Server gebunden, zensurresistent und auf Ressourcen von Teilnehmern des P2P-Netzwerks angewiesen ist. Die Plattform unterst\u00fctzt g\u00e4ngige Elemente der sozialen Interaktion von Entwicklern, wie Issues, Patches und Code-Reviews. Die Entwicklungen des Projekts sind in der Programmiersprache Rust geschrieben und werden unter den Lizenzen Apache 2.0 und MIT verbreitet. Die Builds sind f\u00fcr Linux und macOS vorbereitet. Zus\u00e4tzlich werden ein Desktop-Client, eine Web-Oberfl\u00e4che und eine Konsole entwickelt. <\/p>\n
Radicle erm\u00f6glicht es, bei der Entwicklung und Verbreitung von Code unabh\u00e4ngig von zentralisierten Plattformen und Unternehmen zu bleiben, deren Bindung zus\u00e4tzliche Risiken mit sich bringt (Single Point of Failure, das Unternehmen kann schlie\u00dfen oder die Nutzungsbedingungen \u00e4ndern). Zur Verwaltung des Codes in Radicle wird das vertraute Git verwendet, erg\u00e4nzt durch Tools zur Bestimmung von Repositories im P2P-Netzwerk. Alle Daten werden zun\u00e4chst lokal gespeichert (Local-First-Konzept) und sind immer auf dem Computer des Entwicklers verf\u00fcgbar, unabh\u00e4ngig vom Status der Netzwerkverbindung. <\/p>\n
Teilnehmer gew\u00e4hren Zugang zu ihrem Code und zu den damit verbundenen Artefakten wie Patches und Diskussionen von Fehlerberichten (Issues), die lokal gespeichert und auf die 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
Zur Bestimmung benachbarter Knoten im P2P-Netzwerk wird das Gossip-Protokoll verwendet, und zur Replikation von Daten zwischen den Knoten das Heartwood-Protokoll, das auf Git basiert. Da das Protokoll auf Git basiert, l\u00e4sst sich die Plattform leicht mit bestehenden Werkzeugen f\u00fcr die Git-Entwicklung integrieren. Zur Identifizierung der Knoten und zur Verifizierung der Repositories wird eine auf \u00f6ffentlicher Schl\u00fcssel-Kryptographie basierende Methode verwendet, ohne dass Benutzerkonten erforderlich sind. Die Authentifizierung und Autorisierung erfolgt auf Basis \u00f6ffentlicher Schl\u00fcssel ohne zentrale Zertifizierungsstellen. Server<\/a>. <\/p>\n Jedes Repository im P2P-Netzwerk hat eine einzigartige Kennung 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 best\u00e4tigt, die es erm\u00f6glicht, die Richtigkeit der Daten auf anderen Knoten ohne die Nutzung zentraler Zertifizierungsstellen zu \u00fcberpr\u00fcfen. Um auf das Repository zuzugreifen, gen\u00fcgt es, dass sich mindestens ein Knoten online befindet, auf dem eine replizierte Kopie vorhanden ist. <\/p>\n Knoten im 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 des Repositories wird das Konzept der \u201eDelegierten\u201c verwendet. Ein Delegierter kann sowohl ein einzelner Benutzer als auch ein Bot oder eine Gruppe sein, die mit einer speziellen Kennung verbunden ist. Delegierte k\u00f6nnen Patches in das Repository einpflegen, Issues schlie\u00dfen und Zugriffsrechte f\u00fcr das Repository festlegen. An jedes Repository k\u00f6nnen mehrere Delegierte gebunden werden. <\/p>\n Radicle-Repositories werden auf den Systemen der Benutzer als ganz normale Git-Repositories gespeichert, in denen zus\u00e4tzliche Namensr\u00e4ume f\u00fcr die Speicherung von Peer-Daten und Forks vorhanden sind, mit denen derzeit gearbeitet wird. Diskussionen, vorgeschlagene Patches und Komponenten zur Organisation von Reviews werden ebenfalls in Git-Repositories in Form von kollaborativen Objekten (COB \u2014 Collaborative Objects) gespeichert und zwischen den Peers repliziert. <\/p>\n In der neuen Version: <\/p>\n\n