Un social network cambia le regole, introduce un assistente AI che nessuno aveva chiesto o modifica il modo in cui vediamo i contenuti. Normalmente possiamo accettare le novità oppure abbandonare il servizio, perdendo magari anche i contatti costruiti negli anni. Ma che cosa succederebbe se potessimo modificare direttamente il social network, senza chiedere il permesso alla società che lo gestisce? È la domanda da cui nasce Social.Wiki, un sistema sviluppato da ricercatori del Massachusetts Institute of Technology e presentato il 29 ottobre 2026.
L’idea sembra semplice: prendere il principio collaborativo di Wikipedia e applicarlo non soltanto ai testi, ma alle applicazioni vere e proprie. Dentro Social.Wiki chiunque può modificare il codice di un sito, costruire una funzione o scegliere quali modifiche apportate da altri visualizzare. Il risultato non è un nuovo Facebook già pronto per il grande pubblico, ma un prototipo di ricerca che prova a immaginare un web meno dipendente da piattaforme proprietarie.
Da utenti a persone che possono cambiare le regole
Oggi le applicazioni social vengono progettate e aggiornate da gruppi relativamente piccoli di sviluppatori. Gli utenti possono personalizzare alcuni elementi, ma difficilmente decidere come funziona davvero un algoritmo di raccomandazione, quale assistente compare nelle conversazioni o quali dati vengono richiesti. Social.Wiki ribalta questa impostazione: ogni sito creato nel suo ecosistema dispone di un pulsante per modificarlo.
Premendo quel pulsante si può intervenire direttamente sul codice sorgente oppure descrivere in linguaggio naturale il cambiamento desiderato. Un assistente basato sull’intelligenza artificiale aiuta a tradurre la richiesta in modifiche operative. Per esempio, una chat potrebbe perdere un chatbot indesiderato e acquisire una funzione con cui gli amici votano il ristorante per la serata. Non è necessario che tutti gli altri utenti accettino la stessa versione.
Questo è un passaggio importante: l’intelligenza artificiale non è qui l’arbitro dei contenuti né il proprietario dell’applicazione. È uno strumento di programmazione che abbassa la barriera tecnica. La piattaforma gestisce inoltre parte del lavoro di infrastruttura, così chi vuole creare un piccolo forum o una rete per il proprio gruppo non deve partire configurando server e database.
Lo stesso sito può essere diverso per ciascuno
Se tutti possono modificare un’applicazione, nasce immediatamente una domanda: quale versione dobbiamo vedere? Un social network in cui ogni intervento diventa obbligatorio sarebbe caotico e vulnerabile. I ricercatori propongono una soluzione che chiamano plural governance, cioè una gestione plurale delle modifiche. Ogni persona sceglie una politica che stabilisce quali cambiamenti accettare.
Potrei decidere di vedere soltanto le modifiche approvate da due amici fidati, oppure seguire gli interventi di una comunità di sviluppatori. Un’altra persona potrebbe scegliere regole differenti. Quando il browser Social.Wiki carica il sito, applica le preferenze selezionate e mostra la versione corrispondente. La moderazione non scompare: si distribuisce tra politiche e relazioni di fiducia scelte dagli utenti.
L’esempio più sorprendente riguarda un’applicazione per condividere viaggi: due persone potrebbero usare lo stesso servizio ma visualizzare algoritmi di prezzo differenti. Una potrebbe preferire una tariffa uniforme, l’altra una tariffa dinamica. È un’idea potente, ma introduce anche problemi reali di compatibilità: come si garantisce che versioni differenti continuino a comunicare correttamente e che le regole economiche siano comprensibili a tutti?
Dati separati dalle applicazioni
Il progetto deriva da Graffiti, un precedente framework decentralizzato del gruppo MIT. La scelta architetturale è separare i dati delle persone dalle applicazioni che li utilizzano. In molti servizi attuali, quando carichiamo fotografie, messaggi o informazioni personali, li affidiamo all’azienda che gestisce il sito. In Social.Wiki i dati restano in uno spazio distinto e le applicazioni devono chiedere accesso.
Un componente chiamato data guard intercetta le richieste di lettura o utilizzo dei dati e permette all’utente di valutarle. Questo meccanismo è particolarmente importante perché il codice di un sito può essere modificato da persone diverse: senza controlli, una modifica apparentemente innocua potrebbe provare ad accedere a informazioni che non le spettano.
Naturalmente una richiesta di autorizzazione non equivale automaticamente a sicurezza. Le persone possono approvare permessi senza comprenderne le conseguenze, e un’applicazione complessa può avere comportamenti inattesi. Per questo la protezione dei dati deve essere valutata insieme alla qualità dell’interfaccia, alla trasparenza delle richieste e alle verifiche sul codice.
Che cosa hanno costruito nei primi esperimenti
Il MIT descrive diversi casi di studio. In uno, i partecipanti hanno modificato l’aspetto di un sistema di messaggistica senza cambiare l’esperienza degli altri. In un altro hanno creato un’applicazione per condividere viaggi con un calcolatore trasparente delle tariffe, basato anche sul concetto di salario dignitoso. La piattaforma è stata usata anche per una tela collaborativa, dove più persone possono disegnare insieme.
Durante un hackathon di due ore, piccoli gruppi hanno realizzato applicazioni molto diverse: uno strumento per organizzare le comunicazioni di una cooperativa abitativa su una mappa degli edifici e un microblog chiamato The Garden, in cui i messaggi appaiono come fiori. Sono esempi utili perché mostrano quanto le necessità delle comunità possano differire. Non tutte hanno bisogno di un feed globale ottimizzato per trattenere l’attenzione.
Questi esperimenti dimostrano la fattibilità e la flessibilità del prototipo, non la sua capacità di sostenere centinaia di milioni di utenti. La ricerca sarà presentata all’ACM Symposium on User Interface Software and Technology nel novembre 2026; al momento del comunicato MIT, il lavoro scientifico era disponibile anche come preprint.
I problemi ancora aperti: sicurezza, moderazione e scala
La possibilità di modificare un sito è anche una responsabilità. Un utente malintenzionato potrebbe proporre codice dannoso, una comunità potrebbe adottare regole che amplificano disinformazione o molestie, e persone diverse potrebbero trovarsi davanti a versioni incompatibili della stessa applicazione. La pluralità delle politiche di moderazione può aumentare l’autonomia, ma non elimina la necessità di contrastare abusi e vulnerabilità.
Il gruppo di ricerca riconosce la necessità di ulteriori miglioramenti. Tra le priorità indicate figurano la cifratura end-to-end dei messaggi privati e strumenti migliori per gli sviluppatori. Il team intende inoltre distribuire Social.Wiki a un pubblico più ampio per capire come venga utilizzato fuori dai test iniziali. È lì che emergeranno problemi difficili da riprodurre in laboratorio.
Il web può tornare a essere qualcosa che costruiamo insieme?
Social.Wiki non è ancora un’alternativa commerciale alle grandi piattaforme. E non è detto che ogni utente desideri programmare il proprio social network. Il punto è piuttosto offrire una scelta che oggi quasi non esiste: restare con la propria comunità anche quando si vuole cambiare il software che la ospita. L’intelligenza artificiale può rendere questa scelta più accessibile, purché la facilità di modifica non venga scambiata per assenza di rischi.
Trovo interessante soprattutto il cambio di prospettiva. Negli ultimi anni abbiamo imparato a considerare le applicazioni come spazi in affitto, dove le regole vengono decise altrove. Il MIT prova a immaginarle come luoghi modificabili, in cui gli utenti possono partecipare anche alla progettazione. Se questa visione riuscirà a uscire dai laboratori dipenderà da sicurezza, affidabilità e semplicità. Ma vale già la pena chiedersi perché, nel web di oggi, cambiare piattaforma sia spesso più facile che cambiarne una regola.
