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

24Aug/1113

Psi+ GPG-Verschlüsselung unter Linux ((X)Ubuntu) aktivieren

Ich hatte jetzt eine ganze Zeit über das Problem, dass ich bei Psi+ unter Xubuntu (und ich glaube, es war auch unter Linux Mint Debian Edition das gleiche Elend) keine GPG-Verschlüsselung für meinen Account aktivieren konnte, weil ich keinen privaten Schlüssel unter Account Properties -> Details auswählen konnte: Der Button "Select Key" war ausgegraut. An der Schlüsselverwaltung konnte es eigentlich nicht liegen, denn unter Gajim ging es einwand frei. Nun bin ich im Psi-MUC zufällig über die Lösung gestolpert:

libqca2-plugin-gnupg

muss installiert werden. Nun funktioniert GPG einwandfrei. So einfach kann es manchmal gehen. :-)

23Aug/1111

Jabber-Client-Updates: Psi+, Gajim & Vacuum IM

Es gibt mal wieder ein paar kleinere Neuigkeiten bei den XMPP-Clients.

Psi+
Was mich besonders freute, war folgende Zeile im Changelog zu Version 0.15.5091:

 * fixed receipts when pgp/gpg is enabled (psi-receipts.diff, psi-pgp-chat-icons.diff)

Endlich funktionieren die Receipts bei aktivierter Verschlüsselung. Das bedeutet, dass wenn eine Nachricht abgeschickt wird, der Pfeil links von ihr lila ist, bis der Client des anderen eine Empfangsbestätigung sendet. Wenn dieses beim Sender eintrifft, wird der Pfeil grün. Darüber hinaus wurden schöne Icons hinzugefügt, so dass man leicht sehen kann, ob eine Nachricht verschlüsselt übermittelt wurde oder eben nicht. Schön zu sehen, dass es bei meinem lieblings-Jabber-Programm immer wieder weitergeht.

Gajim
Es geht das Gerücht, dass die Tage eine Alphaversion von Gajim 0.15 herauskommt. Diese wird aller Wahrscheinlichkeit nach Stream Management und GPG-Unterstützung unter Windows beinhalten. Ich bin gespannt!

Vacuum IM
Dieser hierzulande recht unbekannte Client wurde in der Version 1.1.1 veröffentlicht. Sie auch hier

veröffentlicht unter: Jabber/XMPP, Software 11 Kommentare
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.

1Jun/1114

User Mood und User Activity via PEP in ejabberd aktivieren

Ich habe mich eine ganze Weile lang mit einem ejabberd-Server rumgeschlagen, bei welchen  PEP (Personal Eventing Protocol, XEP-0163) nicht aktiviert/aktivierbar war (obwohl es laut Config den Anschein hatte) und somit Funktionen wie User Mood (XEP-0107) und User Activity (XEP-0108) nicht funktionierten. Jetzt konnte mir jemand im ejabberd-MUC helfen(thx badlop and skupko): Beim Update von Version 2.0.x zu 2.1.x hat sich die Art, wie man die Funktion in der ejabberd.cfg einstellen muss, geändert.

Original:

{mod_pubsub, [ % requires mod_caps
{access_createnode, pubsub_createnode},
{plugins, ["default", "pep"]}
]},

Korrekt:

{mod_pubsub, [ % requires mod_caps
{access_createnode, pubsub_createnode},
{plugins, ["flat", "hometree", "pep"]}
]},

Mit dieser Einstellung funktioniert alles wunderbar.
Vielleicht hat ja jemand das gleiche Problem und ihm hilft dieser Beitrag.

veröffentlicht unter: Jabber/XMPP, Software 14 Kommentare
1Jun/119

How to enable User Mood and User Activity via PEP in ejabberd

I had an problem with an ejabberd server for a while. PEP (Personal Eventing Protocol, XEP-0163) was not enabled/ possible to enable (although according to the config-file it seemed to be) so functions like User Mood (XEP-0107) and User Activity (XEP-0108) did not work. Finally someone from the ejabberd-MUC (thx badlop and skupko) could help me: Through an update from 2.0.x to 2.1.x the way the ejabberd.cfg has to be configured has changed:

Original:

{mod_pubsub, [ % requires mod_caps
{access_createnode, pubsub_createnode},
{plugins, ["default", "pep"]}
]},

Correct:

{mod_pubsub, [ % requires mod_caps
{access_createnode, pubsub_createnode},
{plugins, ["flat", "hometree", "pep"]}
]},

