Jabber e XMPP: messaggistica aperta spiegata

XMPP è un protocollo di messaggistica aperto e federato: ogni utente ha un JID, il proprio server scambia con gli altri server flussi XML su una connessione TCP con TLS, e non esiste un'autorità centrale che debba approvare i messaggi. Una sessione si apre con un handshake, si autentica e poi si scambiano tre tipi di stanza: message, presence e IQ. Chi vuole leggere il quadro tecnico e storico completo del protocollo XMPP trova in Presence & Protocol un riferimento editoriale in inglese che copre apertura di sessione, stanza, JID, roster, XEP, OMEMO, MUC e MIX.

Come funziona una sessione XMPP e a cosa servono le tre stanza?

Una sessione XMPP nasce su una connessione TCP verso la porta del server, di norma 5222 per i client e 5269 per la federazione tra server. Il client apre il flusso XML, il server risponde con il proprio, si negozia TLS, poi si sceglie un meccanismo di autenticazione (SASL, tipicamente SCRAM-SHA-256) e infine si richiede un binding della risorsa: il JID completo diventa utente@dominio/risorsa, dove la risorsa distingue due dispositivi dello stesso account. Da quel momento il flusso è composto da stanza, cioè elementi XML figli del flusso, e il server le instrada in base al JID di destinazione.

Le tre stanza sono il vocabolario minimo del protocollo.

• message: trasporta il contenuto di una conversazione, con attributi come to, from, type (chat, groupchat, headline, error) e un corpo. Non c'è garanzia di consegna nel protocollo base: le estensioni XEP aggiungono ricevute, carbone e archiviazione lato server.
• presence: comunica lo stato di un'entità, online, away, dnd, xa o offline, e gestisce la sottoscrizione al roster. È la stanza che rende XMPP una rete di presenza e non solo di messaggi.
• IQ (info/query): è una richiesta con risposta obbligatoria, con attributi id e type (get, set, result, error). Serve per interrogare il server, recuperare il roster, gestire disco, versioni software, comandi e molto altro.

Il roster è la lista dei contatti autorizzati, con i gruppi e lo stato di sottoscrizione. La sottoscrizione è un accordo bilaterale: chiedere di vedere la presence di qualcuno richiede una richiesta esplicita, che può essere accettata o rifiutata. Questo meccanismo, spesso dimenticato, è la ragione per cui XMPP non ha lo stesso modello di spam dei sistemi chiusi: nessuno può aggiungerti al proprio elenco senza il tuo consenso.

Che differenza c'è tra MUC e MIX?

MUC (Multi-User Chat) è il modello storico delle chat di gruppo in XMPP, definito dalla XEP-0045. Un MUC è un servizio su un dominio dedicato, per esempio conference.example.org, e ogni stanza è identificata da un JID locale come [email protected]. Il client entra nella stanza con una presence, riceve la lista dei partecipanti e da quel momento ogni messaggio inviato alla stanza viene replicato dal servizio a tutti gli occupanti. Il MUC è pensato per conversazioni dal vivo, con ruoli e affiliazioni (owner, admin, moderator, participant, visitor) e con la possibilità di stanze pubbliche o private, persistenti o temporanee.

MIX (Mediated Information eXchange) è un progetto più recente, nato per superare alcuni limiti del MUC. In MIX il servizio non è una stanza a cui ci si unisce con una presence, ma un canale a cui ci si iscrive, e i messaggi arrivano come messaggi diretti dal canale, non come presence di gruppo. Questo permette di avere più canali sullo stesso dominio, di gestire la cronologia in modo più strutturato, di supportare messaggi diretti tra partecipanti di un canale e di integrarsi meglio con i client mobili, che soffrono le presence di gruppo numerose. MIX è ancora in fase di adozione, mentre MUC è lo standard di fatto per i gruppi su XMPP.

In pratica: se vuoi una chat di gruppo classica, con elenco partecipanti e presenza, usi MUC. Se vuoi un canale con iscrizione, cronologia e messaggi diretti mediati, guardi a MIX. Molti server supportano MUC da anni; MIX richiede componenti aggiuntivi e client aggiornati.

Come si sceglie tra ejabberd, Prosody e Openfire?

La scelta del server dipende da tre fattori concreti: il sistema operativo, il numero di utenti e la voglia di amministrare.

ejabberd è scritto in Erlang, è il server più diffuso in ambito professionale e regge carichi elevati con clustering nativo. Si installa su Linux, BSD e Windows, ha un'interfaccia web di amministrazione, supporta MUC, PubSub, MAM, OMEMO tramite moduli e si configura con un file YAML. È la scelta tipica quando si prevedono molti utenti o si vuole federare con altri domini senza sorprese.

