Jabber instrada messaggi e presenza fra server di soggetti diversi, senza un’autorità centrale e senza obbligare i client a parlare lo stesso protocollo proprietario. Il server di riferimento, jabberd, è alla versione 1.x e gira su jabber.org dal 1999; la 1.2 dell’ottobre 2000 ha introdotto il dialback, il meccanismo che oggi tiene insieme la rete dei server indipendenti (https://xmpp.org/about/history/). Raccolgo qui gli appunti presi leggendo il protocollo, con in testa una domanda: ci si può costruire sopra un servizio?

Contesto

Nel 2001 la messaggistica istantanea è una collezione di silos. AIM, ICQ (entrambi di AOL), MSN Messenger e Yahoo! Messenger usano protocolli chiusi, non documentati, e ognuno pretende il proprio client. L’interoperabilità, dove esiste, è il sottoprodotto di un reverse engineering che il fornitore rompe al primo aggiornamento del server. Chi vuole offrire presenza e messaggi come servizio — un portale, un operatore, una intranet aziendale — deve scegliere una piattaforma chiusa e accettarne le condizioni.

Jabber va nella direzione opposta: un protocollo aperto, in XML, con un server libero (jabberd, sotto Jabber Open Source License / GPL) e diversi client e librerie indipendenti. Jeremie Miller ha annunciato il progetto a inizio 1999; la 1.0 del server, di maggio 2000, ha stabilizzato lo streaming XML, i messaggi, la presenza e le liste contatti (https://xmpp.org/about/history/).

Architettura

Il client apre verso il proprio server un unico stream XML lungo, e al suo interno scorrono i frammenti — le stanza. Lo stream si apre con il tag radice <stream:stream>, e da lì in poi ogni elemento di primo livello fa storia a sé: <message/>, <presence/>, <iq/> (info/query). Lo stream resta aperto per tutta la sessione; non c’è una richiesta/risposta HTTP per ogni evento, ed è questo che rende economica la notifica di presenza in tempo reale.

L’indirizzo di un utente ha la forma nodo@dominio/risorsa. Il dominio identifica il server, esattamente come la parte a destra della @ in una mail; la risorsa distingue le connessioni simultanee dello stesso account (per esempio lavoro e casa). È un nome che si risolve via DNS sul dominio del server, non un identificativo opaco assegnato da un fornitore: chiunque controlli un dominio può ospitare i propri utenti.

La presenza è informazione che il server propaga. Quando mi collego, il server manda un <presence/> a tutti i contatti che hanno una sottoscrizione verso di me; ogni cambio di stato (away, dnd, chat) è un nuovo <presence/>. La lista contatti — il roster — sta sul server, nel namespace jabber:iq:roster, e così mi segue da qualunque client: non è un file locale.

Il punto critico

Ciò che rende Jabber una rete e non un arcipelago di isole è il server dialback, arrivato con jabberd 1.2. Quando a.example riceve da un suo utente un messaggio diretto a tizio@b.example, apre una connessione server-to-server verso b.example e deve dimostrare di essere davvero a.example, altrimenti chiunque potrebbe iniettare messaggi spacciandosi per qualsiasi dominio.

Il dialback se la cava appoggiandosi al DNS. In sintesi: a.example manda a b.example una chiave derivata da un segreto e dagli identificativi dei due stream; b.example non si fida di quella connessione, ma ne apre una propria verso il dominio a.example risolto via DNS e gli chiede di confermare la chiave. Se la conferma arriva sul canale che b.example ha aperto da solo, allora il mittente controlla davvero il DNS di a.example. È un’autenticazione debole — lega l’identità del server alla sicurezza del DNS, non a una catena di certificati — ma non richiede né una certificate authority né accordi bilaterali, ed è questo che ha fatto crescere la rete dei server senza un registro centrale (https://xmpp.org/about/history/).

Gateway verso le reti chiuse

Jabber non finge che le reti proprietarie non esistano: le incapsula. Un transport (o gateway) è un componente che da un lato si connette al server Jabber e dall’altro parla il protocollo legacy — ci sono transport per AIM, ICQ, MSN, Yahoo! e per servizi non-IM come IRC ed e-mail. Dal mio client, un contatto MSN compare come un normale indirizzo Jabber sul dominio del gateway (per esempio 12345@msn.gateway.example), e i messaggi gli arrivano attraverso lo stesso stream che uso per tutto il resto.

La registrazione passa per jabber:iq:gateway e jabber:iq:register: deposito sul transport le mie credenziali della rete legacy, e da lì in poi il gateway tiene aperta la sessione proprietaria per mio conto e traduce presenza e messaggi nelle due direzioni (https://jabber.org/). Il costo è strutturale: il gateway è un punto di concentrazione, deve custodire le credenziali altrui e rincorre per reverse engineering gli stessi protocolli non documentati di prima — quando AOL cambia il proprio server, il transport si rompe finché qualcuno non lo aggiorna.

Implicazioni per chi costruisce un servizio

Per un operatore o un portale che voglia offrire messaggistica, Jabber sposta la domanda. Non è più «di chi è la piattaforma», ma «chi gestisce il mio dominio». Posso far girare jabberd sulla mia infrastruttura, assegnare indirizzi sul mio dominio, federarmi con il resto della rete via dialback, e intanto dare ai miei utenti i gateway verso le reti dove i loro contatti stanno già. Lo streaming XML si presta anche alle estensioni — un namespace iq personalizzato trasporta dati applicativi arbitrari dentro lo stesso canale — e apre la strada a integrazioni come notifiche o ponti verso SMS, costruite come componenti server senza toccare il core. Proprio su questo schema — jabberd più un modulo SMS verso le reti mobili — noze sta costruendo Community con SARITEL, e ne descrive l’impianto in un insight (https://www.noze.it/insights/community-jabber-saritel/).

Limiti

Tre cautele, allo stato attuale del progetto. La prima: il dialback autentica il server, non cifra il traffico — la confidenzialità fra server non la garantisce il meccanismo, va aggiunta sopra. La seconda: la specifica vive come documentazione del protocollo e codice di jabberd, non come standard ratificato da un ente terzo; chi adotta oggi accetta che qualche dettaglio cambi quando la standardizzazione maturerà. La terza: i gateway ereditano la fragilità delle reti che incapsulano e dipendono dalla buona volontà — o dalla tolleranza — dei fornitori proprietari, che non hanno alcun interesse a essere interoperati.

Quel che tiene, e per cui lo seguo, è il modello: indirizzi ancorati al DNS, server indipendenti che si federano, presenza propagata dal server, estensioni trasportate nello stesso stream. Le stesse scelte che hanno fatto dell’e-mail una rete e non un prodotto.

https://xmpp.org/about/history/ https://jabber.org/

Immagine di copertina: Logo ufficiale del progetto Jabber: una lampadina stilizzata di colore rosso e giallo — logo di Jabber Software Foundation, CC BY 2.5 — https://commons.wikimedia.org/wiki/File:Jabber-bulb.svg