Last-Crusade.de – The Empire Writes Black Stories of these dark and modern days…

4Aug/1269

XMPP – (M)eine Einschätzung und Prognose

Im folgenden Beitrag möchte ich meine persönliche Einschätzung zum aktuellen Stand um XMPP sowie eine subjektive Prognose abgeben. Das Ganze ist als "IMHO" zu betrachten und mag natürlich voll daneben liegen.

Zunächst einmal der Stand Mitte 2012:
ICQ scheint in Deutschland langsam auszusterben. Vermutlich ist das zu weiten Teilen ein Resultat ihrer 'tollen' Clients. MSN und Yahoo kann ich schwer einschätzen, werden aber auch stark an Nutzern verlieren. Und zwar an Facebook. Ja, die Kommunikation der Menschen scheint sich immer mehr auf diese Plattform zu verlagern. Ich werde es mir an dieser Stelle einmal verkneifen zu schreiben, warum ich das vor Allem aus datenschutzrechtlicher Sicht absolut daneben finde.

Nun, so ist also die Situation bei dem Feind - äh bei den anderen IM-Netzwerken wollte ich schreiben. XMPP ist ein Nischenprotokoll. So manch einer kennt es, manche nutzen es sogar. Und damit meine ich jetzt nicht wirklich die Nutzer vom Facebook Chat und MSN, die wohl mittlerweile unter der Haube zwar XMPP verwenden, aber sich nicht für andere Server öffnen. Nein, ich meine die Nutzer, die auf einem freien Jabber Server ein Nutzerkonto haben und alle Vorzüge dessen genießen können. Nun, was kann man machen? Andere anhauen, ebenfalls darauf zu setzen! Teilweise zahlt sich sogar die Hardliner-Mentalität (Jabber oder eben nicht chatten) aus. Aber das ist gewiss nicht für jeden der richtige Weg. Sehr gute Gründe für den (schleichenden) Wechsel gibt es genug, auch hierauf will ich hier nicht noch einmal eingehen.
Doch was muss sich an der Softwarefront noch tun? Hier liegt noch viel Potential brach. Fangen wir bei den Clients an:
Das von mir präferierte Psi(+) Projekt dümpelt vor sich hin und ist nicht gerade offen für Vorschläge und eigene Beiträge (zumindest, wenn man sie nicht in russisch präsentiert). Gajim erscheint brauchbar, aber ich hatte hier und da schon Abstürze und unerwünschtes Verhalten, das einfach keinen guten Eindruck macht. Der schlanke Swift Client entwickelt sich im Schneckentempo. Es fehlt z.B. noch an einer Gesprächschronik (ist schon in Arbeit, ich weiß, aber das ist echt ein elementares Feature..) und seit der Beta Version 2.0 hat sich auch nichts mehr groß getan, wenngleich die Arbeiten an 3.0 bereits weitergehen. Pidgin, der Universalclient und vermutlich wichtiges Sprungbrett zum 'Endsieg' der Verbreitung des XMP Protocols funktioniert zwar. Aber eine richtige Weiterentwicklung mit Funktionen wie Message Receive Receipts oder gar Stream Management ist nicht abzusehen.
Bei der Server Software sieht es meines Erachtens auch nicht signifikant besser aus. Eine gewisse Ausnahme bildet nur Prosody. Hier wird zwar auch schon lange an Version 0.9 gearbeitet, aber es geht wenigstens voran und Version 0.8 ließ bereits wenig Wünsche für den Normalbetrieb offen. Stabil, flott mit freundlicher Unterstützung im Entwickler-Chat habe ich an meinem Favoriten wenig auszusetzen. Die anderen Kandidaten beobachtete ich nicht mehr so genau, daher nur ein grober Abriss. Die ejabberd Entwicklung ist gähnend langsam und es kommt mir so vor, als wenn man sich mehr auf die Unternehmenswünsche konzentrieren würde. Stream Management mögen die Entwickler wohl nicht und implementieren es daher auch nicht, was sehr schade ist. Ihr eigener Gegenvorschlag dazu lässt seit geraumer Zeit auf sich warten. Auch Tigase und OpenFire dümpeln vor sich hin. Mit OpenFire gab es immer wieder Probleme hinsichtlich des Verbindungsaufbaus zu anderen Servern.
Sehr ärgerlich ist der instabile Zustand von Jabber.org, welches eigentlich ja das Flaggschiff und erster Anlaufhafen für der XMPP Gemeinschaft für Einsteiger bei Jabber sein sollte. Verbindungsverluste häufen sich hier. Mir erscheint die eingesetzte proprietäre M-Link Software daher irgendwie nicht auch noch "so ganz optimal". Auch jabber.ccc.de hatte immer wieder kleinere Probleme, über die sich die Nutzer beschwerten. Ich weiß jetzt nicht, wie oft dies passiert, aber ich glaube im Allgemeinen hält es sich derzeit noch im Rahmen. Dennoch wäre eine höhere Verfügbarkeit wünschenswert. Das alles wäre mit einer Integration von dem oben bereits genannten Stream Management in Servern und Clients oder zumindest Message Receive Receipts in den Clients zumindest weniger frustrierend für die Anwender.

