Die dezentrale Plattform für gemeinschaftliche Entwicklung Radicle 1.5 ist verfügbar.

Die Version 1.5 der P2P-Plattform Radicle wurde veröffentlicht, die darauf abzielt, einen dezentralen Dienst zur gemeinsamen Entwicklung und Speicherung von Code bereitzustellen, der GitHub und GitLab ähnelt, jedoch nicht an spezifische Server gebunden ist, zensurfrei arbeitet und die Ressourcen der Teilnehmer des P2P-Netzwerks nutzt. Die Plattform unterstützt gängige Elemente des sozialen Austauschs unter Entwicklern, wie Issues, Patches und Code-Reviews. Die Entwicklungen des Projekts sind in Rust geschrieben und werden unter den Lizenzen Apache 2.0 und MIT veröffentlicht. Die Builds sind für Linux und macOS vorbereitet. Zusätzlich werden ein Desktop-Client, eine Web-Oberfläche und eine Konsolenanwendung weiterentwickelt.

Radicle ermöglicht es, bei der Entwicklung und Verteilung von Code unabhängig von zentralisierten Plattformen und Unternehmen zu sein, deren Bindung zusätzliche Risiken mit sich bringt (wie z.B. einen einzelnen Ausfallpunkt, das Unternehmen könnte schließen oder die Nutzungsbedingungen ändern). Zur Verwaltung des Codes in Radicle wird das gewohnte Git verwendet, ergänzt 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ügbar, unabhängig vom Zustand der Netzwerkverbindung.

Die Teilnehmer gewähren Zugang zu ihrem Code und verwandten Artefakten, wie z.B. Patches und Diskussionen über 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.

Für die Identifizierung benachbarter Knoten in einem P2P-Netzwerk wird das Gossip-Protokoll verwendet, während das Heartwood-Protokoll, basierend auf Git, für die Replikation von Daten zwischen den Knoten zuständig ist. Da das Protokoll auf Git basiert, lässt 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.

Jedes Repository in einem P2P-Netzwerk besitzt eine eindeutige Identifikation und ist selbstzertifizierend, d.h. alle Aktionen im Repository, wie das Hinzufügen von Commits und das Hinterlassen von Kommentaren zu Issues, werden vom Eigentümer mit einer digitalen Signatur versehen. Diese ermöglicht es, die Integrität der Daten auf anderen Knoten zu überprüfen, 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.

Knoten im P2P-Netzwerk können sich für bestimmte Repositories anmelden und Updates erhalten. Es ist möglich, private Repositories zu erstellen, die nur bestimmten Knoten zugänglich sind. Zur Verwaltung und Eigentümerschaft eines Repositories wird das Konzept der 'Delegierten' verwendet. Ein Delegierter kann sowohl ein einzelner Benutzer als auch ein Bot oder eine Gruppe sein, die an eine spezielle Identifikationsnummer gebunden sind. Delegierte können Patches im Repository akzeptieren, Issues schließen und Zugriffsrechte für das Repository festlegen. An jedes Repository können mehrere Delegierte gebunden werden.

Radicle-Repositories werden auf den Systemen der Benutzer als gewöhnliche Git-Repositories gespeichert, in denen zusätzliche Namensräume für die Speicherung von Peer-Daten und Forks vorhanden sind, mit denen aktuell gearbeitet wird. Diskussionen, vorgeschlagene Patches und Komponenten zur Organisation von Reviews werden ebenfalls im Git-Repository als kollaborative Objekte (COB – Collaborative Objects) gespeichert und zwischen den Peers repliziert.

In der neuen Version:

• Die Unterstützung für Bare-Repositories wurde verbessert, die keinen Arbeitsordner mit einer Kopie der Projektdateien enthalten, sondern nur die Änderungsverläufe und Metadaten wie Branches und Tags speichern. Der Befehl „rad clone“ hat die Option „—bare“ hinzugefügt, die es ermöglicht, das Repository in einer Ansicht ohne Arbeitsverzeichnis zu klonen. In dem Tool „git-remote-rad“ wurde die Handhabung von Bare-Repositories bei der Verwendung der Befehle „git push“ und „git fetch“ für externe rad-Server verbessert.
• Die Einstellung „patch.branch“ wurde hinzugefügt, die in der git-remote-rad Utility verwendet werden kann („git-remote-rad -o patch.branch[=<name>]“), um beim Hinzufügen eines Patches automatisch einen Branch im Upstream-Repository zu erstellen, ohne den Befehl „rad patch checkout“ verwenden zu müssen.
• Die Ausgabe des Befehls „rad patch show“ wurde verbessert, der nun die ursprüngliche Patch-Version anzeigt, die zuvor nur bei Angabe des „—verbose“-Flags ausgegeben wurde. Alle Revisionen werden jetzt in einer einheitlichen Chronologie angezeigt, ohne zwischen Änderungen des ursprünglichen Autors und anderer Beteiligter zu unterscheiden.
• Die Möglichkeit, Protokolle in einer strukturierten Ansicht auszugeben, wurde hinzugefügt, die über die Optionen „—log-logger structured“ und „—log-format json“ aktiviert werden kann.

Quelle: opennet.ru