Dezentralisierte Dienste – Zu spät, zu kompliziert, zu fragmentiert

Die meisten Dienste im Netz lassen sich in zwei Kategorien einteilen: Zentralisierte Dienste und dezentralisierte Angebote. Bei ersteren gibt es eine zentrale Instanz über die der Dienst betrieben wird, bei letzteren eine dezentralisierte Struktur unabhängig betriebener Server. Dezentralisierte Dienste sind oft Open Source aber auch zentralisierte Angebote können quelloffen sein.

Dezentralisierte Dienste, insbesondere zur Kommunikation, sind aber vor allem in der Open Source Community populär. Die Vorteile liegen auf der Hand. Durch die dezentrale Struktur gibt es keine neuralgischen Punkte, deren Störung das Angebot lahmlegen würde. Dezentrale quelloffene Lösungen kommen zudem dem “Do-it-yourself” Gedanken in der OSS-Szene entgegen, nach dem jeder Dienstbetreiber werden kann.

In der Praxis gibt es im Bereich der Kommunikation nur ein dezentrales Angebot von wirklicher Bedeutung: Die E-Mail. Dies hat vor allem historische Gründe und liegt in den gewachsenen Kommunikationsstrukturen. Andere dezentralisierte Kommunikationslösungen konnten sich nie gegen die zentralisierte, oft proprietäre Konkurrenz durchsetzen. Warum das so ist kann man sehr gut an XMPP/”Jabber” zeigen.

Jabber bzw. XMPP kam auf als die 2000er noch jung waren. Die große Konkurrenz hieß ICQ, damals der unbestrittene Markführer für Kurznachrichten. Die Älteren werden sich vielleicht noch erinnern. Smartphones waren noch noch nicht mal in den Forschungslaboren der großen IT-Konzerne angekommen und selbst Notebooks für die breite Öffentlichkeit unbezahlbar. Messenger bediente man damals auf dem PC und beide Kommunikationspartner waren zeitgleich online. Verschlüsselung setzte Rechenkapazitäten voraus, die fast niemand privat besaß.

Nach der Standardisierung 2004 wurde XMPP die Basis für viele proprietäre Angebote. Google experimentierte mit einer VoIP-Funktion (Google Talk) und 2005 zog die Erweiterung “Jingle” in XMPP ein. Hinzu kam dann auch noch Gruppenchats (MUC) und einiges weiteres. XMPP hatte das Potenzial die Standardlösung für Messenger zu werden, vergleichbar der E-Mail für zeitversetzte Kommunikation. Nicht nur Google-Kunden hatten automatisch XMPP, sondern auch die in Deutschland wichtigen Dienste von United Internet lieferten dies für ihre E-Mail Nutzer aus. Mittelfristig hätte man ICQ sicher den Rang abgelaufen.

Dann kamen zwei heftige Einschläge. Zuerst änderte das iPhone ab 2007 die Art wie man kommunizierte, dann erfuhr die Weltöffentlichkeit 2013, dass westliche Geheimdienste alles mithörten. Auf beides war XMPP nicht vorbereitet.

In der Folgezeit hoben neue StartUps Messengerdienste wie WhatsApp aus der Taufe und nicht mehr ganz so neue StartUps wie Facebook erweiterten ihre Angebote irgendwann um Kurznachrichtendienste. Beides auf Basis von XMPP aber beide koppelten sich entweder sofort oder später vom Netzwerk ab. Geschlossene Kommunikationsnetze versprachen eine stabilere Kundenbasis. Eine agil handelnde zentrale Stelle hätte nun Fehleranalyse betrieben und versucht den Dienst konkurrenzfähig zu halten. Die Veränderung der Kommunikationsgewohnheit war offensichtlich. Die Verknüpfung des Messengers mit der Telefonnummer war beispielsweise eine geniale Idee von WhatsApp, die nahezu jeder nachfolgende Dienst kopierte. XMPP nicht. Hier musste man wie zu ICQ-Zeiten weiterhin eine separate Kennung dem Kommunikatiospartner mitteilen. Nur eines von vielen Beispielen, bei denen man den Anschluss verlor.

