# Manteniamo internet un posto libero dalle Big Tech con le piattaforme open Per definizione, non esistono soluzioni facili a problemi difficili. La semplice scelta (o creazione) di una piattaforma che eviti l'addomesticamento degli utenti non è sufficiente se tale piattaforma può cambiare. Il prezzo della libertà è l'eterna vigilanza: oltre a stabilirci sulla piattaforma giusta, dobbiamo assicurarci che rispetti i suoi utenti sia nel presente che nel futuro. Mantenere una piattaforma libera e *open source* è più diretto[^2] che mantenerla "aperta". Come possiamo evitare che una piattaforma aperta si chiuda in futuro? ## Come si chiudono le piattaforme Ci sono tre modi per chiudere una piattaforma: 1. Una migrazione forzata verso verso una piattaforma differente. 2. Un'unica implementazione diventa dominante, offuscando il confine tra specifica e implementazione. 3. Le implementazioni dominanti adottano troppe funzionalità e comportamenti non standard. Questi tre approcci si sovrappongono: spesso prevedono una monocultura della piattaforma e un unico fornitore che controlla sia i client che i server. ### Migrazione forzata Quando un fornitore controlla tutte le parti di un servizio (ad esempio, sia un client che un server), ha i mezzi per creare quella che chiamo una piattaforma inscatolata [? boxed platform]: un sottoinsieme di una piattaforma aperta più grande che può evolvere al proprio ritmo, senza preoccuparsi di compatibilità o interoperabilità. Il controllo sia del server che del client permette a un fornitore di aggiornarli entrambi senza preoccuparsi di rompere la compatibilità con altri client/server della rete più grande. Potrebbe aggiornare il client per indirizzare gli utenti a un server che adotta un protocollo completamente diverso e chiuso. Questo è ciò che è accaduto a molti utenti di XMPP nei primi anni 2000. #### Studio di un caso: l'inscatolamento di XMPP [XMPP](https://it.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol) (precedentemente noto come Jabber) è un protocollo di messaggistica istantanea aperto e federato. Chiunque può aprire il proprio server XMPP e comunicare con utenti di altri server XMPP, evitando così che una organizzazione possegga la piattaforma. Tra il 2005 e il 2014, molte piattaforme proprietarie lo supportavano: alcuni esempi ben noti erano Google Talk, AOL Instant Messenger (AIM), Facebook Chat (in seguito Facebook Messenger) e Skype. Alcune di queste avevano anche abilitato la federazione tra server. Sfortunatamente, gli utenti di questi servizi proprietari erano in scatola [? users of these proprietary services were boxed]. Pochi utenti di Google Talk parlavano con quelli di Skype, e questi ultimi generalmente non parlavano con quelli di AIM. Come risultato, tutti sono rimasti nelle loro sotto-piattaforme, limitandosi a parlare esclusivamente usando il software del loro fornitore, che controllava l'intero flusso di messaggi, dal client del mittente al server al client del destinatario. Gli utenti erano sempre esposti a un'unica implementazione di XMPP offerta da un unico fornitore. Ciascuna delle piattaforme sopra elencate ha infine bloccato i propri utenti al suo interno migrando da XMPP. Ciò non sarebbe stato possibile se molteplici implementazioni e fornitori avessero interagito l'un l'altro. Immaginate che Bob usi BobClient e BobServer, e Alice usi AliceClient e AliceServer. Tutti e quattro dovrebbero essere compatibili e implementare lo stesso protocollo: sarebbe impossibile che si verifichi una migrazione forzata, poiché si perderebbe la compatibilità. Confrontate la situazione con la posta elettronica: nonostante il dominio di Gmail, ci sono altri fornitori popolari del servizio. Gli utenti di Gmail devono essere in grado di comunicare con utenti non di Gmail e viceversa. La posta elettronica è molto meno "inscatolata" delle altre piattaforme proprietarie di XMPP. Di conseguenza, Google non è stata in grado di controllarla così facilmente: non può semplicemente migrare i suoi utenti a una piattaforma non di posta elettronica, incompatibile con il resto delle implementazioni, per addomesticarli ulteriormente. XMPP è ancora vivo e vegeto, ma la sua popolarità attuale è una frazione di quella di cui godeva un tempo. ### Influenza di un'implementazione Gli standard sono una forma di accordi compiuti per garantire la compatibilità tra le implementazioni e devono essere concordati dalle implementazioni stesse. Quando una di queste diventa dominante, altrettanto fa la sua influenza nel processo decisionale sugli standard condivisi. Un'eccessiva dominanza può creare una monocultura in cui l'implementazione dominante è l'unica conforme alla specifica. Con una voce sufficiente, un'implementazione dominante può servire come riferimento. Le implementazioni di riferimento in genere sono abbastanza utili, servono come fonte di verità con cui testare altre implementazioni. Possono sorgere dei problemi quando gli sviluppi della specifica e dell'implementazione di riferimento sono fortemente connessi, perché la fattibilità dell'implementazione da parte di terzi viene tralasciata nel processo decisionale. #### Studio di un caso: Matrix ed Element Un esempio di questo fenomeno è [Matrix](https://matrix.org/), una piattaforma di messaggistica istantanea aperta e federata simile a XMPP, con una specifica molto vasta che vanta molte caratteristiche: cronologia lato server, risposte, testo formattato, versioni delle stanze, crittografia *end-to-end*, avatar, visualizzazione dei nomi, indicatori di scrittura, ricevute di lettura, verifica del dispositivo... L'elenco continua e cresce ogni mese.[^3] L'unico client che implementa tutte le funzionalità necessarie è [Element](https://element.io), che oltre ad essere il più popolare, serve praticamente come implementazione di riferimento: è sviluppato dalla stessa azienda che sviluppa i server dominanti e la maggior parte della specifica. La stretta connessione tra Element e la specifica di Matrix le permette di aggiungere funzioni a un ritmo troppo elevato perché gli altri client restino al passo. Quasi ogni utente di Matrix prima o poi dovrà usare Element per eseguire un'azione non supportata da alcun altro client. Lato server, Synapse è l'unico che implementa la specifica sufficientemente da essere usabile, e Dendrite è al secondo posto. Entrambi sono sviluppati dalla stessa azienda che sviluppa Element. Poiché non ci sono altri client e server di terzi che possano sostituire quelli ufficiali, un fornitore è prossimo al controllo di tutte le parti della piattaforma. La crescente complessità richiesta dai client e dai server può anche consolidare ulteriormente queste implementazioni dominanti, come ho [spiegato in precedenza](https://hedgedoc.devol.it///s/e9ydqjgaN#Semplicit%C3%A0). Matrix è sul punto di essere una piattaforma inscatolata[?] perché il client e il server ufficiali possono iterare indipendentemente dall'ecosistema più grande. Non credo che Matrix possa diventare a breve una piattaforma completamente chiusa. Il post [*On Privacy versus Freedom*](https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom) (*"Sulla privacy contro la libertà"*) sembra porla sul lato giusto dello spettro aperto-chiuso. Client come [gomuks](https://github.com/tulir/gomuks) e [FluffyChat](https://fluffychat.im/) sembrano riuscire a stare al passo con Element abbastanza da servire come parziali sostituti. Trovo problematico, tuttavia, il suo stato attuale e molto più vicino a "chiuso" nello spettro aperto-chiuso rispetto a XMPP, IRC e la posta elettronica. ### Sovrabbondanza di funzionalità non standard Le piattaforme sono molto di più dei loro protocolli. Implementazioni differenti adottano comportamenti unici per distinguersi dalle altre. I problemi sorgono quando le caratteristiche uniche e non standard di un'implementazione crescono oltre una certa soglia da creare un sovrinsieme chiuso di una piattaforma aperta. #### Studio di un caso: i fornitori di posta elettronica Dopo aver letto il mio articolo precedente, alcune persone mi hanno contattato per chiedermi cosa ne pensassi di alcuni fornitori di posta elettronica. Non c'è molto che possa far distinguere un fornitore dall'altro se ospita soltanto un semplice server di posta elettronica. Per distinguersi, spesso implementano delle funzionalità oltre la conformità agli standard della posta elettronica. La stragrande maggioranza degli account di posta elettronica provengono da una manciata di fornitori dominanti sostenuti da grandi aziende (Gmail, Yahoo! Mail, Yandex Mail, Mail.ru, iCloud e altri). Fornitori come Gmail sono tristemente noti per aver implementato filtri di spam avanzati che discriminano i fornitori meno popolari. Gli utenti che ospitano i server in proprio o si appoggiano a piccoli fornitori provocano spesso dei falsi positivi e i loro messaggi vengono erroneamente etichettati come spam, fino a quando non si sono costruiti una "reputazione".[^4] L'aggiunta di filtri per la prevenzione dello spam così complessi rafforzano l'oligopolio della posta elettronica e creano una barriera d'entrata per i nuovi arrivati. I mittenti a basso volume sono discriminati, come ha scoperto [Migadu](https://web.archive.org/web/20200218162235/https://www.migadu.com/en/guides/deliverability.html): > Abbiamo già avuto a che fare con parecchi cattivi filtri di spam e server mal configurati. In alcuni casi, i server destinatari hanno intenzionalmente respinto delle email corrette solo perché siamo dei mittenti a basso volume. Paradossalmente, è così che dovrebbe essere un mittente ideale. Per migliorare "l'accettabilità" ovviamente offrono il loro servizio di posta elettronica dedicato a un prezzo considerevole. Un altro esempio: fornitori come Hey.com, ProtonMail e Tutanota offrono funzionalità incompatibili con [IMAP](https://it.wikipedia.org/wiki/Internet_Message_Access_Protocol)/[POP3](https://it.wikipedia.org/wiki/Post_Office_Protocol). Questi ultimi due usano la loro implementazione non standard di crittografia *end-to-end* (invece di concentrarsi sul migliorare l'interfaccia dei [PGP](https://it.wikipedia.org/wiki/Pretty_Good_Privacy) standard) ed Hey.com offre l'organizzazione della posta lato server. Gli utenti di questi servizi devono usare i client ufficiali sul web, sul desktop e sui dispositivi mobili.[^5] Questi tre fornitori controllano sia il client che il server e hanno così i mezzi per bloccare i propri utenti al loro interno. Naturalmente c'è un limite a quanto forte possa essere questo blocco: come ho spiegato nel [caso di XMPP](#Studio-di-un-caso-l’inscatolamento-di-XMPP), devono comunque supportare l'[SMTP](https://it.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol) per rimanere compatibili con il resto della rete della posta elettronica. ## Soluzioni Abbiamo parlato abbastanza di morte e distruzione. Concentriamoci ora sulle azioni che gli utenti e i fornitori possono intraprendere per mantenere aperte le piattaforme. ### Cosa possono fare gli utenti Come utenti, considerate di usare client e server realizzati da gruppi diversi di persone, così da rendere più difficile l'inscatolamento della piattaforma. Scegliete delle implementazioni che meno [sovrabbondano di funzionalità](https://it.wikipedia.org/wiki/Feature_creep) oltre alla conformità alla specifica. Ciò che distingue un client non dev'essere *quante* funzionalità offre, ma *come* le implementa. Ovviamente, averne alcune di uniche è fantastico, i problemi sorgono quando il loro numero oltrepassa una certa soglia. Seguendo queste pratiche, le implementazioni sono incoraggiate a conformarsi agli standard, ad essere affidabili e compatibili invece che "innovative". [Scegliete tecnologie noiose](https://web.archive.org/web/20211205161801/https://boringtechnology.club/) al posto di nuove funzionalità luccicanti. Cercate di avventurarvi al di fuori della corrente principale, date un'occhiata a un fornitore o a un client meno popolare. Tutte le implementazioni iniziano da qualche parte, e una loro diversità previene un dominio oligopolistico. Quando scegliete un client e un fornitore, considerate gli incentivi di quest'ultimo. Chi serve? Gli utenti o gli investitori? Ha oltrepassato il punto di sostenibilità finanziaria? Non dico che gli utenti medi facciano qualcosa di "sbagliato" comportandosi diversamente. È ingenuo aspettarsi che cambino il proprio comportamento per un bene superiore. Questo consiglio è rivolto al sottoinsieme di utenti tecnici e abbastanza disposti a porre cura nella scelta delle piattaforme, ed è indirettamente rivolto alle persone che questi possono influenzare. ### Cosa possono fare i fornitori Piuttosto di concentrarvi troppo ad espandervi, concentratevi a rendere il software lato server facile da installare e federare. Chiudete le iscrizioni se la vostra istanza cresce troppo e incoraggiate le persone a guardare verso altri fornitori. Molte istanze del [fediverso](https://mastodon.it/it/fediverso) già lo fanno. Non sto dicendo che espandersi non sia importante, piuttosto, dico che abbassare la barriera d'entrata ad altri fornitori è un approccio efficace alternativo all'espansione.[^6] Considerate le licenze con [permesso d'autore](https://it.wikipedia.org/wiki/Copyleft) (*copyleft*). Il permesso d'autore è uno degli strumenti più potenti che abbiamo per proteggere la libertà degli utenti, perché previene la creazione di opere derivate che cerchino di limitarla. Ciò rende più difficile a implementazioni alternative mantenere le modifiche per sé stesse nel tentativo di "inscatolare" gli utenti. La [GNU AGPLv3](https://it.wikipedia.org/wiki/GNU_Affero_General_Public_License) è particolarmente efficace perché richiede la distribuzione del codice lato server per i servizi in rete. Una proliferazione virale di software sotto licenza AGPLv3 avrebbe mitigato l'inscatolamento degli utenti XMPP nei primi anni 2000. Le implementazioni di riferimento vanno bene se non sono troppo dominanti. Assicuratevi che anche le altre possano stare al passo. Se necessario, rallentate l'evoluzione di una specifica, lasciate che gli sviluppatori delle altre implementazioni partecipino al processo decisionale e prestate loro una mano per migliorarle. Muoversi in fretta e rompere tutto non è il miglior approccio. Per esempio, Element e la Fondazione Matrix.org attenuerebbero molte delle mie preoccupazione se: * Limitassero le nuove iscrizioni all'*homeserver* di Matrix.org, indicando agli utenti server alternativi gestiti da persone diverse. * Adottassero un approccio molto conservativo verso nuove funzionalità, fino a quando più implementazioni di client e server non abbiano raggiunto la parità con Element, Synapse e Dendrite. * Si concentrassero a ridurre i requisiti di sistema per ospitare un server, abbassando la barriera d'entrata per i nuovi fornitori. Ciò sta accadendo con lo sviluppo di Dendrite. ## Inconvenienti L'inconveniente più grande per il consiglio che ho presentato è la velcoità di sviluppo. Mantenere la compatibilità e la conformità alla specifica rallenta il tasso a cui potrebbero essere aggiunte nuove funzionalità. Come [sostiene](https://signal.org/blog/the-ecosystem-is-moving/) Moxie, Signal potrebbe non essere stata in grado di implementare tante funzionalità se fosse stata una piattaforma aperta. Lo sviluppo vincolato da una specifica è, per definzione, *vincolato*. Gli utenti sono limitati dal denominatore comune più basso tra le implementazioni partecipanti più popolari. Le piattaforme aperte con più fornitori e implementazioni spesso soffrono di una peggiore usabilità, in particolare per quanto riguarda la procedura d'iscrizione. Invece di aprire il sito/l'app ufficiale e basta, gli utenti devono scegliere tra molteplici client e fornitori. Ciò potrebbe far calare l'interesse degli utenti occasionali che vogliono solo provare qualcosa di nuovo. Uno dei modi più efficaci per migliorare questa esperienza è fornire consigli ai vostri amici non tecnici. Li conoscete bene e probabilmente potete aiutarli a compiere una decisione informata. ## Paralleli con altre situazioni I linguaggi di programmazione guidati da uno standard invece che da un'implementazione di riferimento godono in genere di una maggiore portabilità, molte buone implementazioni ed è improbabile che se ne vadano col tempo. Alcuni esempi sono il C, C++, Common Lisp, JavaScript e l'interprete POSIX. Confrontateli con un linguaggio come il Python: così tanti pacchetti dipendono dall'approccio alle estensioni in C adottato dall'implementazione di riferimento, CPython, che le implementazioni alternative come PyPy rimarrano perennemente dei cittadini di seconda classe. L'approccio allo sviluppo di una piattaforma guidato dagli standard e dal consenso e l'inefficienza che ne deriva è un compromesso evidente in molti ambiti al di fuori dello sviluppo del software. La maggior parte delle forme di democrazia soffrono di burocrazia e lotte intestine che soffocano il progresso. Alcuni hanno sostenuto che l'inefficienza della democrazia sia una caratteristica, non un errore. Per [come la pone](https://slate.com/news-and-politics/1996/10/the-virtue-of-inefficient-government.html) [Nathan Myhrvold](https://en.wikipedia.org/wiki/Nathan_Myhrvold): > La ragione per cui le società con i governi democratici sono luoghi migliori in cui vivere rispetto alle loro alternative non è a causa di una bontà intrinseca alla democrazia, ma perché la sua disperata inefficienza aiuta a mitigare il potenziale fondamentale per il male. Essere costretti a mantenere una popolarità costante è semplicemente un peso troppo grande da sopportare. Perciò, fortunatamente, si fanno molte poche cose estremamente cattive – o estremamente buone. Forse il più grande vantaggio nell'abbandonare la mentalità del "muoversi in fretta e rompere tutto" è che oltre a rendere più difficile migliorare velocemente un servizio, rende anche più difficile peggiorarlo. ## Riconoscimenti [Denver Gringerich](https://ossguy.com/) mi ha aiutato a raccogliere le idee all'inizio del processo di stesura e mi ha fornito utili informazioni per la sezione su XMPP. Grazie a [Barna Zsombor](https://bzsombor.web.elte.hu/) e carbolymer per avermi fornito un buon riscontro su IRC. Questo articolo è il secondo di una serie di post in cui esploriamo le situazioni in cui il FLOSS (*free, libre, and open source software*, software libero e *open source*) da solo non basta per garantire la libertà degli utenti. Il mio articolo precedente, *[WhatsApp e l'addomesticamento degli utenti](https://hedgedoc.devol.it///s/e9ydqjgaN#)*, ha ricevuto più attenzioni di quante me ne aspettassi. Alcune repliche mi hanno dato molto su cui riflettere,[^1] soprattutto riguardo alle *azioni* che possiamo intraprendere. Suggerisco di leggere prima quell'articolo, in cui ho spiegato cos'è "l'addomesticamento degli utenti" e perché è un problema. Ho elencato tre contromisure: il FLOSS, la semplicità e le piattaforme aperte. Articolo originale: Rohan Kumar, [*Keeping platforms open*](https://seirdy.one/2021/02/23/keeping-platforms-open.html), su *[seirdy.one](seirdy.one)*, 23 febbraio 2021. ## Note [^1]: [Questo commento su Hacker News](https://news.ycombinator.com/item?id=25961895) in particolare ha piantato diversi semi per questo articolo. [^2]: Notate che "diretto" e "facile" non sono interscambiabili, sebbene a volte si sovrappongano. [^3]: Vedete *[This Week in Matrix](https://matrix.org/blog/category/this-week-in-matrix)* ("*Questa settimana su Matrix*"), un blog settimanale sugli aggiornamenti al panorama di Matrix. In particolare, guardate gli aggiornamenti alla specifica: ogni mese vengono integrati nuovi MSC (*Matrix spec changes*, cambiamenti alla specifica di Matrix). [^4]: I consigli ufficiali di [Google](https://support.google.com/mail/answer/81126?hl=it) ed [AWS](https://docs.aws.amazon.com/it_it/ses/latest/DeveloperGuide/dedicated-ip.html#dedicated-ips-managed-reputation) descrivono questo comportamento in maggior dettaglio. [^5]: ProtonMail offre il proprio programma "ponte" che "traduce" la propria API in IMAP, consentendo agli utenti di usare i loro client di posta preferiti. Ciò non cambia che debbano usare i client ufficiali: in questo caso, il "ponte" stesso. [^6]: Ho deciso di non usare un sottotitolo sfrontato come "*Scaling considered harmful*" ("*Espansione ritenuta nociva*"), perché ero preccupato che i lettori di un certo sito web arancione potessero prendere la battuta troppo sul serio.