Zum Inhalt
Werkstatt Digital
KontaktRSS

Wissen · Redaktion

Jabber und XMPP: Protokoll, JID und Stanzas

Jabber und XMPP erklären: Aufbau einer JID, die drei Stanzas message, presence und IQ, Roster und Abonnements sowie Verschlüsselung mit OMEMO.

A quiet desk in daylight, a laptop screen showing a plain text editor with an XML-like stream, a notebook and a pen beside it, shot from a slight angle, no readable text, no people. Distinct lead composition for this editorial entry.

Jabber ist der ursprüngliche Name eines offenen Messaging-Protokolls, das seit 2004 unter dem Namen XMPP als Reihe von RFC-Dokumenten standardisiert ist. Es arbeitet mit XML-Strömen über eine bestehende TCP-Verbindung und kennt drei Grundbausteine, die Stanzas message, presence und IQ. Wer das Protokoll verstehen will, beginnt beim Aufbau der Adresse, der JID, und bei der Frage, welche Aufgabe jede Stanza im Ablauf einer Sitzung übernimmt.

Was ist Jabber beziehungsweise XMPP?

Jabber entstand Ende der 1990er Jahre als freies Protokoll für den Austausch kurzer Nachrichten. Der Name gehört heute nicht mehr dem ursprünglichen Projekt, das Protokoll selbst wurde 2004 von der IETF als Extensible Messaging and Presence Protocol, kurz XMPP, in den RFC 3920 und 3921 veröffentlicht und später in den RFC 6120 und 6121 überarbeitet. XMPP ist damit kein Produkt eines einzelnen Anbieters, sondern eine Spezifikation, die jeder implementieren darf. Ein Server vermittelt Nachrichten zwischen Clients, mehrere Server können über Föderation direkt miteinander sprechen, ohne zentrale Instanz. Wer die technische Herkunft und die heutige Einordnung nachlesen möchte, findet in dem englischsprachigen Leitfaden Presence und Protocol erklärt eine zusammenhängende Darstellung von der frühen jabberd-Zeit bis zu den aktuellen XEP-Erweiterungen. Für die Praxis bedeutet das: Ein Konto liegt immer auf einem bestimmten Server, die Adresse nennt diesen Server mit, und die Erreichbarkeit hängt nicht an einem einzigen Betreiber.

Wie ist eine JID aufgebaut?

Eine Jabber-ID, abgekürzt JID, folgt dem Muster localpart@domain/resource. Der lokale Teil vor dem At-Zeichen ist der Kontoname auf dem Server, die Domain dahinter benennt den Server selbst, und der Teil nach dem Schrägstrich ist die Ressource. Die Ressource unterscheidet mehrere gleichzeitige Verbindungen desselben Kontos, etwa ein Telefon und einen Rechner. Sie ist frei wählbar und nicht Teil der Identität des Kontos. Eine Nachricht an [email protected] erreicht das Konto ohne Festlegung auf ein bestimmtes Gerät, eine Nachricht an [email protected]/buero dagegen gezielt die Verbindung mit dieser Ressource. Domain und lokaler Teil bilden zusammen die sogenannte bare JID, die vollständige Adresse mit Ressource die full JID. Beim Anmelden sendet der Client zunächst einen Öffnungs-Tag für den XML-Strom, handelt mit dem Server die Version aus und authentifiziert sich, meist über SASL. Erst danach bindet er eine Ressource und kann Stanzas senden. Domainnamen werden über DNS aufgelöst, wobei SRV-Einträge den zuständigen Dienst benennen.

Was leisten die drei Stanzas message, presence und IQ?

XMPP kennt genau drei Arten von Stanzas, und jede hat eine klar abgegrenzte Aufgabe. Die Stanza message transportiert Inhalte, also Text, aber auch Dateiverweise oder Zustellhinweise. Sie ist als Feuer-und-vergessen gedacht, eine Antwort darauf ist nicht vorgesehen. Die Stanza presence teilt den Anwesenheitszustand mit, etwa verfügbar, abwesend oder beschäftigt, und steuert zugleich die Verteilung dieser Information an die Kontakte, die ein Abonnement angelegt haben. Die Stanza iq, kurz für Info/Query, bildet einen Anfrage-Antwort-Austausch ab. Jede IQ-Anfrage trägt eine eindeutige Kennung, der Empfänger antwortet mit result oder error. Über IQ laufen unter anderem die Kontaktliste, die Registrierung, Serverabfragen und viele Erweiterungen. Die drei Typen sind absichtlich getrennt: Zustellversuche, Präsenzsignale und Abfragen haben unterschiedliche Fehler- und Wiederholungslogiken, und diese Trennung hält das Protokoll überschaubar. Ein Client muss alle drei beherrschen, um als vollständig zu gelten.

