{"id":119756,"date":"2024-09-11T03:43:02","date_gmt":"2024-09-11T01:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-deczentralizovannoj-platformy-sovmestnoj-razrabotki-radicle-1-0"},"modified":"2024-09-11T03:43:02","modified_gmt":"2024-09-11T01:43:02","slug":"vypusk-deczentralizovannoj-platformy-sovmestnoj-razrabotki-radicle-1-0","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/vypusk-deczentralizovannoj-platformy-sovmestnoj-razrabotki-radicle-1-0","title":{"rendered":"Rilascio della piattaforma decentralizzata per lo sviluppo collaborativo Radicle 1.0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c8 stata presentata la versione 1.0 della piattaforma P2P Radicle, destinata a creare un servizio decentralizzato per lo sviluppo e l'archiviazione di codice, simile a GitHub e GitLab, ma non legato a server specifici, immune alla censura e operante utilizzando le risorse dei partecipanti alla rete P2P. Il rilascio della versione 1.0 segna la stabilizzazione del protocollo e la prontezza della piattaforma per un utilizzo diffuso. A partire da questa versione, il protocollo verr\u00e0 modificato mantenendo la retrocompatibilit\u00e0, e gli strumenti includeranno funzionalit\u00e0 per un aggiornamento fluido dei sistemi esistenti alla nuova versione. I lavori del progetto sono scritti in linguaggio Rust e distribuiti sotto le licenze Apache 2.0 e MIT. Sono disponibili build per Linux e macOS. Inoltre, un client desktop, un'interfaccia web e un'interfaccia da console sono in fase di sviluppo. <\/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 determinare i nodi vicini nella rete P2P viene utilizzato il protocollo Gossip, mentre per la replica dei dati tra i nodi \u00e8 impiegato il protocollo Heartwood, basato su Git. Poich\u00e9 il protocollo si basa su Git, la piattaforma \u00e8 facilmente integrabile con strumenti di sviluppo esistenti per Git. Per l'identificazione dei nodi e la verifica dei repository viene utilizzata la crittografia a chiave pubblica, senza l'uso di account. <\/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

Nei sistemi degli utenti, i repository Radicle sono memorizzati come normali repository git, in cui sono presenti spazi dei nomi aggiuntivi per memorizzare i dati dei peer e dei fork con cui si lavora attualmente. Le discussioni, le patch proposte e i componenti per organizzare la revisione vengono anche conservati nel repository git come oggetti collaborativi (COB - Collaborative Objects) e vengono replicati tra i peer. <\/p>\n

Radicle 1.0 include: <\/p>\n