Wohnzimmerhostblogger

Bei einem Kunden geht die Uhrzeit auf dem Computer wohl ca. 2 Minuten vor. Heute morgen erreichte mich so also eine E-Mail vor ihrem eigentlich Zeitstempel.

Das an sich ist natürlich nicht des Bloggens wert und ich habe mit derart Ungenauigkeit natürlich überhaupt kein Problem. Mein "Problem" find damit an, dass meine Antwort innerhalb von einer Minute formuliert war. Da es aber noch andere Teilnehmer in der Konversation gab, mochte ich meine E-Mail nicht "vor" der ursprünglichen E-Mail abschicken.

So saß ich also eine knappe Minute vor dem Monitor und wartete bis der Minutenzeiger der Uhr umspringt bevor ich meine E-Mail los schickte. Nun kann man damit Argumentieren, dass bei einer etwaigen Threadansicht des E-Mail-Verkehrs kein "Problem" bestanden hätte, aber wer hat die schon in seiner Inbox? Auch wird der schlaue Leser recht schnell bemerken, dass ich mich auf eine "spätere" E-Mail beziehe, aber ich finde auch so kleine Dinge kann man ruhig im Voraus beachten - auch wenn ich meiner Minute hinterher trauere. Aber wer weiß: Vielleicht habe ich im großen und ganzen der Menschheit ein paar Sekunden oder Minuten an Arbeitszeit gespart. Es kann ja mehr Sinn machen, wenn ich eine Minute auf meiner Seite verbrenne, als wenn 3 andere Menschen 25 Sekunden o.ä. mit dem mehrfachen Lesen von E-Mails verbringen

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.