Das zweite Problem war die fehlende Verschlüsselung für text-, audio- und videobasierte Kommunikation. Hier griff man zuerst auf OTR zurück, eine Lösung die ebenso wie XMPP älter als das Smartphone war. Weil hierfür beide Kommunikationspartner zeitgleich online sein müssen, eignete sic dieser Ansatz für die Welt der mobilen Kommunikation überhaupt nicht. Erst 2015 implementierte der Entwickler von Conversations im Rahmen eines GSoC-Projektes das Signal-Protokoll (vormals Axolotl) in XMPP. Eine notwendige Erweiterung, die bis heute nicht offiziell angenommen wurde. Die Verschlüsselung von Video- und Sprachkommunikation trieb Jitsi voran und setzte hierfür auf OTR und ZRTP. Bisher nutzt diese Methode kein anderer Client.

Hier kommen wir zum Kern des Problems dezentralisierter Dienste. Die Kommunikationsgewohnheiten ändern sich rasant und neue Anforderungen entstehen. Dezentralisierte Dienste nehmen erstens die Herausforderung viel zu spät auf (OMEMO kam 2 Jahre nach Snowden!), Conversations als mobil funktionsfähige Lösung 5 Jahre nach WhatsApp. Zweitens fragmentieren solche Erweiterungen das Ökosystem, weil die Standardisierung ewig dauert und die Clients diese nicht zeitnah implementieren. OMEMO ist immer noch nicht in der Mehrheit der Clients integriert. Für mobile und sichere Kommunikation braucht der Anwender also nicht nur den richtigen Client und einen passenden Server, sondern der Kommunikationspartner auch.

XMPP funktioniert zudem nicht nur dezentral, es wird auch dezentral entwickelt. Wenn es eine zentrale Entwicklung des Protokolls und Referenzclients gibt, kann man Änderungen verhältnismäßig schnell ausrollen. Das Ökosystem passt sich dann meist schnell an. Bei XMPP fügen kleine Entwicklergruppen oder Einzelpersonen Erweiterungen an und versuchen diese offiziell zu machen. Server und Clients ziehen nach oder eben auch nicht. Bis sich Änderungen durchsetzen vergeht so viel Zeit.

Selbst wenn man dann irgendwann funktional gleichgezogen hat man agileren zentralisierten Projekten, ist der Zug schon lange abgefahren. Die Entwicklung der letzten Jahre hat eines schließlich deutlich gezeigt: Es gewinnt nicht das qualitativ hochwertigste Projekt, sondern jenes, dass sich früh etablieren und große Marktanteile sichern konnte. Ansonsten wäre Android nicht so erfolgreich und WhatsApp auch nicht.

Das spricht nun nicht unbedingt gegen dezentrale Ansätze allgemein – wohl aber gegen dezentrale Ansätze in der Massenkommunikation. Der Anspruch an einen Messenger ist es – vergleichbar zu WhatsApp nahezu jeden zu erreichen. Wenn er dies nicht leisten kann wenden sich die Menschen ab, weil niemand dutzende verschiedene Messenger bediene möchte. Soll der Dienst jedoch nur in einer definierten Gruppe zum Einsatz kommen können diese natürlich per Absprache Änderungen festlegen oder notfalls auf ein anderes Angebot migrieren.


Bilder:
Einleitungsbild und Beitragsbild von von geralt via pixabay

Cruiz
Cruizhttps://curius.de
Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.
  1. Dezentral-Zentral … da gibt es Parallelen mit Regierungssystemen:
    Die schnellere Reaktion ist bei zentral aufgestellten autoritären Systemen.
    Die stärkere Abwehr von Kontrolle durch eine Minderheit eher bei dezentralen = föderalen Systemen.
    Bei den Kommunikationssystemen wäre eine dezentrale Struktur sehr wünschenswert. Sie scheitert allerdings an der Bequemlichkeit der Menschen, die maximalen Komfort an erste Stelle setzen.
    Ich denke, Delta.Chat wäre auch eine Betrachtung wert. Das verwendet ausschließlich das bestehende email-System. Der Kommunikationspartner muß nichts installieren, nur eine email-Adresse haben. Er kann aber einen Chat-Client verwenden, um den Komfort der Kommunikation zu erhöhen. Ein toller Ansatz, wie ich finde …. leider auch non-profit und darum gibt es keine PR dafür.

Kommentieren Sie den Artikel

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Weitere Artikel