Deep Dive zu Bluesky — Teil 1: Die technische Sicht

Die Social Media-Plattform Bluesky hat seit Trumps Wiederwahl und der offensichtlich gewor­denen engen Verbindung zwischen Trump und dem X-Besitzer Elon Musk deutlich an Usern zugelegt. Waren es im August 2024 noch 13 Millionen User, sind es Ende November bereits über 23 Millionen. Und auch wenn der User-Zähler nicht mehr so schnell nach oben zählt wie noch vor zwei Wochen, der Anstieg geht kontinuierlich weiter.

Damit verbunden ist natürlich die Frage, ob Bluesky unter dem Strich effektiv besser ist als X. Fragen kann man sich auch, wie gross das Risiko ist, dass Bluesky in ein paar Jahren zu einem ähnlichen Umfeld wird, wie es X unter Musk geworden ist. Diese und ähnliche Fragen wurden letzte Woche auch in den Kommentarspalten der Republik aufgeworfen, als Reaktion auf einen Artikel, welcher zum Wechsel von X nach Bluesky animieren wollte.

Diesem Thema gehen wir unter zwei Gesichtspunkten nach: Heute (in diesem Artikel) aus einer technischen Sicht, nächste Woche dann aus einer Benutzer-Sicht. Wir möchten im folgenden insbesondere anschauen, wie sich Bluesky aus technischer Sicht von X und Fediverse/Mastodon unterscheidet, und welche Konsequenzen das für die Benutzerinnen hat. Auch wollen wir verstehen, welche Auswirkungen diese Unterschiede auf die Resilienz der Plattform gegen zentrale Macht­kon­zentration hat (welche Nachteile eine solche Konzentration hat, dürfte spätestens mit der Übernahme von Twitter durch Elon Musk offensichtlich geworden sein).

Grundsätzliche Architektur-Überlegungen

Sämtliche Social Media-Plattformen stehen grundsätzlich vor denselben technischen Problemen:

• Sie müssen grosse Datenmengen (Posts und Medien) ihrer Benutzer speichern
• Diese Daten müssen Benutzerinnen schnell und jederzeit auf Anfrage angezeigt werden
• Es braucht Möglichkeiten, die Daten Benutzer-spezifisch auszuwählen und zu filtern
• Moderations-Tools sind notwendig, um zumindest illegale Inhalte verbergen oder löschen zu können

Daneben gibt es eine ganze Reihe anderer technischer Herausforderungen (Performance & Antwortzeiten, Ausfallsicherheit, weltweite Verfügbarkeit, Backups etc.), diese sind aber für alle Plattformen in etwa dieselben.

Zwei diametral gegensätzliche Ansätze, diese technischen Probleme zu lösen, werden durch Twitter/X bzw. durch das Fediverse (Mastodon plus vieles mehr) realisiert.

• X kann man sich stark vereinfacht als eine grosse, globale Datenbank vorstellen, in welcher alle Accounts und alle Posts gespeichert sind. Die Verteilung dieser Posts (also quasi die globale Timeline) erfolgt über hochperformante Distributionsserver. Damit jede Benutzerin die Posts sieht, welche X ihr zeigen will, wird die globale Timeline mithilfe von Algorithmen gefiltert und sortiert. Beachten muss man dabei, dass das gesamte System vollständig unter Kon­trolle von X steht, und es dem Benutzer verborgen bleibt, wie die für ihn angezeigten Posts ausgewählt werden.

• Das Fediverse (von dem Mastodon der bekannteste, aber bei weitem nicht der einzige Vertreter ist) hat einen grundsätzlich anderen Ansatz gewählt. Wenn wir auch hier stark vereinfachen, entspricht quasi jeder Fediverse-Server in etwa der Architektur von X, kann also für sich alleine bereits eine Social Media-Plattform anbieten. Um es für die Benutzerin­nen nützlicher zu machen, tauschen all diese Server aber untereinander all die Posts aus, für welche sich auch Benutzer auf anderen Servern interessieren. Die Server sind also unter­einander föderiert (woher auch der Name Fediverse stammt). Das Interesse an Posts von anderen Servern wird typischerweise durch das Folgen von Accounts ausgedrückt, jeder Fediverse-Server enthält daher neben den Posts der eigenen Benutzerinnen auch die Posts aller von diesen gefolgten Accounts auf anderen Servern.

Die beiden Architekturen haben direkten Einfluss auf die Kontrolle, welche die Plattform auf ihre Benutzer ausüben kann:

• Bei X sind Accounts, Posts wie auch Filterung/Sortierung vollständig unter Kontrolle des Unternehmens. Und während dieses zu Twitter-Zeiten noch um eine gewisse Transparenz bemüht war, hat sich das mit dem Wechsel zu X fundamental geändert. Es gibt für Benutzerin­nen keine Möglichkeit zu erkennen, ob sie wirklich genau die Posts sieht, welche sie sehen möchte, oder ob die Filterung von X Inhalte nach geheimen Kriterien favorisiert oder unterdrückt. Auch hat X die volle Kontrolle über Accounts und Posts, und kann auch jederzeit Accounts sperren oder löschen.

• Im Fediverse ist die zentrale Kontrolle auf den jeweiligen Server beschränkt, und betrifft primär die Konformität von Accounts und deren Posts mit den für den jeweiligen Server gültigen Hausregeln. Wer sich auf einem Server nicht mehr zuhause fühlt, kann problemlos auf einen anderen umziehen, ohne deswegen seine Follower und Followees zu verlieren. Und wer einen noch höheren Grad an Unabhängigkeit bevorzugt, kann auch einen eigenen Server für sich alleine betreiben. Dank der Föderation zwischen den Servern bleibt er auch dann Teil des Fediverse (zumindest so lange er nicht durch Spam oder ähnlichem negativ auffällt).

Aus Benutzer-Sicht ist man im Fediverse daher deutlich unabhängiger vom jeweiligen Serverbetreiber. Allerdings bietet das Fediverse keinen adäquaten Ersatz für das flexible Filtern der angezeigten Posts (von Account-Listen und Hashtag/Stichwort-Suchen einmal abgesehen). Auch das Bekämpfen von Spam, Hass-Posts und ähnlichem hängt weitgehend vom Willen der Administratoren ab, entsprechende Massnahmen zu ergreifen. Und zumindest für Neu­ein­steigerinnen ist die Struktur mit den vielen Servern, aus denen man fürs Anlegen eines Accounts einen auswählen muss, ungewohnt (und oft verwirrend).

Wie funktioniert nun Bluesky?

Da Bluesky generell Open Source ist, sind das verwendete Protokoll (ATProto) und die gesamte technische Dokumentation im Internet verfügbar, letztere beschreibt unter anderem die Architektur.

Die Basis von Bluesky bildet ein Personal Data Server (PDS), welcher die Posts der einzelnen User speichert. Dieser kümmert sich auch um Dinge wie Logins, weiss, welche Accounts man stumm­geschaltet oder blockiert hat, und nimmt neu geschriebene Posts entgegen. Um die Masse der Benutzer und ihrer Beiträge zu bewältigen, werden von Bluesky eine ganze Reihe von PDS betrieben. Die Benutzer merken davon grundsätzlich nichts, und müssen auch nicht wissen, auf welchem dieser Server ihr Account gespeichert ist (in der Wachstumsphase der letzten Wochen wurden Accounts teilweise auf neue PDS verschoben, was jeweils zu einer kurzzeitigen Nicht-Sichtbarkeit führte).

Eine besondere Eigenschaft von Bluesky ist, dass User-Accounts technisch gesehen nicht über den sichtbaren Namen identifiziert werden, sondern über eine zentral generierte numerische User-ID, DID genannt. Dies erlaubt es Benutzerinnen, ihr Account jederzeit umzubenennen, ohne dabei Follower oder bisherige Posts zu verlieren.

Die einzelnen PDS haben keine direkte Kommunikation untereinander. Um die auf den ver­schiedenen PDS publizierten Posts in eine Timeline zu kombinieren, kommt ein Relay-Server ins Spiel. Dieser zieht die Posts aller PDS-Server zusammen und publiziert sie als kombinierten, ungefilterten, chronologischen Stream (diesen kann man hier hübsch visualisiert verfolgen). Die Anforderungen an einen Relay-Server sind insbesondere bezüglich Diskplatz beträchtlich. Aktuell gehen Schätzungen von 5 TB aus, mit wachsender User-Zahl wird diese Zahl massiv ansteigen. Es überrascht daher nicht, dass der einzige Relay-Server momentan von Bluesky selbst zur Verfügung gestellt wird.

Als User selbst greift man über eine AppView (de facto eine Bluesky-App auf dem Smartphone oder ein Bluesky-Webclient) auf den vom Relay generierten Stream zu . Diese AppView sorgt dafür, dass man nur die Posts sieht, welche man via Followees oder Listen abonniert hat. Sie nutzt dabei auch die von den Labeler an den Posts angebrachten Meta-Daten, und steuert basierend darauf die Anzeige (oder Nicht-Anzeige) von Inhalten. Von Bluesky zur Verfügung gestellte Labeler erkennen zum Beispiel Posts mit sexuellen Inhalten oder pornografischem Material. Technisch versierte User können aber auch eigenen Labeler entwickeln und anderen zur Verfügung stellen, mit denen sich andere Inhalte klassifizieren lassen (ich wäre zum Beispiel um einen Katzen- und Hundebilder-Labeler froh :-)).

