{"id":153580,"date":"2026-01-15T11:12:28","date_gmt":"2026-01-15T09:12:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-6"},"modified":"2026-01-15T11:12:28","modified_gmt":"2026-01-15T09:12:28","slug":"opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-6","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/opublikovana-deczentralizovannaya-platforma-sovmestnoj-razrabotki-radicle-1-6","title":{"rendered":"\u00c8 stata pubblicata la piattaforma decentralizzata di sviluppo collaborativo Radicle 1.6","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c8 stata pubblicata la versione 1.6 della piattaforma P2P Radicle, progettata per creare un servizio decentralizzato di collaborazione e archiviazione del codice, simile a GitHub e GitLab, ma non legato a server specifici, non soggetto a censura e che utilizza le risorse dei partecipanti alla rete P2P. La piattaforma supporta elementi standard di interazione sociale per 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. Le build sono preparate per Linux e macOS. Inoltre, sono in fase di sviluppo un client desktop, un'interfaccia web e un'interfaccia a riga di comando. <\/p>\n

Radicle consente di non dipendere dallo sviluppo e dalla distribuzione del codice da piattaforme e corporation centralizzate, i cui vincoli comportano rischi aggiuntivi (unico punto di errore, la societ\u00e0 potrebbe chiudere o cambiare i termini di servizio). Per la gestione del codice in Radicle si utilizza Git, esteso con strumenti per la definizione dei repository nella rete P2P. Tutti i dati vengono prima salvati localmente (concetto local-first) e sono sempre disponibili 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 sulle correzioni (issues), che vengono salvati localmente e replicati sui nodi di altri sviluppatori interessati, connessi alla rete decentralizzata P2P comune. Alla fine, si forma un repository Git decentralizzato globale, i cui dati sono replicati e duplicati su diversi sistemi dei membri. <\/p>\n

Per la determinazione dei nodi vicini nella rete P2P viene applicato il protocollo Gossip, mentre per la replicazione dei dati tra i nodi \u00e8 utilizzato il protocollo Heartwood, basato su Git. Poich\u00e9 il protocollo si basa su Git, \u00e8 facile integrare la piattaforma con gli strumenti di sviluppo esistenti per Git. Per identificare i nodi e verificare i repository viene utilizzata la crittografia a chiave pubblica, senza l'uso di account. L'autenticazione e l'autorizzazione avvengono sulla base di chiavi pubbliche senza autorit\u00e0 di certificazione centralizzate. server<\/a>. <\/p>\n

Ogni repository nella rete P2P ha un proprio identificatore unico ed \u00e8 auto-certificato, cio\u00e8 tutte le azioni nel repository, come l'aggiunta di commit e la scrittura di commenti agli issue, sono convalidate dal proprietario con una firma digitale, che consente di verificare l'integrit\u00e0 dei dati su altri nodi senza l'uso di autorit\u00e0 di certificazione centralizzate. Per accedere al repository \u00e8 sufficiente che almeno un nodo sia online, in possesso di una copia replicata. <\/p>\n

I nodi nella rete P2P possono iscriversi a determinati repository e ricevere aggiornamenti. \u00c8 possibile creare repository privati, accessibili solo a nodi specifici. Per gestire e possedere un repository si utilizza il concetto di \"delegati\". 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 i diritti di accesso al repository. A ogni repository possono essere collegati pi\u00f9 delegati. <\/p>\n

I repository Radicle vengono memorizzati sui sistemi degli utenti come normali repository git, nei quali sono presenti spazi dei nomi aggiuntivi per memorizzare i dati dei peer e dei fork con cui si sta attualmente lavorando. Le discussioni, le patch proposte e i componenti per organizzare le revisioni vengono anch'essi conservati nel repository git come oggetti condivisi (COB - Collaborative Objects) e vengono replicati tra i peer. <\/p>\n

Nel nuovo rilascio: <\/p>\n