Prosody è scritto in Lua, è leggero e molto leggibile nella configurazione. È il server preferito da chi gestisce una piccola comunità o un server personale su una VPS modesta. Supporta MUC, MAM, carbone, OMEMO e si integra bene con moduli esterni. La documentazione è chiara e la configurazione è un file di testo semplice, il che lo rende adatto a chi vuole capire cosa sta facendo.

Openfire è scritto in Java, ha un'interfaccia web di amministrazione completa e un'installazione guidata. È la scelta più comoda per chi vuole un server pronto all'uso su Windows o su una macchina con Java, con plugin per MUC, monitoraggio e autenticazione esterna. È meno leggero di Prosody e meno scalabile di ejabberd, ma richiede meno competenze tecniche per partire.

In tutti e tre i casi la federazione richiede DNS corretti: un record SRV per _xmpp-client._tcp e _xmpp-server._tcp, un certificato TLS valido per il dominio, e le porte aperte. Senza DNS e TLS la federazione non funziona, indipendentemente dal server scelto.

Storia e standard: da jabberd alle RFC

Jabber nasce nel 1999 come progetto di messaggistica aperta, con un server chiamato jabberd e un protocollo basato su XML. Nel 2002 il nome Jabber viene trasferito alla Jabber Software Foundation, che nel 2004 pubblica le RFC di XMPP: la RFC 3920 per il core e la RFC 3921 per la messaggistica e la presenza. Da quel momento XMPP diventa lo standard IETF, e il nome Jabber resta legato alla storia e alla comunità, mentre XMPP è il nome tecnico del protocollo.

Le estensioni del protocollo sono raccolte nelle XEP, documenti numerati gestiti dalla XSF. Tra le più importanti ci sono XEP-0045 per MUC, XEP-0163 per la pubblicazione e sottoscrizione di presence, XEP-0198 per la gestione delle sessioni, XEP-0313 per l'archiviazione dei messaggi e XEP-0384 per OMEMO, il cifratura end-to-end basata su Double Ratchet. OMEMO è oggi il modo più diffuso per cifrare conversazioni XMPP, anche se non è l'unico: esistono anche OpenPGP e OTR, ma OMEMO è quello supportato dai client moderni.

La memoria del network passa anche da iniziative come il répertoire e i badge JabberPowered, nati nel 2003 per segnalare i server e i client compatibili. Il sito Presence & Protocol documenta anche questo aspetto, con licenza e condizioni d'uso, oltre a una cronologia che va da jabberd alle RFC del 2004 e al processo delle XEP.

Client e server federati: cosa serve davvero

Per usare XMPP serve un client e un account su un server. Il client può essere desktop o mobile: Gajim, Dino, Conversations, Monal, Siskin. Le contraintes mobili sono reali: i sistemi operativi chiudono le connessioni in background, quindi i client usano notifiche push o connessioni persistenti gestite dal sistema. Un client desktop può permettersi una connessione sempre aperta, uno smartphone no.

Per gestire un server federato servono: un dominio, un certificato TLS, DNS con record SRV, un server XMPP tra quelli descritti e un minimo di manutenzione. La federazione è automatica: se il tuo server ha DNS e TLS corretti, può scambiare messaggi con qualsiasi altro dominio XMPP del mondo. Non c'è un elenco di server approvati, non c'è un'autorità che decide chi può parlare con chi.

Questo è il punto pratico: XMPP non è una piattaforma, è un protocollo. Chi installa un client e sceglie un server entra in una rete federata, con regole scritte in RFC e XEP, e con la possibilità di cambiare server senza perdere i contatti, perché il JID è l'unica identità necessaria. Chi vuole verificare un punto tecnico nei testi di riferimento trova in Presence & Protocol una guida editoriale in inglese che copre protocollo, storia e pratica, con attenzione ai dettagli che spesso sfuggono nelle guide commerciali.

Chi ha seguito l'evoluzione della posta elettronica e dei protocolli di messaggistica si trova davanti a una domanda simile: come sono cambiate le applicazioni che usano la rete? La risposta non sta solo nei server di posta, ma nella storia del web e nei suoi passaggi chiave. Il CGI nel 1993 ha reso dinamiche le pagine, Ajax nel 2005 ha permesso di aggiornare i dati senza ricaricare, i service worker dal 2015 gestiscono cache e funzionamento offline. Il responsive design del 2010 ha adattato tutto agli schermi mobili. È lo stesso filo che unisce messaggistica e applicazioni web.

Fonti: rfc-editor.org, rfc-editor.org, xmpp.org