Was die Verbreitung von Jabber richtig voran würde, wäre eine Öffnung von beispielsweise MSN oder ICQ (bei FB habe ich die Hoffnung da schon komplett aufgegeben) zu anderen XMPP-Anbietern. Es spricht meiner Meinung nach für sie wenig dagegen. Aber ob und wenn überhaupt wann dies geschieht, steht in den Sternen.

Zuden braucht es noch viel Mund-zu-Mund Propaganda. Vielleicht wird ja auch mal einer der Populär-TV-Sender im Kontext von neuen Datenschutzskandalen bei FB und Co. von dieser offenen Alternative berichten. Aber bis das soweit ist, müssten die verfügbaren Clients hier und da - Manche mehr und Andere weniger - nachbessern. Die Entwicklung darf nicht einschlafen, aber laufend neue halbgare Clients bringen auch nichts. Gerade der Mobilbereich braucht noch eine State of the Art - App für XMPP.

Nun, sieht es also düster aus für Jabber? Nun, ein heller Stern am Himmel wäre jedenfalls kein Fehler. Aber ich vertrete immer noch die Auffassung, dass sich XMPP irgendwann durchsetzen wird - vor allem, wenn die softwareseitige Unterstützung besser wird. Es ist ja nicht so, dass es unbenutzbar ist, ganz im Gegenteil. Ich bin seit Jahren mit meinem Psi+ in Jabber unterwegs und mittlerweile auch schon fast zwei Jahre auf einem eigenen (Prosody) Server. Es hat sich derweil einiges getan und ich bin wirklich weitestgehend zufrieden. Aber für den Massenmarkt des Nutzers von Heute braucht es eben noch ein wenig mehr. Ich denke, unter der Haube werden immer mehr Dienste auf XMPP setzen. Inwieweit sie diese aber öffnen, ist die relevante Frage. (Leicht übertrieben formuliert: Ich will ja nicht von parasitärem Verhalten sprechen, aber so kommt mir das teilweise vor 😉 )

Also, wie sieht meine persönliche Prognose aus? Zweitausendzwölf wird XMPP nicht den Durchbruch bringen, vielleicht auch noch nicht 2013. Aber spätestens 2014 geht es - gesetzt den Fall, dass die Software sich bis dahin entsprechend weiterentwickelt hat - bergauf und die Nutzerzahlen werden signifikant steigen.
Jeder weiterer Nutzer ist ein Gewinn, überzeugt in eurem Umfeld Menschen dazu (Datenschutz, Verschlüsselung und unabhängige Offenheit ohne kommerziellen Hintergrund sollten doch gute Argumente sein?!), jabber eine Chance zu geben. Und unterstützt sie anfangs dabei. 😉

So, das war jetzt mein Senf zum Thema.

3Aug/11566

ejabberd zu Prosody: Migration & Konfiguration

Endlich habe ich mein lange geplantes Projekt umgesetzt und meinen ejabberd-Server durch einen Prosody ersetzt. Hier eine kurze Übersicht für andere, die diesen Schritt auch planen.

Hintergründe - Warum der Wechsel?

Mein ejabberd hat mir in letzter Zeit immer öfter "consuming too much memory"-Fehlermeldungen gebracht, das hat mich ziemlich genervt (war aber vermutlich eine Konfigurations-Sache). Zudem hat der werte ejabberd immer wieder Einstellungen "vergessen", was ziemlich ärgerlich war. Kurzum, er war schon immer ein wenig zickig und von der Konfiguration her stellenweise nicht sehr entgegenkommend (mag hier und da mein Fehler gewesen sein). Zudem ist ein Stream Management-Plugin nicht in absehbarer Zeit zu erwarten.

Warum Prosody?

Nun, Prosody ist relativ neu (2008) und sehr schlank, dafür umso einfacher zu erweitern. Da der/die Entwickler anderen gegenüber sehr offen sind, hat sich ein gesundes Ökosystem an Modulen gebildet. Eines davon hatte es mir besonders angetan - Überraschung - : Stream Management. Endlich ist es möglich, auch bei schlechter Verbindung verlässlich zu kommunizieren! :-)