Als letztes Element auf dem Architektur-Bild gibt es Feed-Generatoren (FeedGen), mit welchen sich Inhalte (Posts) gruppieren lassen. Von Bluesky zur Verfügung gestellt werden Feeds wie Following (alle Posts von Accounts denen ich folge), Mutuals (alle Posts von gefolgten Accounts, welche auch mir folgen), daneben gibt es eine schier unendlich wirkende Zahl von user-generierten Feeds zu Themen aller Art.

Zusammengefasst besteht Bluesky also aus

• Einer Reihe von Personal Data Server (PDS), welche die Posts und Accounts der User halten
• Einem Relay-Server, welcher die Posts aller PDS zusammenzieht und in einem grossen Datenstrom (Firehose) zur Verfügung gestellt
• Einer Reihe von Labeling-Algorithmen, welche Posts nach transparenten Kriterien klassifizieren
• Einer App (AppView), welche dem User die gewünschten Posts unter Berücksichtigung der Labels anzeigt

Diese Architektur sieht grundsätzlich ähnlich aus wie bei X. Die Benutzer haben zwar mehr Einfluss auf die angezeigten Inhalte (da sowohl Labeler wie auch Feed-Generatoren von jedem erstellt werden können), aber die Hoheit über das Gesamtsystem scheint immer noch bei Bluesky zu liegen. Diese Einschätzung verändert sich, wenn wir auf dem obigen Bild diejenigen Teile markieren, welche auch durch Dritte angeboten werden können.

Die Bluesky-Architektur erlaubt es also,

• einen eigenen PDS für sein eigenes Account und dessen Posts zu betreiben, und die eigenen Posts über den Relay zu verbreiten,
• eigene Labeler zu entwickeln und anderen Benutzern zur Verfügung zu stellen,
• eigene Feeds zu definieren und anderen Benutzerinnen zur Verfügung zu stellen,
• eigene Apps zu bauen und anderen …

Was die Architektur nicht erlaubt, ist die vollständige Unabhängigkeit vom Unternehmen Bluesky. Einerseits gibt es zurzeit nur einen zentralen, von Bluesky betriebenen Server für die Generierung der User IDs, andererseits ist man auf die Verbreitung seiner Posts über den von Bluesky betriebenen Relay angewiesen, sofern man nicht nur mit sich selbst reden möchte. Man ist als Benutzerin also auch mit eigenem PDS darauf angewiesen, dass Bluesky die Posts sämtlicher PDS ohne Diskriminierung und Sperrung von Inhalten verbreitet.

Ist Bluesky nun dezentral oder föderiert?

In Vergleichen zwischen X und Bluesky wird letzteres manchmal als föderiert bezeichnet. Aufgrund der Abhängigkeit von zentralen Komponten (ID-Generator und Relay) ist diese Beschreibung aber definitiv nicht korrekt, man kann allenfalls von «teilweise dezentral» sprechen. Der Betrieb eines eigenen PDS gibt einem immerhin die Hoheit über die eigenen Daten, aber für die Teilnahme am Netzwerk ist man auf zentral bereitgestellte Komponenten angewiesen. Es gibt zwar Ideen (und Hinweise in der Spezifikation), diese Abhängigkeiten zu reduzieren oder zu beseitigen. An kon­kreten Plänen mangelt es aber, und angesichts der zu erwartenden hohen Kosten für den Betrieb eines Relays (der bei der aktuellen Benutzerzahl schon mehr als 5 TB für Diskplatz braucht) scheint eine Grassroot-Föderation zurzeit unwahrscheinlich.

Das Image als dezentrales Netzwerk hat Bluesky vermutlich seinen Anfängen zu verdanken. Entstanden ist das Projekt 2019 als Arbeitsgruppe innerhalb Twitter, ins Leben gerufen vom damaligen CEO Jack Dorsey. Auslöser waren die Wellen, welche der Ausschluss von Donald Trump von Twitter warfen (was angesichts der Tatsache, dass Trumps erneute Wahl viele Benutzer von X nach Bluesky getrieben hat, leicht ironisch ist). Twitter wollte mit Bluesky eine Plattform schaffen, welche grundsätzlich für alle offen und zugänglich ist, und auf welcher die Moderationsentscheide an Dritte delegiert sind. Das geht auch aus dem Tweet hervor, mit welchem er Bluesky ankündigte.

