Jabber

Gerade eben im Jabber/XMPP-Support:

[11:35:23] <support@tiggerswelt.net> Du hast gleich einen reconnect...
[11:35:30] *** Kunde (xxxxxx.de) ist Offline

Hintergrund der Sache: Ich hatte einen Neustart des Jabber-Instanz des Kunden bei uns veranlasst, da er mich um ein selbst signiertes SSL-Zeritifkat für die Client-Verbindungen zum Jabber-Server erfragt hatte.

Eine der Sachen, die man mir negativ zur Last legen könnte, ist der Umstand, dass ich manchmal so wahnsinnig viel an so wahnsinnig vielen verschiedenen Dingen arbeite - das weiß ich! Um so schöner ist es dann doch, wenn man spontan ein paar dieser vielen Dinge nimmst und sie in einem kleinen Stück Software miteinander verbindet.

So geschehen an der Nacht von Samstag auf Sonntag, als die Dame des Herzens bereits am Schlafen war und mich so eine Lust überkam irgendwas zu "arbeiten". Man nehme also die XML-Stream-Komponente aus meiner XMPP-Library und verknüpfe sie mit der HTTP-Server-Komponente meiner Event-API und erhalte einen "BOSH-Dienst" frei nach XEP-0124!

Sehr toll!

Da ich jedoch noch nicht sonderlich viel Zeit rein investiert habe, kann das Ding noch nicht viel, so fehlen z.B. jegliche Timeouts, sodass Sessions die nicht explizit geschlossen werden für immer bestehen bleiben. Aber das bisherige Ergebnis hat mich irgendwie so erfreut, dass ich bestimmt noch die eine oder andere Nacht hier investieren werde.

Mit Hilfe von jQuery UI und Strophe.js habe ich dann noch einen kleinen XMPP-Client in HTML5 gebastelt, der immerhin schon Nachrichten senden und empfangen kann.

So ist es dann wieder sinnvoll über die Zeit "viele kleine Dinge" zu bauen, wenn man sie später zu "etwas größerem zusammensetzt".

Sofern es meine Freizeit es in den vergangenen Wochen zuließ - und das war echt selten - habe ich mich daran gemacht einen abstrakten Gateway zu basteln, d.h. ich habe ein Stück Software geschrieben, das eine einheitliche API bereitstellt um einen IM-Gateway für XMPP zu bauen. Ich habe sowas ja schon mal für ICQ gebaut, das war mir aber zu sehr spezifisch bzw. zu wenig für andere Zwecke anpassbar.

Einen ersten Testfall habe ich gestern Abend bei einem schönen Glas Wein gleich mal ausprobiert:
Ich habe den Gateway gegen eine abart von Skype-Library laufen lassen und war doch prompt im Stande Präsenz-Informationen auszutauschen und über Skype zu chatten.

Bevor jetzt aber jeder schreit "Wir haben einen Skype-Transport!" - ein paar Nachteile hat die Sache dann doch: Ich kann mich nur mit "Skype for Business"-Accounts verbinden, "Skypen" bzw. Telefonieren geht natürlich nicht, es kostet Lizenzgebühren, die Zukunft von Skype ist ungewiss - besonders was das Linux-Umfeld angeht - und irgendwie fühle ich mich auch nicht sonderlich danach es Open Source zu machen. Es wird wohl mehr eine private Spielerei bleiben. Aber trotzdem erwähnenswert :) 

Vor zwei Jahren hatte ich es schon einmal hier im Blog:

Jabber-Präsenz API

Und es hat doch tatsächlich so lange gedauert bis ich mich dazu hab überreden lassen, es für alle Jabber/XMPP-Nutzer bei uns zugänglich zu machen.

Auslöser war wie so häufig das einfache Nachfragen eines Kunden, ob es sowas bei uns gibt und dann das herausfordernde "Geb mir kurz mal 10 Minuten" - und es hat tatsächlich nur 10 Minuten gedauert. Wesentlich anstrengender war es dann das ganze noch ins Wiki zu schreiben. 