With this configuration-entries the PEP worked fine.

Perhaps someone has the same problem so that this post helps.

veröffentlicht unter: Jabber/XMPP, Software 9 Kommentare
16Mai/1111

Schon gewusst?

Schon gewusst, dass bei Straßenbegrenzungspfosten (aka Pinguine...diese weißen Pfosten mit Schwarzen greifen am Straßenrand eben) immer dann einen gelben Reflektor haben, wenn sie um eine Einfahrt, also z.B. ein Feldweg, der in die Straße mündet, stehen?

veröffentlicht unter: Allgemein, Schon gewusst? 11 Kommentare
16Mai/111

Bitte ein Bit, oder: Warum XML die richtige Wahl für XMPP war

XML ist eine "menschenlesbare" Auszeichnungssprache, also nicht nur kryptisch codierter Code (okay, natürlich ist XML "unten rum" auch nur Binärcode, aber dazwischen ist eben eine Präsentationsschicht). Dies bringt jedoch den Nachteil mit sich, dass Menschen zum Lesen nicht irgendwelche Register haben, wo sie möglichst kurze Variablen ablegen können, um später jederzeit darauf zuzugreifen. Ein "" hat bereits neun Zeichen - ein Rechner bräuchte diesen Overhead nicht. Für uns als Menschen ist es jedoch ein doch recht aussagekräftiges Element. Aber z.B. beim Chatten sieht man den XML-Schnipsel ja eigentlich nicht (Freaks mal ausgenommen *pfeift unauffällig*), sondern nur den Inhalt der Nachricht, aufbereitet in einem schönen XMPP-Chat-Programm. Unter der Haube könnten da doch ruhig Bytes gespart werden - schließlich bedeutet Chatten im Normalfall, dass die Nachricht in das Internet über mindestens einen Server, zahllose Router bis zum Empfänger der Nachricht - welcher auch gerne auch mal auf der anderen Seite unseres Planeten sein kann - gejagt wird. Wäre es gerade da nicht gut, großen Wert auf kompakte Paketgrößen zu legen? Ich denke, mir werden nicht viele widersprechen, wenn ich sage, dass diese Frage eher rhetorischer Natur ist (Für den Rest: "Ja!").

Nun, warum wurde also beim Design der Sprache eine solch verschwenderische Sprache wie XML gewählt? Da XMPP ja aus guten Gründen auf Unicode (UTF-8) aufbaut, bedeuten die zusätzlichen Zeichen einen nicht insignifikanten Anstieg der benötigten Bits. Ist also auf den falschen Unterbau gesetzt? Ich für meinen Teil verneine dies.

Als 2004 XMPP zu einem offiziellen Standard wurde, war die Intention natürlich, dass sich dieses Protokoll schnell und weit verbreiten wird. Wäre anstatt XML eine z.B. rein binäre Kodierung gewählt worden, hätte dies vermutlich in der Zwischenzeit viel Bandbreite gespart. Zum Einen, weil es kompakter gewesen wäre. Zum anderen, weil XMPP/Jabber wohl kaum benutzt werden worden. Das schöne an XML, die Lesbarkeit, macht das Entwickeln und die Fehlersuche erheblich einfacher. Wer programmieren kann, hat mit XML auf jeden Fall keine Probleme, die Lernkurve ist extrem steil (== viel Lernen in kurzer Zeit ;-)). Wenn man sich erst einmal zwei Monate mit der Art und Weise der Kodierung auseinander setzen hätte müssen, hätten wir heute wohl kaum ein so gesundes Ökosystem an Software, die XMPP nutzt. Von daher ist XML meines Erachtens ein guter Ausgangspunkt für weitere Entwicklungen - und es hat sich ja bewährt.

Ein weiterer Pluspunkt bezüglich XML ist die einfache Erweiterbarkeit. Auf jene bin ich mehr oder minder ja hier bereits eingegangen. XML ist einfach per Definition gut zu erweitern. Ob das bei einem Binärprotokoll so elegant geklappt hätte, wage ich zu bezweifeln.
Somit wäre das Projekt Jabber und erst Recht XMPP (oder wie auch immer es ohne das X, welches es vom XML geerbt hat geheißen hätte) vermutlich recht schnell im Sand verlaufen. Die Menschen lieben eben auch in der digitalen Welt Dinge, die man "greifen" kann.

