{"id":165452,"date":"2026-03-20T17:11:54","date_gmt":"2026-03-20T15:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-7"},"modified":"2026-03-20T17:11:54","modified_gmt":"2026-03-20T15:11:54","slug":"opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-7","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-7","title":{"rendered":"\u00c8 stata pubblicata la piattaforma decentralizzata di sviluppo collaborativo Radicle 1.7","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c8 stato rilasciato Radicle 1.7, una piattaforma P2P progettata per creare un servizio decentralizzato di sviluppo e archiviazione del codice, simile a GitHub e GitLab, ma non legata a server specifici, non soggetta a censura e funzionante grazie alle risorse dei partecipanti alla rete P2P. La piattaforma supporta elementi tipici di interazione sociale tra sviluppatori, come issue, patch e recensioni del codice. I progressi del progetto sono scritti in Rust e distribuiti sotto le licenze Apache 2.0 e MIT. Sono disponibili versioni per Linux e macOS. Inoltre, sono in sviluppo un client desktop, un'interfaccia web e un'interfaccia da console. <\/p>\n

Radicle consente di sviluppare e distribuire codice senza dipendere da piattaforme e corporation centralizzate, la cui dipendenza comporta ulteriori rischi (singolo punto di fallimento, la societ\u00e0 potrebbe chiudere o modificare le condizioni di utilizzo). Per gestire il codice in Radicle si utilizza Git, arricchito da strumenti che definiscono i repository in una rete P2P. Tutti i dati sono principalmente salvati localmente (concetto di local-first) e sono sempre accessibili sul computer dello sviluppatore, indipendentemente dallo stato della connessione di rete. <\/p>\n

I partecipanti forniscono accesso al proprio codice e agli artefatti correlati, come patch e discussioni sulla correzione di bug (issues), che sono salvati localmente e replicati sui nodi di altri sviluppatori interessati, connessi a una rete P2P decentralizzata comune. Di conseguenza, si forma un repository Git decentralizzato globale, i cui dati sono replicati e duplicati su diversi sistemi dei partecipanti. <\/p>\n

Per determinare i nodi vicini in una rete P2P viene utilizzato il protocollo Gossip, mentre per la replica dei dati tra i nodi si utilizza il protocollo Heartwood, basato su Git. Poich\u00e9 il protocollo \u00e8 basato su Git, la piattaforma si integra facilmente con gli strumenti di sviluppo esistenti su Git. L'identificazione dei nodi e la verifica dei repository avviene mediante crittografia basata su chiavi pubbliche, senza l'uso di account. L'autenticazione e l'autorizzazione sono basate su chiavi pubbliche senza enti di certificazione centralizzati. server<\/a>. <\/p>\n

Ogni repository nella rete P2P ha un identificatore unico ed \u00e8 auto-certificato, cio\u00e8 tutte le azioni nel repository, come l'aggiunta di commit e la pubblicazione di commenti sulle issue, sono firmate digitalmente dal proprietario, consentendo di verificare l'integrit\u00e0 dei dati su altri nodi senza utilizzare enti di certificazione centralizzati. Per accedere al repository \u00e8 sufficiente che sia online almeno un nodo contenente una copia replicata di esso. <\/p>\n

I nodi nella rete P2P possono iscriversi a specifici repository e ricevere aggiornamenti. \u00c8 possibile creare repository privati, accessibili solo a determinati nodi. Per gestire e possedere un repository si utilizza il concetto di \u00abdelegati\u00bb (delegates). Un delegato pu\u00f2 essere un singolo utente, un bot o un gruppo, legati a un identificatore speciale. I delegati possono accettare patch nel repository, chiudere issue e impostare diritti di accesso al repository. A ciascun repository possono essere associati pi\u00f9 delegati. <\/p>\n

I repository Radicle sono memorizzati sui sistemi degli utenti come normali repository git, che contengono spazi dei nomi aggiuntivi per memorizzare i dati dei peer e dei fork con cui si sta lavorando attualmente. Le discussioni, le patch proposte e i componenti per l'organizzazione delle revisioni vengono anch'essi salvati nel repository git come oggetti collaborativi (COB \u2014 Collaborative Objects) e replicati tra i peer. <\/p>\n

Nel nuovo rilascio: <\/p>\n