{"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\/novosti-interneta\/vypusk-deczentralizovannoj-platformy-sovmestnoj-razrabotki-radicle-1-0","title":{"rendered":"Rilascio della piattaforma decentralizzata di collaborazione Radicle 1.0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00c8 stata presentata la versione 1.0 della piattaforma P2P Radicle, progettata per creare un servizio decentralizzato di sviluppo e archiviazione del codice, simile a GitHub e GitLab, ma non legato a server specifici, non soggetto a censura e operativo 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 l'uso generalizzato. A partire da questa versione, il protocollo continuer\u00e0 a essere modificato mantenendo la retrocompatibilit\u00e0, e gli strumenti includeranno funzionalit\u00e0 per l'aggiornamento fluido dei sistemi esistenti alla nuova versione. I sviluppi del progetto sono scritti in Rust e distribuiti sotto le licenze Apache 2.0 e MIT. Sono disponibili build per Linux e macOS. \u00c8 in fase di sviluppo anche un client desktop, un'interfaccia web e un'interfaccia da riga di comando. <\/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 nella rete P2P viene utilizzato il protocollo Gossip, mentre per la replicazione 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 esistenti per lo sviluppo su Git. L'identificazione dei nodi e la verifica dei repository avvengono tramite crittografia a chiave pubblica, senza l'uso di account. <\/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

Nei sistemi degli utenti, i repository Radicle vengono memorizzati come normali repository git, nei quali 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 l'organizzazione della revisione vengono anch'essi salvati nel repository git come oggetti collaborativi (COB - Collaborative Objects) e vengono replicati tra i peer. <\/p>\n

Radicle 1.0 include: <\/p>\n