In der Diskussionsrunde nach meinem Vortrag am Donnerstag wurde unter anderem nochmal der Wunsch nach einem serverseitigen Gesprächsverlauf um nicht bei einem Wechsel des Clients oder Gerätes zerschnittene Protokolle zu haben.

Nun gibt es bereits XMPP-Dienste, die sowas über eine eigene Oberfläche ermöglichen, es stellt sich aber immer die Frage, ob man will dass die Betreiber der selbigen (offiziell? ) die eigenen Konversationen mitloggen. Der interessierte Geek wird sowieso lieber selber loggen wollen bevor er irgendwem anderes die Macht über seine Daten gibt.

Mir ist das Thema im Kopf geblieben und ich als Geek wollte in dem Fall einfach nur mal spielen.

Heraus gekommen ist dabei eine Jabberd2-Komponente, die sich als "logging sink" am Server anmeldet und Konversationen ganz stupide auf die Festplatte schreibt - natürlich nur sofern dies auch gewünscht wird. Andernfalls wird alles bedingungslos verworfen.

"Gewünscht werden" ist in diesem Fall recht simpel: Der Dienst stellt fest, wem eine Nachricht gehört ("owner") und wer sein Gegenüber ist ("opponent") und schaut nach ob ein Verzeichnis "history/owner/" existiert - wenn dem so ist, wird gelogged.

Die viel spannendere Frage ist dann aber eher, wie man an die Mitschnitte seiner Gespräche kommt. Zwar existiert mit dem XEP-0136 bereits ein Entwurf zum Archivieren von Nachrichten, allerdings ist es wie erwähnt im Monent lediglich ein Entwurf, kaum ein Client unterstützt die Erweiterung und es wird explizit darauf hingewiesen, dass dieser Ansatz noch zu überarbeiten ist. Schade!

Ich habe mich folglich für einen Mix aus Service Discovery (XEP-0030), Ad-Hoc Commands (XEP-0050) und Delayed Delivery (XEP-0203) entschieden und auch über In-Band Registration (XEP-0077) nachgedacht. In der Summe ist es nicht wirklich schön geworden, aber es funktioniert.

Gerade wenn man sich den Teil bestehend aus Service Discovery und Ad-Hoc Commands anschaut und das "Replay" von Gesprächen mal außen vor lässt ist es eigentlich noch schön anzugucken:

Der Dienst erscheint als Service unterhalb der eigenen Domain. Sofern bereits Gesprächspartner existieren, werden diese nach Jabber-ID sortiert direkt als Knoten unterhalb des Dienstes angezeigt. Unterhalb dieses Knotens findet man dann die Gespräche nach Datum sortiert.

Mit den Ad-Hoc Commands kann man die Protokolle dann nochmal lesen oder direkt vom Server löschen lassen. Wobei ersteres irgendwie noch Ekelhaft ist:

Der Dienst (in diesem Fall "logger") schickt Chat-Nachrichten an den Eigentümer der Konversation und stellt die jeweilige Jabber-ID des ursprünglichen Absenders voran. Delayed Delivery hilft dabei den ursprünglichen Absender und Zeitstempel mit zu übertragen - letzteres wird aber längst nicht von jedem unterstützt und hat gerade beim "ursprünglichen Absender" immer irgendwo ein Geschmäckle.

Der Dienst ist keine propietäre Erweiterung, die ich bei mir in der Schublade verschwinden lassen würde. Im Gegenteil:
Er befindet sich in den Code-Beispielen meiner XMPP-Library, da es eigentlich nur ein Interface für die Logging-Sink-Variante der Jabberd2-Komponente ist - somit Open-Source und für jedermann nutzbar. Wenn man denn will.