Ja, aaaaaber trotzdem ist XMPP ja sehr "Bithungrig". Ja, das stimmt schon. Und auch zu Zeiten von breiten Datenautobahnen sollte man sich überlegen, ob man die Daten nicht kompakter übermitteln kann. Schließlich ist auch das mobile Internet nicht überall gut ausgebaut. Auch bei XMPP wurde darüber nachgedacht, es gibt eine Erweiterung (XEP-0138: Stream Compression), die beim Verbindungsaufbau zwischen zwei Entitäten versucht, einen Kompressionsalgorithmus auszuhandeln. Somit werden die übertragenen XML-Schnipsel aka Stanzas in verkleinerter Form übertragen, wenn Server und Client sich darauf verständigt haben. Somit sollte das Datenaufkommen doch stark reduziert sein.

Und wer generell etwas gegen XML hat, mag wohl auch kein HTML und das, was daraus geworden ist, oder? Gut, da kann ich dann nichts gegen sagen. Klar wäre auch hier vielleicht eine kleinere Auszeichnungssprache möglich gewesen (ich bin mir immer noch nicht sicher, ob z.B. JSON wirklich so viel Einsparungspotential gehabt hätte), aber der Erfolg zeigt doch relativ deutlich, dass man mit XML nicht auf das falscheste Pferd gesetzt hat 😉 Und wenn sich eine Sprache fände, die so elementare Vorteile bringen würde - was spräche dagegen, eine XEP zu formulieren, in der die Translation zwischen jener Sprache und dem normalen XMPP geregelt und ausgehandelt werden würde? Klar, das wäre dann je nach Implementierung ein Tick mehr Rechenarbeit, aber würde wohl kaum dramatische Ausmaße annehmen. Es ist eben eine "eXtensible Markup Language" :-)

So, alles in Allem bin ich jedenfalls für mich zu dem Schluss gekommen, dass XML eine sehr gute Wahl gewesen ist - auf eine Bessere wäre ich jedenfalls nicht gekommen.

veröffentlicht unter: Jabber/XMPP 1 Kommentar
9Mai/110

Schon gewusst?

Schon gewusst, dass die Mobiltelefon-Eingabemethode T9 eine Abkürzung für Text on 9 keys ist?

veröffentlicht unter: Allgemein, Schon gewusst? keine Kommentare
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.

4Mai/111

Vacuum IM – ein recht unbekannter Jabber-Client

Unter vacuum-im.org (hier die englische Google Code Seite) findet man einen echt brauchbaren XMPP Client - natürlich Open Source und unter Linux und Windows lauffähig.

Ich würde sagen, er ist für Leute, die viel mit XMPP rumspielen und vielleicht auch einen eigenen Server haben sehr interessanter, da er z.B. Service-Disco sehr gut beherrscht und sauber auflistet, was ein Client/Server kann. Viele Details werden leicht erreichbar aufgelistet. Darüber hinaus sind noch Nettigkeiten wie Kommentare zu einzelnen Nutzern möglich. Generell bietet das Programm eine recht aufgeräumte, wenn auch nicht immer ganz praktische Oberfläche. Die Gestaltung des Nachrichtenfensters ist sehr schick gemacht (sieht in etwa so aus wie bei Swift IM).

Nun, ich denke, dass man den Client ruhig mal auf dem PC haben kann, ein Blick darauf schadet dem geneigten Nutzer nicht. Mal sehen, wie sich das Projekt noch weiter entwickelt – Abwarten und Tee trinken.
Was mir daran fehlt? Leider kein XEP-0184 (Message Delivery Receipts) (Nachtrag: laut Entwicklern kommt das noch) und kein GPG, von XEP-0198 (Stream Management) ganz zu schweigen. Local Storage, wie man es von Psi+ und Miranda kennt, kann er leider nicht (oder ich habe es noch nicht entdeckt *g*).

Ich für meinen Teil schätze das Programm im Moment, auch wenn ich z.B. keine OTR-Verbindung zu Pidgin aufgebaut bekomme (hier muss eindeutig mal eine XEP her).

Schön jedenfalls, die Diversität der Clients zu sehen und zu erkennen, dass es überall noch Platz für neue, gute Ideen und Umsetzungen gibt. Weiter so!

Updates: Link zur Google Code Seite; Korrektur bzgl. Entwicklern; Lizenz+Plattformen; Miranda kann auch Local Storage; Message Delivery Receipts sind für eine zukünftige Version geplant