Ursprüngliches Ziel von Bluesky war also nicht das Erstellen einer neuen, dezentralen oder sogar föderierten Social Media-Plattform, sondern eines Basis-Standards für Social Media. Dieser hätte grundsätzliche Dinge wie Datenaggregation und -verbreitung gesetzt und auch den Rahmen für Moderation etc. gesteckt, die konkreten Regeln aber anderen überlassen. Auch ist ATProto (das technische Protokoll, welches das Zusammenspiel von PDS, Relay etc regelt) nicht auf Text und Medien beschränkt, sondern kann grundsätzlich beliebige Datentypen verarbeiten. Es wäre daher zum Beispiel möglich, neben der eher twitter-ähnlichen Bluesky-App auch einen Instagram- oder einen Tiktok-Clone auf derselben Basis zu entwickeln.

Mittels ATProto hätte (so der Plan in 2019) dann Twitter eine (von grundsätzlich beliebig vielen) Implementierungen von Social Media auf der gemeinsamen Plattform sein können. Diese Implementierung hätte sich auf die Bereitstellung eines Relays sowie Twitter-spezifischer Labeler und Feed-Generatoren beschränkt (es wäre sogar möglich, dass eine Social Media-Plattform nur noch aus Labeler und Feed-Generatoren besteht). Parallel dazu wären auf derselben Basis, d.h. unter Nutzung desselben ATProto-Protokolls und derselben PDS, auch weitere Social Media-Plattformen denkbar gewesen. Diese hätten, dank ATProto und gemeinsamen PDS, Daten untereinander austauschen können. Dieses ursprüngliche Zielbild kann man, relativ zur gemeinsamen Datenbasis, durchaus zumindest bezüglich Moderation und Darstellung gegenüber dem Benutzer als dezentral bezeichen.

Nun, es kam (nicht zuletzt da Twitter bzw. Jack Dorsey mit der Zeit selbst das Interesse an Bluesky verlor) anders. Was wir heute haben, ist das Protokoll für den Social Media-Standard, und Bluesky als einzige darauf aufsetzende Social Media-Applikation. Ob es jemals weitere geben wird, ist offen; Bluesky alleine kann man aber weder als dezentral noch als föderiert bezeichnen.

Was bedeutet das nun für die Benutzer?

Aus technischer Sicht bedeutet all das für die Bluesky-Benutzer, dass die Plattform defacto ähnlich zentral aufgebaut ist wie X. Zwar bestehen technisch gesehen verschiedene Möglichkeiten für dezentrale Elemente, praktisch bleibt deren Wirkung sehr beschränkt, da ja das Unternehmen Bluesky momentan der einzige Anbieter ist. Auch wenn es grundsätzlich möglich wäre, eigene Relay-Server zu betreiben, sind insbesondere aufgrund des hohen Diskbedarfs und der Verfügbarkeitsanforderungen die finanziellen Hürden ziemlich hoch. Für das Problem der zentralisierten Vergabe der numerischen User-ID gibt es noch nicht mal eine konzeptionelle Lösung. Benutzerinnen, welche eine Social Media-Plattform suchen welche nicht zentral kontrolliert werden kann, bleibt also weiterhin nur der Weg ins Fediverse.

Wo Bluesky gegenüber X Vorteile hat, ist in der Erweiterbarkeit von Bluesky durch user-definierte Labeler und Feed-Generatoren. Hier kommt die Grundidee, welche 2019 den Anstoss gab, durchaus zur Geltung. Welche Auswirkungen diese praktisch gesehen auf die User-Experience haben, schauen wir uns in einer Woche an. Zusätzlich werfen wir auch einen Blick auf Besitzverhältnisse und Finanzierung von Bluesky.

Wer mehr dazu wissen will

• Wikipedia-Eintrag zu Bluesky, mit einem Kurzabriss der Entwicklung angefangen vom Forschungsprojekt bei Twitter
• How decentralized is Bluesky really? Eine detaillierte, technisch umfassende Analyse der Architektur von Bluesky
• Maybe Bluesky has “won” Eine kritische Analyse mit verhalten positivem Fazit
• Pluralistic: Bluesky and enshittification Cory Doctorow erklärt, wieso er auch bei Bluesky die Gefahr von Enshittification sieht und darum kein Account anlegen wird
• BlueSky is cosplaying decentralization Eine ziemlich kritische Sicht auf die Bluesky-Architektur