Anders herum weiß ich gar nicht, ob ich so eine Komponente im produktiven Einsatz haben möchte. Wenn man sich ein Webinterface dazu denkt, eigentlich ne super Sache, aber son bisschen Geschmack nach Stasi & Co. hab ich dann schon im Mund.
Vielleicht wartet man hier einfach besser bis das Message Archiving (XEP-0136) als Standard abgesegnet wird, da wird dann ja auch geregelt wie der Nutzer über eine etwaige Protokollierung seiner Unterhaltungen zu informieren ist. Bis dahin sei sowieso jedem GnuPG oder OTR ans Herz gelegt.

Wer heute Abend noch nichts vor hat und zufällig in der Region Stuttgart ist, ist herzlich eingeladen in die Stadtbücherei zu kommen und der Vortragsreihe des Chaos Computer Club Stuttgart (CCCS) beizuwohnen.

Thema heute:

IRC trifft Jabber - Wie XMPP ein weiteres Protokoll konsolidiert

Der Referent bin zufälligerweise ich selbst und ich traue mich das, weil wir ja gerade selbst kräftig an einer MUC-Komponente bauen.

Als ob ich nicht schon Panik genug vor dem Publikum dort hätte, würde ich mich natürlich freuen den einen oder anderen Blogleser und/oder Kunden im Publikum wiederzufinden. Für alle die nicht dabei sein können gibt es im Anschluss einen Audio-Mitschnitt und natürlich meine Vortragsfolien.

... die ich noch übelst kürzen muss. Ich soll mich kurz fassen hat Myriam gesagt und ich soll langsam und deutlich sprechen hab ich mir gesagt.

Wir suchen gegenwärtig nach interessierten Kunden, die mal den Gegenwärtigen Zustand unserer Multi-User-Chat-Komponente samt Anbindung ans Kundeninterface testen möchten.

Super wäre natürlich eine bereits vorhandene Jabber/XMPP-Domain bei uns im Hause, sofern mindestens eine "normale" Domain vorhanden ist, kann man den aber natürlich noch ergänzen. Tiefgreifendere Kenntnisse oder Erfahrungen mit mit dem Multi-User-Chat (XEP-0045) sind wünschenswert.

Bei Interesse einfach per E-Mail melden.

Seit heute betreiben wir (wie schon einmal angedroht) auf unserem Jabber/XMPP-Server eine c2s-Komponente, die alle bei uns gehosteten Domains bedient und auf den wohlbekannten Standard-Ports 5222 und 5223 (klassisches SSL) horcht.

Für ganz restriktive Umgebungen haben wir noch die Ports 80 (HTTP) und 443 (HTTPS) hinzugefügt. Damit sollte der Dienst wohl für alle Nutzer von überall erreichbar sein. Auf den von vorne herein verschlüsselten Ports liefern wir unser SSL-Zertifikat für ssl.tiggerswelt.net aus - das ist nicht direkt schön, aber offiziell signiert. Für die modernere StartTLS-Variante funktionieren die jeweiligen Kunden-/Domain-spezifischen SSL-Zertifikate bzw. wieder unser SSL-Zertifikat als Fall-Back.

Einziger Nachteil bei dieser Variante: Änderungen auf Kundendomains spielen wir maximal alle 2 Stunden ein. Das bedeutet zum einen, dass Änderungen an der XMPP-Konfiguration wie z.B. verwendetes Zertifikat, Passwort-Änderungen oder Benutzer-Registrierung werden nur stark verzögert übernommen. Zudem kann es dann entsprechend im "worst case" zu einem Disconnect aller Nutzer auf dieser Komponente kommen.

Ich bin mal gespannt, wie viele die neue Variante nutzen werden und wie oft da tatsächlich neu gestartet wird.

Ich habe gestern nun endlich aktiv damit begonnen, unseren Jabber/XMPP-Server um eine MUC-Komponente zu erweitern.

Ein wenig überrascht war ich schon, denn bevor ich zur eigentlichen Arbeit gekommen bin, hagelte es erst einmal ein paar Patches für meine Event-Bibliothek, meine XMPP-Komponente und natürlich auch die recht generische MUC-Implementation von mir.

