La messaggistica istantanea è uno dei servizi digitali che oggi si danno più per scontati: si installa un’app, si crea un account e si comincia a scrivere. Dietro questa comodità, tuttavia, spesso c’è una dipendenza molto forte da un singolo gestore. Se il servizio cambia condizioni, chiude, limita l’accesso in una regione o modifica la propria politica commerciale, l’utente può fare ben poco.
Daniel Gultsch, sviluppatore open source specializzato nei protocolli di comunicazione e project lead di Conversations, parte proprio da questo punto per riportare l’attenzione su XMPP, tecnologia nata come Jabber nel 1999 e formalizzata dall’IETF con la pubblicazione delle prime RFC del 2004. A oltre 25 anni di distanza, secondo Gultsch, il punto di forza di XMPP non è la “nostalgia”: è la concreta possibilità di costruire sistemi di messaggistica efficaci ed efficienti senza consegnare a un solo fornitore il controllo della rete.
Il tema è di grande attualità, in un momento in cui in Europa si parla con crescente insistenza di sovranità digitale, dipendenza dalle Big Tech e controllo delle infrastrutture.
Gultsch osserva che sostituire un fornitore statunitense con un’azienda europea non risolve automaticamente il problema. Se protocolli, server, identità e interoperabilità restano legati a un unico soggetto, cambia il proprietario del servizio ma non la natura della dipendenza.
Il concetto chiave non è self-hosting, ma sostituibilità
Gultsch usa un paragone con infrastrutture molto più tradizionali. Una società può costruire una strada, fornire apparati a una rete elettrica o realizzare parti di una rete di telecomunicazioni. Il problema nasce quando quella società diventa tecnicamente impossibile da sostituire.
Trasportando la riflessione nel mondo del software, un servizio importante non dovrebbe dipendere da API, formati e server controllati in modo esclusivo da un solo operatore.
Poter installare il codice di un’applicazione su un proprio server (self-hosting) è utile, ma serve relativamente a poco se quel server non può comunicare liberamente con implementazioni indipendenti dello stesso protocollo.
XMPP affronta il problema con un’architettura federata. Un utente può avere un account su un server e comunicare con persone registrate altrove, in modo simile a ciò che accade con la posta elettronica. Il dominio entra nell’identificativo Jabber, o JID, e i server stabiliscono collegamenti server-to-server per instradare i messaggi.
L’utente non deve necessariamente amministrare un’infrastruttura in proprio: può affidarsi a un provider XMPP pubblico, a un server aziendale, a un’associazione oppure a un’istanza personale. L’elemento decisivo è che il protocollo non obbliga tutti gli interlocutori a registrarsi presso lo stesso soggetto.
La X di XMPP spiega perché il protocollo è ancora vivo
XMPP significa Extensible Messaging and Presence Protocol. Quella X iniziale, cioè “Extensible“, è probabilmente la ragione tecnica principale per cui una tecnologia progettata prima dell’iPhone, ben 25 anni fa, riesca ancora a gestire notifiche mobili, chat di gruppo, chiamate, reazioni, allegati e cifratura moderna.
Il nucleo definisce streaming XML, autenticazione, cifratura del canale, presenza e scambio dei messaggi. Le funzioni successive arrivano attraverso gli XMPP Extension Protocols, abbreviati in XEP. La XMPP Standards Foundation (XSF) gestisce il processo con cui una proposta nasce, riceve implementazioni, matura e può raggiungere stati più avanzati.
Un’estensione fondamentale è OMEMO: consente la cifratura end-to-end delle conversazioni tenendo conto anche del caso, oggi normalissimo, in cui lo stesso account utilizzi più dispositivi.
XMPP non impone un’unica applicazione
Un aspetto spesso interpretato come debolezza può diventare un vantaggio: XMPP non definisce una singola esperienza utente. Un client aziendale può privilegiare gruppi, archiviazione e integrazione con altri strumenti; un’app per conversazioni personali può mettere al centro cifratura e semplicità.
Oggi Conversations su Android, Dino su Linux, Gajim su desktop e Monal sulle piattaforme Apple mostrano quanto si sia ridotta la distanza rispetto alle applicazioni proprietarie.
Le estensioni XMPP coprono reazioni, sincronizzazione dello stato di lettura, correzione e ritiro dei messaggi, condivisione multimediale e numerose altre funzioni.
Non tutte le combinazioni client-server supportano però ogni specifica: è il prezzo dell’interoperabilità aperta che implica una verifica delle funzioni implementate da ciascun software. La XSF mantiene proprio per questo informazioni sul supporto delle varie estensioni e suite di conformità che aiutano sviluppatori e amministratori a confrontare implementazioni differenti.
Installare un server XMPP nel 2026 è molto meno “esotico”
L’idea di indipendenza digitale rischierebbe di restare astratta se mettere in piedi un server fosse ancora un’impresa per pochi specialisti. Qui è utile un racconto pubblicato a febbraio 2026 che documenta la realizzazione di un’istanza personale basata su Prosody e Docker.
La configurazione mostra bene come si presenta oggi uno stack XMPP moderno. Prosody, software open source scritto principalmente in Lua, gestisce il protocollo XMPP vero e proprio. Il DNS pubblica record SRV per indicare dove raggiungere il servizio client-to-server e server-to-server: tipicamente le porte TCP 5222 e 5269; i certificati TLS possono arrivare da Let’s Encrypt e il server può operare dentro un container con la configurazione e le chiavi montate separatamente.
Prosody, ampiamente maturato negli ultimi tempi, ha integrato anche mod_cloud_notify, un modulo importante per le notifiche push sui dispositivi mobili.
Come spiega l’approfondimento, in una configurazione reale è bene attivare mod_smacks per lo Stream Management (permette di riprendere una sessione XMPP interrotta riducendo il rischio di perdere messaggi), mod_mam per l’archiviazione delle chat, Carbons per la distribuzione coerente delle conversazioni su più client e componenti dedicati alle chat di gruppo e alla condivisione di file. Non è più il Jabber spartano di vent’anni fa.
Dopo 25 anni il vero confronto non è XMPP contro WhatsApp
XMPP non è destinato a imporsi perché una determinata funzione è più gradevole di WhatsApp, Signal, Telegram o Matrix. L’argomento di Gultsch riguarda un livello più profondo: chi controlla il protocollo, chi può implementarlo e quanto costa abbandonare il fornitore che utilizziamo oggi.
La posta elettronica offre una buona analogia. Gmail può essere dominante, ma Google non possiede il concetto stesso di email. Un utente Fastmail, Proton, Outlook o un server amministrato autonomamente può comunque inviare messaggi agli altri. La qualità dei provider varia, così come antispam, interfacce e affidabilità; il servizio di comunicazione, però, non coincide con una singola azienda. Anche se, come abbiamo visto, mettere in piedi un nuovo server di posta è molto complesso, oggi, soprattutto per questioni di “fiducia” e quindi affidabilità del recapito.
XMPP nasce prima dei social network, degli app store e dello smartphone. Ha attraversato una fase in cui sembrava destinato a sparire, ha sofferto l’arrivo del mobile e ha perso enormemente in visibilità rispetto ai messenger centralizzati.
Eppure continua a ricevere nuove caratteristiche, aggiornamenti delle implementazioni ed è protagonista di continue evoluzioni. Il valore di questa continuità non consiste soltanto nel numero di funzioni disponibili: sta nel fatto che server e client realizzati da soggetti diversi continuano a parlare lo stesso linguaggio di base dopo più di un quarto di secolo.