Wie werden Roster und Abonnements verwaltet?

Der Roster ist die Kontaktliste eines Kontos. Er liegt serverseitig, nicht im Client, und wird beim Anmelden abgerufen. Jeder Eintrag enthält eine JID, einen Anzeigenamen und eine Gruppe. Entscheidend ist das Feld für die Abonnementrichtung: none, to, from oder both. Ein Abonnement bedeutet, dass ein Konto die Präsenz eines anderen empfangen darf, und es gilt immer gerichtet. Wer die Präsenz eines Kontakts sehen will, braucht ein to-Abonnement, also die Zustimmung der Gegenseite. Diese Zustimmung wird über eine presence-Stanza vom Typ subscribe angefragt und mit subscribed bestätigt oder mit unsubscribed abgelehnt. Daraus folgt, dass Präsenzinformation nicht automatisch fließt, sondern Ergebnis einer beidseitigen Freigabe. Der Roster selbst ist über IQ erreichbar, Änderungen werden als set gesendet und vom Server bestätigt. In größeren Installationen kommen serverseitige Regeln hinzu, etwa Sichtbarkeitsbeschränkungen zwischen Domains.

Wie wird XMPP verschlüsselt?

Auf der Transportebene schützt TLS die Verbindung zwischen Client und Server sowie zwischen zwei Servern. Der Client handelt TLS während des Aufbaus aus, bevor Zugangsdaten übertragen werden. Damit ist der Weg gesichert, nicht aber der Inhalt gegenüber dem eigenen Server, denn dieser sieht die Nachrichten im Klartext. Für Ende-zu-Ende-Verschlüsselung wird OMEMO verwendet, eine Erweiterung, die auf dem Doppelratschen-Verfahren aufbaut. OMEMO verschlüsselt Nachrichten pro Gerät, sodass auch der Server den Inhalt nicht lesen kann. Voraussetzung ist, dass die beteiligten Geräte ihre Schlüssel veröffentlichen und der Client die Schlüssel der Gegenseite prüft. Für Gruppen existieren zwei Ansätze: die klassischen MUC-Räume, in denen die Verschlüsselung je nach Client einzeln geregelt wird, und MIX als neuerer Entwurf, der Gruppenverschlüsselung stärker im Protokoll verankert. Daneben bestehen ältere Verfahren wie OTR, die in der Praxis kaum noch eine Rolle spielen. Unabhängig vom Verfahren gilt: Ohne TLS sollte keine Anmeldung erfolgen, und ohne geprüfte Schlüssel bleibt die Ende-zu-Ende-Sicherheit eine Annahme.

Der erste brauchbare Schritt

Für den Einstieg genügt ein Konto auf einem Server, der TLS erzwingt und OMEMO unterstützt, dazu ein Client, der die drei Stanzas korrekt behandelt und den Roster pflegt. Wer die Grundlagen nachlesen will, findet die verbindlichen Texte bei der Internet Engineering Task Force, namentlich die RFC 6120 und 6121 zum Kernprotokoll sowie die RFC 7622 zur Adressierung. Ergänzend dokumentiert die XMPP Standards Foundation die Erweiterungen, darunter die XEP-0384 für OMEMO. Ein Blick in diese Dokumente klärt viele Fragen, die in Clients nur als Schalter erscheinen.

Für den nächsten Schritt hilft Digitale Wissensarbeit ordnen.

Wenn Dateien beteiligt sind, führt Zettelkasten-Methode: klein beginnen.

Als prüfbare Ergänzung erklärt Git für Anfänger.

Der passende Überblick liegt bei Terminal-Grundlagen auf dem Mac.

Prüfstand: 24.08.2026 · Quellen und Methode machen die Grundlage sichtbar. Die Kriterien stehen im Werkzeug-Kompass.

Ein Free-Net war in den 1980er und 1990er Jahren ein öffentlich zugängliches Computernetz, das Bürgerinnen und Bürger über Einwahlknoten, meist in Bibliotheken, mit E-Mail, Foren und lokalen Informationen versorgte. Man nutzte es, indem man sich per Modem einwählte und die Dienste ohne kommerzielle Gebühren verwendete. In Cleveland und Houston entstanden solche Netze aus kommunalen Initiativen, während NPTN und FreePort Organisation und Software bereitstellten. Wer die Parallelen zur heutigen digitalen öffentlichen Infrastruktur einordnen möchte, findet in die Geschichte der Free-Nets eine sachliche Darstellung der Anfänge und der heutigen Rolle von Bibliotheken als Zugangspunkt.