Radicle 1.7: Updates zur P2P-Git-Plattform

Radicle 1.7: Wichtige Verbesserungen in der P2P-Plattform für dezentralisierte Entwicklung

Am 18. März 2026 wurde Version 1.7 der P2P-Plattform Radicle veröffentlicht – eine dezentralisierte Alternative zu GitHub und GitLab. Die Plattform arbeitet ohne zentrale Server, nutzt Ressourcen der Netzwerkknoten und ist zensurresistent. Radicle 1.0 erschien im September 2024. Die Komponenten sind in Rust unter Apache-2.0- und MIT-Lizenzen implementiert, Builds sind für Linux und macOS verfügbar. Ein Desktop-Client, eine Weboberfläche und eine CLI befinden sich in Entwicklung.

Die Nachbarschaftserkennung erfolgt über das Gossip-Protokoll, während die Datenreplikation auf Heartwood basiert, das auf Git aufbaut. Knotenidentifikation und Repository-Verifizierung beruhen auf Public-Key-Kryptographie ohne Benutzerkonten. Authentifizierung und Autorisierung sind dezentral.

Repositories sind selbstbescheinigend: Jedes hat eine eindeutige ID, und Commits sowie Issue-Kommentare sind vom Eigentümer signiert. Zugriff ist möglich, wenn mindestens eine Replik im Netzwerk vorhanden ist. Knoten abonnieren Repositories für Updates, und private Repositories werden unterstützt.

Datenmanagement und Speicherungsmechanismen

Das Management erfolgt über Delegierte – Benutzer, Bots oder Gruppen, die mit IDs verknüpft sind. Delegierte nehmen Patches an, schließen Issues und konfigurieren Zugriffe. Mehrere Delegierte können einem Repository zugewiesen werden.

Daten werden in standardmäßigen Git-Repositories mit zusätzlichen Namespaces für Peers und Forks gespeichert. Diskussionen, Patches und Reviews sind Collaborative Objects (COB), die zwischen Knoten repliziert werden.

Die Integration mit Git-Tools ist optimiert: Die Plattform verwendet Git-Objekte und unterstützt Verweise auf externe Branches, Tags, Labels und Notes.

Wichtige Neuerungen in Version 1.7

Version 1.7 konzentriert sich auf Sicherheit, Performance und Benutzerfreundlichkeit. Hier die wichtigsten Änderungen:

• Sigrefs (Signed References): Die Implementierung wurde überarbeitet, um Schutz vor Replay-Attacks zu bieten. Ein Zeiger auf den vorherigen Eintrag in der Kette wurde hinzugefügt, der vollständig signiert ist. Das verhindert den Austausch von altem Code durch erneutes Signieren und gewährleistet eine verifizierbare Historie ab der Wurzel.

• Knotenblockierung: Erweitert auf Verbindungs-Ebene. Die Blockierung wird beim Verbindungsaufbau oder beim Erhalt von einem blockierten Knoten ausgelöst, nicht nur während des Datentransfers.

• Verweise auf externe Git-Objekte: Beliebig viele sind nun erlaubt, außer temporäre Branches (zuvor auf Branches, Tags und Radicle-Metadaten beschränkt).

• Fehlermeldungen: Verbesserte Aussagekraft bei Operationen ohne Zugriffsrechte.

• I/O-Optimierung: Standard synchronous = NORMAL in SQLite (zuvor FULL), um die Belastung bei lang laufenden Knoten zu reduzieren. journal_mode- und synchronous-Einstellungen wurden zur Konfigurationsdatei hinzugefügt.

• Sicherheitslücke behoben: Problem gelöst; Details werden am 23. März veröffentlicht. Scan öffentlicher Repositories ergab keine Hinweise auf Ausnutzung.

Was ist wichtig

• Sigrefs bilden nun eine Kette von Signaturen, die Replay-Attacks und Manipulationen der Historie verhindern.
• Knotenblockierung auf Verbindungs-Ebene verstärkt den Schutz vor unerwünschten Peers.
• SQLite-Optimierung reduziert die I/O-Belastung, ohne die Integrität zu gefährden.
• Unterstützung für beliebige externe Git-Verweise erleichtert Migration und Integration.
• Die Plattform bleibt vollständig dezentral mit Git-kompatibler Speicherung.

Implementierungsempfehlungen

Für Mid-Level- und Senior-Entwickler: Testen Sie Radicle 1.7 in einem isolierten P2P-Netzwerk. Richten Sie Delegierte für CI/CD-Bots ein. Überwachen Sie I/O über SQLite-Parameter bei lang laufenden Knoten. Verwenden Sie Sigrefs für kritische Repositories mit hoher Zensurresistenz.

— Editorial Team