Am Ende des Tages war ich dann aber doch recht zufrieden und fast schon wieder im Arbeitsrausch. Die Sache mit dem Klappe halten hat bei einem kurzen Test auf unserem Produktiv-Server recht gut funktioniert, wenngleich mich die 700 KB an Traffic überrascht haben, die bei einem einfach Start der Komponente mit Authentifizierung und dem Bekanntmachen mit anderen Komponenten auf dem Server (presence und Service-Discovery) verbraten wurden.

Was jetzt noch fehlt ist das dynamische Hinzufügen und Entfernen von MUC-Domains und alles, was so zu einem Chat-Raum dazu gehört - wobei beides wohl weniger ist, als es klingt - und natürlich jede Menge Ideen, die das Ding einzigartig machen

Wer schon eine Jabber/XMPP-Instanz bei uns hat und an einer Public-Beta interessiert ist, darf mich gerne mal anschreiben.

Wir betreiben ja bekanntlich einen Jabber/XMPP-Server mit einigen Domains unserer Kunden.

Vergangene Woche kam hierzu die Frage auf, ob es eigentlich möglich ist, hier eine Komponente anzuschließen, die nicht bei jeder Domain (in der Service-Discovery) als verfügbarer Dienst angezeigt wird. Gerade wenn es darum geht personalisierte Dienste auf den Domains der Kunden oder speziell gebuchte Dienste für einen speziellen Kunden anzubieten.

Die Antwort hierauf ist recht einfach: Ja, es geht!

Ganz egal, ob die Komponenten mittels XEP-0114 oder mit dem nativen Component-Protocol des Jabberd2 (bzw. hier sobald eine Domain gebunden wird) an den Server "angeschlossen" werden, der Router sendet immer einen <presence>-Tag an alle anderen Komponenten, darunter auch die Session-Manager für die Kundendomains. Diese veranlassen daraufhin eine Service-Discovery, deren Ergebnis sie zwischenspeichern und bei eingehenden Anfragen einfach weiterreichen. Wenn wir also nicht wollen, dass ein Dienst unterhalb einer bestimmten Kundendomain angezeigt wird, unterlassen wir einfach Service-Discovery-Antworten an diese Domain.

Schade nur, dass ich selbst auf die Idee kommen musste und mir eigentlich keine Komponente auf dem freien Markt bekannt ist, die so eine Funktionalität von Haus aus anbieten würde. Egal, ich muss das Rad ja sowieso immer neu erfinden

Ich bin heute morgen recht früh aufgewacht und schaffte es nicht weiterzuschlafen. Aus etwas Verzweifelung heraus bin ich dann also aufgestanden und habe erst einmal alles fürs Frühstück vorbereitet. Da ich dann aber immernoch ca. anderthalb Stunden bis zur Sendung mit der Maus hatte, habe ich mich an XEP-0045 heran gemacht.

Das besagte XEP beschreibt den "Multi-User-Chat" für XMPP/Jabber, also die Möglichkeit auf einem XMPP-Server einen Chatraum aufzumachen und eine Konversation mit mehr als zwei Teilnehmern zu führen. Das XEP zu lesen steht schon seit gefühlten 2 Jahren auf meiner ToDo, aber irgendwie erschien es beim ersten Blick immer so aufgebläht und riesig. Doch falsch gedacht! Auch dieses XEP ist nur mit Wasser gekocht und in den meisten Stellen recht trivial.

Ich habe es mir nicht nehmen lassen während des Lesens einfach mal eine Test-Implementation auf Basis meiner bereits vorhandenen XMPP-Bibliothek zu schreiben. Hat super funktioniert und ist mit minimalem Funktionsumfang (ohne Administration oder Moderation) absolut lauffähig. Das bringt uns dem Thema auch Chaträume auf unserem XMPP-Server anzubieten etwas näher, wobei sich dann die Frage stellt, ob man eine bestehende Lösung nimmt oder gleich auf den Eigenbau setzt.