Was darüber hinaus wirklich spitze ist, ist der Support, den einem die Leute im MUC bieten - ich habe einige Stunden hier verbracht und eine Hand voll Leute haben sichwirklich viel Mühe gegeben (und sie waren Erfolgreich *g*), meine Fragen bestmöglich zu klären - danke nochmals!!

Installation Prosody - Mein Vorgehen

Während der ejabberd noch friedlich auf dem Server arbeitete, begann die Revolution. Es empfiehlt sich bei Debian-Systemen auf das Repository von prosody (Übersicht hier) zurück zu greifen, da hier immer die aktuellste Version zusammengeschnürt wird (0.6.1 in den ubuntu-Repos versus 0.8.2 in den Prosody-Repos).

Im Anschluss sollte man sich die Konfig-Datei  /etc/prosody/prosody.cfg.lua zu Gemüte ziehen. Sie ist glücklicher Weise recht schön dokumentiert. Hier muss man als erstes den Host auf die eigene Domain ändern. Bei der Verwendung von self-signed-certificates kann man zunächst einmal das aus der Konfiguration weiter oben kopieren und später ein neues erzeugen.

Ein weiteres Detail, das man beachten sollte ist, dass der Nutzer unter dem Prosody läuft auf /var/lib/prosody/* vollen Schreib- und Lesezugriff haben muss. Um herauszufinden, ob etwaige Probleme, z.B. mit den MUC-Bookmarks (nicht les- oder beschreibbar) daran liegen, kann man unter /var/log/prosody/prosody.log bzw. prosody.err nach Fehlermeldungen mit "Permission denied" schauen. Bei mir ist das jedenfalls der Fall gewesen, lies sich durch die Rechtevergabe auf den Ordner aber  schnell beheben.

Migration ejabberd => Prosody IM

Nun, natürlich wollte ich die Nutzeraccounts samt allen Einstellungen und gespeicherten Daten erhalten. Glücklicherweise gibt es von den Prosody-Leuten hierfür ein Script, das sehr gut funktionierte: http://prosody.im/files/ejabberd2prosody (Update: Jens hat im Kommentar unten auf das Script bei Github verwiesen. Es ist rund 1.100 Zeilen kürzer und wohl einiges aktueller. Ich habe es selbst nicht getestet, bei ihm scheint es ja funktioniert zu haben - daher hier der nochmal sein Link: https://github.com/bjc/prosody/blob/master/tools/ejabberd2prosody.lua ). Auszuführen ist es in /var/lib/prosody/. Zunächst muss man jetzt auf der Konsole mittels
ejabberdctl dump filename.txt
die Daten aus der Datenbank von Ejabberd exportieren (sollte nicht die Standard-DB verwendet werden, weiß ich nicht, ob es geht -> an den Prosody MUC wenden). Das Migrations-Script führt man mittels
lua ejabberd2prosody pfadZurExportiertenEjabberdDatei
aus.
Zu beachten ist, dass der Pfad wo die Dateien hin sollen vom Skript nicht richtig erkannt werden kann und man ggf. noch den Ordner verschieben muss.
Das Skript hat bei mir alles übernommen, es hat sich nur an einer Stelle etwas verschluckt: meine hoch geschätzten Notizen (Storage-Notes) konnten nicht von Psi+ (hab es auch mit Miranda IM getestet) geladen werden. Hier knallte es irgendwie. Wer die Notizen wieder richten möchte, kann folgendermaßen vorgehen: Das private XML liegt unter /var/lib/prosody/<host>/private/<nutzername>.dat.
Das Problem (ich saß da echt 'ne Weile dran, bis ich endlich darauf kam) liegt darin, dass hier leere Attribute = {} gesetzt werden, was irgendwie nicht interpretierbar ist. Wenn man alle leeren geschweiften Klammern durch zwei Anführungszeichen ("") ersetzt, sollte es gehen. Darüber hinaus fügt Prosody bei neuen Notizen immer den Namespace hinzu, daher habe ich das auch gemacht:

["attr"] = {};

bzw.

["tags"] = {};

wurde somit zu

["attr"] = {
["xmlns"] = "http://miranda-im.org/storage#notes";
};

bzw.

["tags"] = "";

Dann ist alles wie gehabt vorhanden und man kann munter weiter damit arbeiten. Könnte man sich auch ein nettes kleines Script basteln, aber den Aufwand war es bei mir nicht wert (genau genommen war es auch den von mir betriebenen nicht wert, weil es nur um meine eigenen Notizen ging, aber egal *g*)

Module

Neue Module werden unter /usr/lib/prosody/modules abgelegt und in der oben bereits erwähnten Konfigurations-Datei aktiviert.

Wer Stream Compression nutzen will (bietet sich bei dem nicht gerade sparsamen XMPP-XML meines Erachtens an), muss unter Debian & Konsorten normal noch die Lua Erweiterung für zlib mittels sudo apt-get install lua-zlib herunterladen und installieren - sonst kann Prosody mit dem aktivierten Modul nichts anfangen. Danach kann man es in der Konfig-Datei aktivieren (und es läuft *g*).

Das Stream Management-Modul mod_smacks lies sich ohne weiteres einbinden und lief auf Anhieb. Jetzt braucht es nur noch bessere Client-Unterstützung, aber für Gajim ist diese in Arbeit und wird hoffentlich nicht so schändlich (bzw. einfach nicht) eingepflegt wie bei Psi. Und Swift bekommt hoffentlich bald Stream Resumption. Aber ich schweife vom Thema ab.

Was es sonst so an Modulen gibt, kann man hier (https://prosody-modules.googlecode.com/hg/) nachsehen und hier (https://code.google.com/p/prosody-modules/w/list) in den meisten Fällen eine kurze Beschreibung und Anleitung finden.

Was nicht mehr geht

Derzeit unterstützt Prosody offiziell kein Publish-Subscribe (es ist aber bereits ein Modul verfügbar), das wird sich aber vermutlich bald ändern. Ich muss zugeben, dass mir der genaue Zweck von PubSub noch nicht 100% erschlossen hat (Nachlesebedarf! *g*), aber ich habe dadurch noch keine Einschränkungen erkennen können.

Ein Webinterface ist standardmäßig nicht gegeben, als eingetragener Admin (entsprechende JIDs sind in der Konfig eingebbar) kann man aber so gut wie alles über Adhoc Kommandos einstellen, einschließlich dem Laden von Modulen). Es gibt aber auch ein Modul, welches auch via Webinterface diese Kommandos bietet, allerdings habe ich das noch nicht getestet. Einfach mal reinschnuppern.

Fazit

Ich bin sehr zufrieden! Die Migration lief mit Ausnahme der Notizen im private XML Storage erstaunlich glatt und problemlos. Dieses Problem wird aber ohnehin nur die Wenigstens tangieren. Die Module funktionieren wunderbar. Ich würde sagen, dass Prosody auf dem Besten Weg ist, State of the Art bei den offenen XMPP-Servern zu werden - wenn er das nicht schon ist. Ejabberd ist gewiss ein guter Server, der auch im großen Stile relativ gut skaliert und seit Jahren bewährt ist. Aber wenn man sich mit XMPP etwas austoben will, halte ich Prosody für die bessere Wahl. Ich hoffe, dass er mich weiterhin so begeistert und sich weiterentwickelt. Rein subjektiv habe ich übrigens das Gefühl, dass der Verbindungsaufbau jetzt schneller geht als zuvor - aber das kann auch euphorische Einbildung sein ;-D

So, vielleicht hilft das hier ja dem Einen oder der Anderen bei der Migration bzw. bei der Entscheidung zu eben dieser.

5Mai/112

XEP-049 (Private XML Storage): Die Möglichkeiten

Ich bin ja immer wieder von den Möglichkeiten von XMPP positiv überrascht. Was mir gerade klar wurde, ist die simple, aber geniale, Funktionsweise von XEP-0049 (Private XML Storage). Es bietet schlicht und ergreifend einen neuen XML-Namespace xmlns="jabber:iq:private"

In diesem kann dann an Kind-Elementen stehen, was will. Wozu das Ganze? Wieso sollte ich Daten auf meinem Jabber-Server speichern? Nun, im Folgenden mal die drei Beispiele, die ich in Implementierungen gefunden habe.

  1. Storage Notes
    Hierbei handelt es sich schlicht und ergreifend um die Möglichkeit, sich Notizen anzulegen. Jeder Notiz kann über einen Titel, Tags und eben den Inhalt verfügen. Ein Implementierungsbeispiel findet sich auf diesem Bildschirmfoto im Psi+-Wiki: klick. Um die Notizen einzusehen, wird ein InfoQuery-Stanza (Stanza, so heißen die XML-Schnipsel von XMPP) in dieser Art verwendet: 

    <iq type="get" id="23">
    <query xmlns="jabber:iq:private">
    <storage xmlns="http://miranda-im.org/storage#notes" />
    </query>
    </iq>

    Was auffällt, ist das Kindelement <storage>, welches den Namespace "http://miranda-im.org/storage#notes" zugewiesen bekommen hat. Dies führt zu der Vermutung, dass Miranda IM dieses Feature erfunden hat. Als Resultat wird man hier eine Liste mit den verschiedenen Notizen bekommen, was in etwa so aussehen kann:

    <iq from="bob@example.com" type="result" to="bob@example.com/home">
    <query xmlns="jabber:iq:private">
    <storage xmlns="http://miranda-im.org/storage#notes">
    <note tags="Jabber XMPP">
    <title>Private XML Storage</title>
    <text>Informationen suchen und Blogeintrag schreiben</text>
    </note>
    </storage>
    </query>
    </iq>

    Unschwer die Notiz zu erkennen.  In diesem Beispiel war eben nur eine Notiz vorhanden.

    Ich für meinen Teil finde die Funktion sehr praktisch. Bisher vorgefunden habe ich sie außer in Miranda und Psi+ noch nirgends.

  2. MUC-Bookmarks
    Die Funktion, Multi User Chatrooms zu speichern und überall verfügbar zu haben, wird in XEP-0048: (Bookmarks) definiert. Hier sieht der der Storage-Tag samt dazugehörigem Namespace so aus: 

    <storage xmlns='storage:bookmarks'>

    Elegant und praktisch!

  3. Kommentare zu Nutzern im Roster (Kontaktliste)
    Ein nettes Features, welches ich in Vacuum IM vorfand,  ist die Möglichkeit, sich zu jedem Kontakt eine Notiz hinzu zu fügen (z.B. Erinnerungen oder wer die Person eigentlich ist...). Bei Vacuum IM werden diese in der Info-Box beim überfahren des Kontaktes eingeblendet.
    In dem Kommentar wird darüber hinaus noch das Erstellungs- und das letzte Änderungsdatum gespeichert. 

    <iq type="set" id="42">
    <query xmlns="jabber:iq:private">
    <storage xmlns="storage:rosternotes">
    <note mdate="2011-05-04T22:46:17Z" cdate="2011-05-04T22:46:17Z" jid="update@identi.ca">Alle neuen Beiträge auf Identi.ca</note>
    </storage>
    </query>
    </iq>

    Nachtrag: Die Rosternotes haben sogar eine XEP: XEP-0145 (Annotations). Interessanter Weise habe ich bei meiner Suche eine neue Version 1.1 (klick) der XEP gefunden, die das Gleiche via Pub-Sub macht. Dann würde obiges natürlich obsolet werden - aber seit Ende 2007 hat sich da nichts mehr getan, wird also für's Erste bei der jabber:iq:private-Variante bleiben.
    Nachtrag 2, 03.08.2011: Ich habe festgestellt, dass Gajim in den Details des Nutzers einen extra Reiter hat, in dem die Roster Notes gezeigt und bearbeitet werden können. Das Ding (Gajim) kann echt viel, das muss man ihm lassen.

 

Das sind also die drei Anwendungen, die mir in der Praxis begegnet sind - und ich als solche erkannt habe.  Es ist mal wieder eine sehr innovative und vielseitig einsetzbare Erweiterung des Protokolls. Ich hoffe, dass mehr Clients die Möglichkeiten nutzen werden.

Was mir bei meinen Recherchen auffiel ist, dass man de facto keine Übersicht hat, was alles im im jabber:iq:private-Namespace auf dem Server unter meinem Account abgespeichert wurde. Das bedeutet, ohne die Namespaces der jeweiligen Funktion, kommt man also nicht so einfach an die Daten ran. Ich bleibe da mal dran, ob sich dazu noch Infos finden lassen. Darüber hinaus wurde ich in einem MUC auf die Idee gebracht, die Nutzerdatenbank eines großen Jabber-Knotens auf die Namespaces (und nur diese -> Datenschutz) innerhalb des jeweiligen privaten XML-Bereiches mit einem Script zu durchforsten - somit ließen sich ggf. noch weitere Anwendungsgebiete zu finden. Mal sehen, ob ich da was deichseln kann. (Update, 05.05.2011: Also auf meinem Server habe ich für das storage-Element keine weiteren Einträge gefunden.)

Wenn ich etwas neues herausgefunden habe, werde ich diesen Beitrag entsprechend erweitern. Bis dahin: Viel Spaß mit XMPP!

 

Nachtrag, 05.05.2011: XEP-0083: Nested Roster Groups nutzt ebenfalls den private-Namespace, allerdings ohne ein Storage-Element.