Jabber

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.

Angetrieben durch die geplanten Veränderungen am Jabber-Server habe ich gestern Nacht mal wieder meine kleine PHP-Jabber-Klasse rausgekramt und rumprogrammiert. Neben ganz kleinen Veränderungen am ursprünglichen Code habe ich auch ein paar XEP's eingebaut, die da wären:

• XEP 0012 Last Activity
• XEP 0078 Non-SASL Authentication (war schon drinne, ich schreibs aber trotzdem)
• XEP 0090 Entity Time
• XEP 0092 Software Version (war auch schon drinne, jetzt aber verfeinert und BESSER)
• XEP 0114 Jabber Component Protocol (als neuen Stream-Typ)
• XEP 0199 XMPP Ping (auch als Replacement für das Whitespace keep-alive)

Als nächstes steht eigentlich das XEP 0030 (Service Discovery) auf dem Programm, allerdings baue ich vorher noch ein wenig die ganze Klasse um, sodass die besser mit XML-Namespaces umgehen und einfacher um das eine oder andere XEP erweitert werden kann...

Bleibt eigentlich nur noch die Frage, wann die mal endlich produktiv zum Einsatz kommt und ich z.B. das Projekt hier mal wieder aufgreife.

Für Interessierte: Die Klasse gibts hier!

Wer braucht eigentlich noch Supporter, wenn man einen cooooolen Jabberbot hat?

Nachdem das alte Interface ein wenig statisch war und kaum jemand es wirklich ausgenutzt hat - mit "wirklich" meine ich z.B. mehrere Domains auf einmal gechecked - habe ich mich eben ein wenig im Menschenverstehen geübt:

Der Bot versucht jetzt aus den Sätzen vom potentiellen Kunden zu interpretieren, was genau gewollt wird. Und noch besser: Es ist ein wenig Sessionbasiert, d.h. Infos aus dem letzten oder auch vorletzten Satz (sollten) nicht verloren gehen, sodass der Bot auch im Zweifel herausbekommt, was gewollt ist...

Für etwaige Gefühlsausbrüche ist btw. auch vorgesogt...

Ich spiele gerade (mal wieder) mit meinem Jabber-Client, vielmehr dessen Kunden-Frontend herum.

Ziel momentan ist es, sich mit dem Kunden "zu unterhalten", d.h. ihn wiederzuerkennen und zwischen den Sätzen zu wissen, was er alles will. Quasi wie ein "Warenkorb" im Online-Shop. Da ich mir die XMPP-Spezifikationen schon einmal durchgelesen habe, weiß ich, dass Jabber rein theoretisch "Threads" oder auch "Sessions" unterstützt.

... zu schön wäre es gewesen, die auch benutzen zu können. Aber das scheitert schon am zweiten Schritt: Psi, mein Jabber-Client, kennt diese Funktion nicht Verdammt... Aber wer will schon gleichzeit zwei Gespräche mit ein und dem selben Bot führen?

Ansonsten kann die darunterliegende PHP-Klasse jetzt auch (Un)Subscribe-Requests verarbeiten. Den einen oder anderen wird das freuen
... ob ich irgendwann die aktuellste Version auf den Server lade, mal schaun

Zugegeben: Es ist ein wenig abgefahren, was mir da letzte Nacht durch den Kopf schoss, aber es ist eine recht leicht zu implementierende Technik und in der Theorie tut sie genau das, was sie soll...

Ich denke die letzten Tage (eigentlich auch schon Monate) verstärkt über das "Zusammenschalten" von Netzwerken nach, konkret eigentlich nur über das dahinterliegende Routing. Weiter habe ich mir auch dabei Gedanken über Redundanz gemacht und den Fall, dass einer dieser angedachten Gateways mal ausfällt. Oder ganz abgefahren: Das ein Netz über einen bestimmten Router erreicht wird, eine IP aus diesem Netz aber gerade nur über einen anderen angesprochen werden kann - grob könnte man sich das mit mehreren WLAN-Zellen veranschaulichen, die im WLAN das selbe Netz teilen, jedoch über ein anderes miteinander verbunden sind. Effizient ist es da ja, wenn der zentrale Router immer weiß, wo sich gerade ein WLAN-Client befindet und dementsprechend das Packet verschickt.

... ist vielleicht alles ein wenig um die Ecke gedacht, zumal es auch schon genug Routing-Protokolle für den Austausch solcher Informationen gibt....

Aber ich bin ja doof und muss das Rad immer wieder neu erfinden. Gestern habe ich meinen kleinen Jabber-Client hergenommen und einen Routing-Client draus gebaut. Klingt eigentlich doof, funktioniert aber recht gut:

Jeder Router ist ein Jabber-Client. Sofern sich seine Routen ändern, sei es, dass sich jemand in das Netz einloggt o.ä., sendet der Client eine Jabber-Nachricht an seine benachbarten Jabber-Clients (ähhh Router) die Ihrerseits diese Routing-Regeln übernehmen. Und voila: Das routing funktioniert sogar!

Schön dabei ist: Das ganze ist auf einer offenen und flexibelen IM-Plattform implementiert. Demnach könnte eigentlich jeder mitmachen.

Schade nur: Man braucht einen Jabber-Server in der Mitte, der von allen erreicht werden kann. In meinem Falle geht das ja noch. Aber den großen Netzen könnte man diese Lösung nicht verkaufen

Angedacht, quasi als weiterentwicklung, ist z.B. auch das Verteilen der Routen via Pubsub - dann wirds richtig krank