Schlussendlich habe ich ca. 30 KB Code (und größtenteils Kommentare und Leerzeichen) in knapp 2 Stunden generiert. Wenn ich bei dem Tempo bleibe, überhole ich noch die Ergebnisse der Google Summer of Code Meinen Code gibt es btw. wie so oft als CC BY-SA hier - sollte es irgendwen interessieren.

Letzten Freitag haben wir ein Update auf unserem Jabber-Server vorgenommen, wodurch sich ein paar nette Features ergeben haben.

Eines davon ist z.B. das Abfragen des Online-Statuses in Echtzeit ohne dabei mit Jabber verbunden zu sein. da diese Informationen nicht jeder freigeben will, geht das vorerst nur für unseren Support:

http://api.tiggerswelt.net/xmpp/status/support@tiggerswelt.net

Das Ausgabe-Format ist hierbei an das "normale" presence-Format wie man es von XMPP gewöhnt ist angelehnt. Hinzu kommt noch Support für XEP 256

Heute habe ich zwei kleine Produkte aus unserem Portfolio eine Symbiose eingehen lassen, indem ich unseren SMS Gateway mit unserem Jabber-Dienst verbunden habe.

Die Idee ist sicherlich nichts neues und findet schon vielerorts Anwendung (leider nicht über uns ), allerdings kann meine Implementation etwas, was ich - bis mich jemand eines besseren belehrt - als einmalig bezeichnen würde: Schicke ich über Jabber eine SMS-Nachricht raus kann der Empfänger der Nachricht mit seinem Handy auf die Nachricht per SMS antworten und die Antwort erscheint wieder bei Jabber. Ich würde das einen "Bi-Direktionalen SMS Transport" nennen oder auch "unified chatting"

Leider musste ich feststellen, dass sich die Konversationen dank lästiger SMS-Tipperei am Handy schon mal etwas hinziehen können. Kaum auszudenken was passiert, wenn das Gegenüber gerade nicht auf dem Sofa sitzt und darauf wartet zurückzuschreiben sondern wild durch die Weltgeschichte dümpelt und nicht sofort zurückschreibt. Eine echte Geduldprobe vor dem Bildschirm wie man es vom chatten sonst wohl nicht gewohnt ist.

Für den Moment ist der Gateway noch in der Testphase und steht nicht für die breite Kundschaft bereit. Aber wer weiß, was daraus noch wird

Neulich bei Jabber:

Man darf gespannt sein!

Von allen Protokollen, mit denen wir so täglich umzugehen haben, empfinde ich XMPP (Jabber) irgendwo als das unhandlichste.

Zwar ist XMPP mit seinem XML-Format sehr leicht zu lesen, allerdings geben die Protokolle auf dem Server oftmals nicht sonderlich viel her, was zum debuggen nützlich wäre. Man könnte vielleicht drüber nachdenken, den Jabber-Server mal im Debug-Modus zu starten, allerdings muss man dafür die Software erst einmal herunter fahren. Man könnte auch überlegen sich den IP-Traffic anzuschauen, der während des Betriebes generiert wird, allerdings wird der großzahl unserer s2s-Verbindungen (Server-zu-Server) von Haus aus verschlüsselt und mit den c2s-Verbindungen (Client-zu-Server) gibt es eher selten Probleme - ganz nebenbei empfehlen wir auch hier eine Verschlüsselung der Verbindung.

So habe ich mir über die Jahre immer mal wieder ein paar Spielzeuge gebastelt, mit denen ich unabhängig vom laufenden Betrieb s2s-Verbindungen testen kann. Eines davon provoziert einen Server-Dialback nach XEP 220, so wie es im Normal-Betrieb mittlerweile üblich ist, um die authentizität eines Jabber-Servers zu ermitteln, und hat mir heute wieder einen guten Dienst erwiesen.

... dummerweise teilen nicht alle Jabber-Server mit woran der Dialback scheiterte, so blieb mir diesmal nichts anderes übrig, als mal bei den Serverbetreibern nachzufragen, woran es denn gescheitert sein könnte.