Eigener XMPP-Server: Ernüchterung bei Transports

Seit mehreren Wochen läuft hier ein eigener XMPP-Server auf Basis von Prosody. Die Benutzung des reinen XMPP-Chats (ohne Transports) mit Gajim unter Gnome und Windows, Xabber und Conversations auf Android und Pidgin unter Windows klappt hervorragend. Was jedoch bis auf zwei Ausnahmen nicht stabil funktionieren wollte, sind die Transports in andere Messenger-Netzwerke.

Als Schnittstelle zwischen Prosody und den Modulen für die anderen Netze habe ich Spectrum2 gewählt. Stabil ließen sich nur Transports zu Twitter und zum IRC betreiben. Das liegt aber nicht an der verwendeten Software, sondern an den Anbietern selbst.

Google-Transport

Prinzipbedingt fügt der Google- bzw. XMPP-Transport zu Google bei jedem Anmelden die Kontakte dem eigenen Roster hinzu. Problematisch ist, dass Google dabei immer wieder neue IDs für bereits bestehende Kontakte generiert. Hier kommt es sofort zu Synchronisationsschwierigkeiten und man handelt sich sehr schnell "Leichen" in der Kontaktliste ein. Ebenfalls problematisch ist, sehr viele Kontakte bei Google zu haben, was bei intensiver Nutzung von z.B. Google+ schnell passieren kann. Bei jeder Statusänderung auf Clientseite werden alle Kontakte über den Transport hinweg über die Statusänderung informiert. Bei > 500 Leuten meinen die Google-Server dann schnell einmal, dass man sein Kontingent an XMPP-Nachrichten in der Minute ausgeschöpft hat und lassen vorübergehend keine weitere Kommunikation zu. Ebenfalls unschön ist, dass Google-Kontakte, welche nicht explizit Hangout deinstalliert oder anderweitig abgeschaltet haben als online, aber beschäftigt angezeigt werden. Die Anzeige der Kontaktliste in den Clientprogrammen unterscheidet grob aber nur zwischen online und offline. Man muss also mit einer sehr langen Kontaktliste bei vielen Kontakten auf Google rechnen. Aufgrund der vorübergehenden Weigerung der Google-Server weitere Nachrichten zu akzeptieren, kommen in diesem Zeitraum natürlich auch keine neuen Nachrichten an noch können andere verschickt werden. So ist dieser Transport leider unbenutzbar.

Facebook-Transport

Genauso wie der Google-Transport fügt der Facebook-Transport die FB-Kontakte auch immer wieder dem Roster hinzu. Allerdings sind die IDs dort fest und führen zu keinen Synchronisationsproblemen. Ebenfalls sind FB-Kontakte auch wirklich offline, wenn sie den Browser schließen. Ich konnte hier leider nur mit wenigen Kontakten testen, die Kommunikation klappte jedoch gut. Ernüchterung kam nun heute, als Facebook meinte, das Konto wäre nicht mehr authorisiert. Ein Blick auf die Facebook-Webseite offenbarte: das FB-Konto wurde vorübergehend gesperrt. Anlass hierzu gab wohl, dass die Verbindung vom XMPP-Server offen gehalten wurde und zwischenzeitlich die Facebook-Webseite mit einem normalen Browser und natürlich mit einer ganz anderen IP-Adresse besucht wurde. Facebook vermutet dann offenbar entwendete Zugangsdaten. Damit war auch dieser Transport unbrauchbar.

Twitter-Transport

Beim Twitter-Transport werden die Kontakte nicht in den Roster eingetragen. Vielmehr wird ein Konferenzraum erstellt, in dem alle Twitter-Follower Teilnehmer sind. Dieser Transport läuft bis jetzt stabil. Die Darstellung der Twitter-Nachrichten ist eher spartanisch und mit ettlichen technischen Informationen durchsetzt. Für den "schnellen Plausch" auf Twitter (sofern es soetwas überhaupt gibt) reicht die angebotene Funktionalität aber allemal.

IRC-Transport

Ebenfalls stabil läuft der IRC-Transport. Die einzelnen IRC-Channels werden als XMPP-Konferenzräume dargestellt. Die Teilnehmer der jeweiligen Konferenz bzw. des jeweiligen Channels brauchen dadurch auch nicht in den Roster übernommen werden. Durch die Möglichkeit, den jeweiligen Transport-Benutzer angemeldet zu lassen kann so ein dauerhafter Kontakt zu einem IRC-Channel hergestellt werden, obwohl man vielleicht gerade gar keinen XMPP-Client gestartet hat.

Transport in andere Netzwerke

Für WhatsApp steht ein weiterer Transport zur Verfügung, welchen ich aber nicht ausprobiert habe. Ein wichtiger Grund ist der, dass man nicht das gleiche Konto wie auf dem Smartphone verwenden kann, sondern sich ein zweites hätte erstellen müssen. Eigentlich ein NoGo für bestehende Kontakte, denn sie wissen dann nicht mehr, über welchen Account sie mich aktuell erreichen können.

Andere Netzwerke wie Signal, Telegram oder auch Threema sind noch ganz außen vor, da für diese bisher keine (mir bekannten) Transports verfügbar sind.

Fazit

Das ursprüngliche Ziel war, unterschiedliche Kommunikationswege unter einem Dach bzw. in einer einzigen XMPP-Schnittstelle zusammen zu führen. Gleichzeitig sollte erreicht werden, dass pro Betriebssystem nur noch ein Messenger verwendet werden muss. Dieser Versuch ist fehlgeschlagen. An diesem Zustand wird sich meiner Meinung nach in Zukunft auch nicht viel ändern, da jeder Dienst alles andere als interconnection-freudig ist.