Dalla sostituibilità dei servizi alle reti resilienti: sovranità digitale senza soluzioni miracolose.
Il problema non è scegliere il provider giusto
Nella prima parte siamo arrivati a una conclusione piuttosto scomoda: possiamo costruire infrastrutture affidabilissime, e rimanere comunque dipendenti dalla decisione di un singolo intermediario.
Il nostro servizio è replicato, monitorato, protetto. Poi perdiamo il controllo del dominio, dell’identità degli utenti o del canale attraverso il quale riceviamo pagamenti. I server continuano a funzionare, ma il servizio, per chi deve utilizzarlo, è diventato inutilizzabile.
A quel punto viene spontanea una domanda: qual è il provider che non ci farà mai questo scherzo?
Temo sia la domanda sbagliata.
Non esiste un contratto, un datacenter o una distribuzione Linux capace di eliminarci ogni rischio. Possiamo invece progettare sistemi nei quali la perdita di una singola dipendenza non equivalga alla perdita di tutto. La parola chiave non è isolamento. È sostituibilità.
Ripartiamo allora dalle quattro domande con cui avevo chiuso il primo articolo: posso esportare i dati, cambiare fornitore, controllare le chiavi e continuare a operare se un servizio mi viene revocato?
Se non sappiamo rispondere, non ci serve l’ennesima piattaforma. Ci serve un piano.
Sovranità digitale: meno slogan, più prove di uscita
L’espressione sovranità digitale rischia di diventare uno di quei termini che funzionano benissimo nei convegni e molto meno nei runbook.
Per me ha un significato abbastanza concreto: sapere che cosa possediamo davvero, da chi dipendiamo, e quanto ci costerebbe cambiare strada. Possedere il codice applicativo non basta, se il database non è esportabile o se gli utenti possono autenticarsi soltanto tramite un servizio esterno. Avere un backup non basta, se non abbiamo mai verificato come ripristinarlo su un’infrastruttura diversa.
Non è neppure obbligatorio gestire tutto in proprio. Un servizio cloud può essere una scelta sensata, anche sotto il profilo della sicurezza, quando ci permette di concentrarci sul prodotto. Ma deve essere una scelta consapevole: un fornitore sostituibile non è lo stesso di un fornitore da cui non possiamo uscire.
Il test serio, quindi, non è chiedere al commerciale quanto sia resiliente la piattaforma. È simulare una migrazione, verificare l’export dei dati, recuperare credenziali e chiavi, misurare tempi e costi di uscita. Se possibile, farlo prima che diventi necessario.
La libertà non è una casella da spuntare nel capitolato. È una proprietà che va collaudata.
Gli strumenti esistono. Ma ciascuno risolve un problema diverso
Proviamo a guardare la nostra vita digitale come una stratificazione di scelte, anziché come un unico prodotto da acquistare.
Sul dispositivo, GNU/Linux offre la possibilità di comprendere, modificare e sostituire parti importanti dell’ambiente di lavoro. In ambito mobile, GrapheneOS propone un approccio orientato all’hardening e alla riduzione della superficie d’attacco, su hardware compatibile. Non significa che ogni configurazione Linux sia automaticamente più sicura di ogni alternativa, né che installare un sistema operativo diverso basti a diventare invisibili.
Sull’infrastruttura, il self-hosting può restituirci controllo su dati e servizi. Ma il conto comprende aggiornamenti, monitoraggio, backup, disponibilità e gestione degli incidenti. Se amministriamo male un server, abbiamo soltanto sostituito la dipendenza da un provider con una dipendenza dalla nostra capacità di mantenerlo in salute. Non sempre è un progresso.
Nelle comunicazioni, protocolli come Matrix e XMPP dimostrano che la messaggistica non deve necessariamente coincidere con un’unica piattaforma: identità e server possono appartenere a operatori differenti. La federazione, naturalmente, non cancella i problemi di moderazione, interoperabilità tra client, gestione degli account e manutenzione dei server.
Nostr affronta un’altra parte del problema: gli utenti firmano eventi con le proprie chiavi e possono distribuirli attraverso relay differenti. È un modello interessante per separare identità e intermediario di pubblicazione, ma le chiavi vanno custodite, i relay possono applicare politiche proprie e la disponibilità dei contenuti non è garantita per magia.
E poi ci sono Tor e I2P, che rispondono soprattutto a esigenze di riservatezza, instradamento e resistenza a determinate forme di sorveglianza o blocco. Non confondiamoli con una garanzia assoluta di anonimato: il software, la configurazione e i comportamenti dell’utente restano decisivi.
Si potrebbe continuare a lungo, ma trasformare questo articolo in un catalogo di progetti sarebbe un errore. Il punto è un altro: ogni tecnologia sposta un punto di fiducia. Sta a noi capire quale, verso chi, e con quali nuove responsabilità.
E se Internet non ci fosse proprio?
Fino a questo momento abbiamo ragionato su come rendere i servizi meno dipendenti da un operatore. Proviamo ora a essere più radicali.
Niente ISP. Niente DNS. Niente cloud.
Due persone, magari nello stesso territorio, devono scambiarsi un messaggio. Serve davvero tutta l’infrastruttura che siamo abituati a considerare indispensabile?
È qui che entra in scena Reticulum.
Reticulum è uno stack di rete costruito intorno a identità crittografiche e comunicazioni cifrate, progettato per funzionare su mezzi trasmissivi diversi. Può utilizzare collegamenti IP, ma può anche appoggiarsi a interfacce seriali, radio a pacchetto, Wi-Fi e dispositivi LoRa. Non è un social network, non è un’app di messaggistica e, soprattutto, non è una nuova Internet globale già pronta a sostituire quella esistente.
È un insieme di strumenti per costruire reti che possono operare anche senza la connettività Internet tradizionale, a patto che tra i partecipanti esista comunque un collegamento fisico o un percorso di nodi funzionante.
La distinzione è importante. «Senza Internet» non significa «senza infrastruttura». Significa poter decidere quale infrastruttura usare, anche quando non coincide con quella degli operatori commerciali.
Da Linux a GrapheneOS passando per la radio
Nelle slide del talk che avevo preparato per il Linux Day c’era uno schema che mi piace ancora molto. Non era una dimostrazione eseguita sul palco, ma un’architettura teorica da cui partire per ragionare:
Computer Linux con client LXMF → RNode → collegamento radio LoRa → RNode → dispositivo Android con GrapheneOS e Sideband.
Scomponiamolo, senza saltare i passaggi.
Reticulum gestisce lo strato di comunicazione. LXMF è un protocollo di messaggistica che può operare sopra Reticulum. Sideband è un client che permette di utilizzare queste funzionalità, anche su Android. RNode è un’interfaccia radio utilizzabile per collegare Reticulum a hardware LoRa.
LoRa è una tecnologia radio per comunicazioni a basso bitrate e relativamente lunga portata, a seconda dell’ambiente e della configurazione. Non va confusa con LoRaWAN, che è un protocollo di rete distinto e non rappresenta un requisito di questo schema.
Il computer non «manda un messaggio a Internet e spera che arrivi». Usa un’interfaccia radio configurata; il dispositivo dall’altra parte deve essere raggiungibile direttamente o attraverso nodi intermedi compatibili. Identità, applicazioni e interfacce devono essere configurate correttamente. Il destinatario può ricevere il messaggio quando esiste un percorso di consegna, eventualmente con meccanismi di inoltro e memorizzazione previsti dall’ecosistema.
È una prospettiva affascinante: una comunicazione digitale cifrata può avvenire senza account presso un servizio cloud, senza risoluzione DNS e senza abbonamento dati lungo il tragitto radio. Ma sarebbe scorretto chiamare questo schema una soluzione già testata da me, o suggerire che basti comprare due moduli radio per ottenere una rete affidabile.
È un progetto tecnico da sperimentare, non una promessa commerciale.
La fisica, per fortuna, non legge i manifesti
A questo punto arriva l’obiezione inevitabile: se è così interessante, perché non lo usiamo tutti?
Perché la libertà tecnologica non abolisce la fisica, e nemmeno il lavoro di chi deve amministrare la rete.
La banda disponibile su molti collegamenti radio è limitata: le aspettative devono essere quelle della messaggistica a basso traffico, non dello streaming video. La copertura dipende da antenne, ostacoli, potenza, posizione e disponibilità di nodi intermedi. La consegna non è garantita in ogni momento: se non c’è un percorso utile, il messaggio può attendere oppure non arrivare nei tempi desiderati.
La gestione delle chiavi resta una responsabilità concreta. La crittografia protegge una comunicazione soltanto all’interno delle proprietà effettive del protocollo e del software utilizzato; non protegge un dispositivo compromesso, un’identità scambiata per errore o un’implementazione vulnerabile. Lo stesso progetto Reticulum segnala che la sicurezza della sua implementazione non va trattata come una garanzia assoluta.
Ci sono poi le regole sull’uso dello spettro radio, da verificare in base a paese, frequenze, apparati e modalità operative. E c’è la compatibilità del software con i dispositivi: l’esistenza di Sideband su Android non equivale alla garanzia che qualunque combinazione di telefono, cavo, adattatore e RNode funzioni immediatamente.
Infine c’è una questione meno appariscente ma interessante per chi tiene al software libero: la reference implementation di Reticulum oggi è pubblicata con una licenza specifica che contiene restrizioni d’uso. Il codice è accessibile, ma non è corretto confondere questa disponibilità con una licenza open source priva di restrizioni di campo d’impiego secondo i criteri OSI. È una scelta del progetto che merita di essere letta e valutata, non nascosta dietro un’etichetta comoda.
Non è una ragione per ignorare Reticulum. È una ragione in più per analizzarlo con lo stesso rigore che chiediamo alle tecnologie proprietarie.
Il Sovereignty Stack: sei strati, nessuna bacchetta magica
Se dovessi riassumere l’idea dell’intero talk in uno schema, userei quello che avevo chiamato Sovereignty Stack.
Non è un prodotto e non è uno standard. È un modo di organizzare domande di architettura:
- Device e sistema operativo: controllo del dispositivo, aggiornamenti, superfici d’attacco, proprietà delle credenziali.
- Infrastruttura: dati esportabili, backup ripristinabili, servizi gestibili da più operatori.
- Rete e comunicazione: protocolli aperti, percorsi alternativi, possibilità di comunicare anche con connettività degradata.
- Identità e socialità: chiavi, account portabili, interoperabilità, possibilità di cambiare client e intermediari.
- Pagamenti: capacità di ricevere e trasferire valore senza dover necessariamente affidare la custodia a un processore centrale.
- Attività economica: modelli di servizio nei quali la piattaforma facilita una relazione senza appropriarsi automaticamente delle identità, dei dati o dei fondi dei partecipanti.
Non dobbiamo raggiungere l’indipendenza totale a tutti e sei i livelli per ottenere un vantaggio. Possiamo iniziare da quello che oggi costituisce il nostro rischio maggiore.
Per un’organizzazione potrebbe essere la portabilità del database. Per un giornalista, la raggiungibilità del proprio pubblico. Per una comunità locale, la disponibilità di un canale di comunicazione quando la connettività Internet non funziona. Per un professionista, la possibilità di ricevere pagamenti senza cedere a un intermediario il controllo dei fondi.
E in ognuno di questi casi dobbiamo chiederci quanto siamo disposti a pagare, in denaro e lavoro operativo, per ottenere maggiore autonomia.
E quando arriva il momento di essere pagati?
C’è un livello che nelle discussioni sulla decentralizzazione viene spesso lasciato per ultimo: il denaro.
Possiamo utilizzare protocolli aperti per comunicare, possedere il nostro server, controllare le nostre chiavi. Poi magari scopriamo che per far funzionare un’attività dobbiamo dipendere da un unico intermediario che autorizza, trattiene o revoca i pagamenti.
È qui che Bitcoin diventa interessante, al di là delle discussioni sul prezzo. Permette di trasferire valore secondo regole di rete condivise, senza richiedere che il beneficiario affidi necessariamente a una piattaforma la custodia dei propri fondi. Non elimina costi di transazione, rischi di volatilità, obblighi fiscali, problemi di usabilità o vincoli normativi. E non garantisce che ogni utente riesca sempre a comunicare con la rete quando la connettività viene interrotta.
BTCPay Server porta questo modello dentro un contesto applicativo: un esercente può generare richieste di pagamento e ricevere Bitcoin direttamente in un wallet che controlla, senza consegnare al software di fatturazione le proprie chiavi private per ricevere pagamenti on-chain. Resta da gestire un’infrastruttura, e per Lightning esistono ulteriori aspetti operativi legati ai nodi e alla liquidità.
A questo punto il collegamento con un progetto a cui sto lavorando, The Orange Cove, viene quasi spontaneo. L’idea architetturale è semplice: un marketplace può aiutare cliente e professionista a incontrarsi, organizzare il lavoro e avviare un pagamento, senza essere obbligato a custodire i Bitcoin del professionista. È un progetto in sviluppo, non un caso da esibire come prova di successo commerciale o come garanzia di assenza di obblighi regolamentari.
Il punto non è promuovere una piattaforma. È mostrare che la separazione fra chi facilita un servizio e chi controlla i fondi può essere una scelta di architettura.
Vale per il denaro come per i dati: ridurre una dipendenza non significa abolire ogni intermediario; significa impedire che un intermediario diventi automaticamente proprietario di ciò che dovrebbe soltanto trasportare o coordinare.
La sovranità ha un costo. La dipendenza pure.
Non vorrei concludere con la solita invocazione a «riprenderci Internet», perché detta così è troppo facile.
Mettere in piedi un server richiede manutenzione. Gestire chiavi crittografiche richiede disciplina. Una rete radio richiede nodi, copertura, competenze e spesso una certa dose di pazienza. Federare servizi significa affrontare antispam, interoperabilità e moderazione. Usare sistemi di pagamento non-custodial implica assumersi responsabilità che altrove deleghiamo.
Non è detto che per ogni persona o azienda il beneficio superi il costo. E non c’è nulla di virtuoso in una soluzione «indipendente» che diventa inaffidabile o insicura per mancanza di risorse.
Ma c’è anche un costo che abbiamo imparato a non vedere: quello di non poter scegliere. Il prezzo di una migrazione impossibile, di un’identità legata a un solo gestore, di un’attività che si ferma perché qualcuno ha spento un servizio che consideravamo permanente.
Per questo non propongo di buttare via cloud, piattaforme o infrastrutture consolidate. Propongo di cominciare a porre domande diverse quando progettiamo qualcosa di nuovo. Chi possiede le chiavi? Quanto costa uscire? Quali protocolli possiamo sostituire? Che cosa rimane in piedi quando il fornitore cambia idea o la rete non è disponibile?
Le risposte non arriveranno tutte da Reticulum, da Linux o da Bitcoin. Nessuna tecnologia, da sola, restituisce autonomia a chi non sa quali dipendenze ha costruito.
Il codice non basta. Le scelte sì.
Non serve sostituire tutta Internet. Serve smettere, quando possiamo evitarlo, di costruire sistemi che un solo intermediario può rendere inutilizzabili.
Internet è ancora riparabile. Ma non si aggiusta con uno slogan.