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

Die Version 1.5 der P2P-Plattform Radicle wurde vorgestellt, die darauf abzielt, einen dezentralen Service für die gemeinsame Entwicklung und Speicherung von Code zu schaffen, ähnlich wie GitHub und GitLab, aber nicht an spezifische Server gebunden, zensurfrei und nutzt die Ressourcen der Teilnehmer des P2P-Netzwerks. Die Plattform unterstützt typische Elemente sozialer Interaktionen von Entwicklern wie Issues, Patches und Code-Reviews. Die Entwicklung des Projekts wurde in Rust geschrieben und wird unter den Lizenzen Apache 2.0 und MIT verbreitet. Es stehen Builds für Linux und macOS zur Verfügung. Zudem werden ein Desktop-Client, eine Web-Oberfläche und eine Konsole entwickelt.

Radicle ermöglicht es, bei der Entwicklung und Verbreitung von Code unabhängig von zentralisierten Plattformen und Unternehmen zu bleiben, deren Bindung zusätzliche Risiken mit sich bringt (Single Point of Failure, das Unternehmen kann schließen oder die Nutzungsbedingungen ändern). Zur Verwaltung des Codes in Radicle wird das vertraute Git verwendet, ergänzt durch Tools zur Bestimmung von Repositories im P2P-Netzwerk. Alle Daten werden zunächst lokal gespeichert (Local-First-Konzept) und sind immer auf dem Computer des Entwicklers verfügbar, unabhängig vom Status der Netzwerkverbindung.

Teilnehmer gewähren 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.

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ässt sich die Plattform leicht mit bestehenden Werkzeugen für die Git-Entwicklung integrieren. Zur Identifizierung der Knoten und zur Verifizierung der Repositories wird eine auf öffentlicher Schlüssel-Kryptographie basierende Methode verwendet, ohne dass Benutzerkonten erforderlich sind. Die Authentifizierung und Autorisierung erfolgt auf Basis öffentlicher Schlüssel ohne zentrale Zertifizierungsstellen. Server.

Jedes Repository im P2P-Netzwerk hat eine einzigartige Kennung 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 bestätigt, die es ermöglicht, die Richtigkeit der Daten auf anderen Knoten ohne die Nutzung zentraler Zertifizierungsstellen zu überprüfen. Um auf das Repository zuzugreifen, genügt es, dass sich mindestens ein Knoten online befindet, auf dem eine replizierte Kopie vorhanden ist.

Knoten im P2P-Netzwerk können sich auf bestimmte Repositories abonnieren und Updates erhalten. Es ist möglich, private Repositories zu erstellen, die nur bestimmten Knoten zugänglich sind. Zur Verwaltung und zum Eigentum am Repository 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 Kennung gebunden sind. Delegierte können Patches im Repository annehmen, Issues schließen und Zugriffsrechte für das Repository festlegen. An jedes Repository können mehrere Delegierte gebunden sein.

Radicle-Repositories werden auf den Systemen der Benutzer als gewöhnliche Git-Repositories gespeichert, die zusätzliche Namensräume zur Speicherung von Peer- und Fork-Daten enthalten, mit denen derzeit gearbeitet wird. Diskussionen, vorgeschlagene Patches und Komponenten zur Organisation von Überprüfungen 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 kein Arbeitsverzeichnis mit einer Kopie der Projektdateien enthalten, sondern nur die Änderungshistorie und Metadaten wie Branches und Tags speichern. Der Befehl „rad clone“ wurde um die Option „—bare“ ergänzt, die es ermöglicht, ein Repository als Bare-Ansicht ohne Arbeitsverzeichnis zu klonen. In der Utility „git-remote-rad“ wurde die Handhabung von Bare-Repositories bei den Befehlen „git push“ und „git fetch“ für den Zugriff auf externe Rad-Server verbessert.
• Eine neue Einstellung „patch.branch“ wurde hinzugefügt, die in der Utility git-remote-rad 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, die jetzt die ursprüngliche Patch-Version anzeigt, die zuvor nur mit dem Flag „—verbose“ ausgegeben wurde. Alle Revisionen werden nun in einer einheitlichen Chronologie angezeigt, ohne zwischen Änderungen des ursprünglichen Autors und anderen Teilnehmern zu unterscheiden.
• Die Möglichkeit, Logs in einer strukturierten Ansicht auszugeben, wurde hinzugefügt, aktiviert durch die Optionen „—log-logger structured“ und „—log-format json.“

Quelle: opennet.ru