Vergleich von Bluesky und dem Fediverse
(hackers.pub)Zentrale Architekturunterschiede: Nachrichtenübermittlung vs. Shared Heap
-
Fediverse: nutzt ein der E-Mail ähnliches Modell der „Nachrichtenübermittlung“
- Nachrichten werden direkt an bestimmte Empfänger zugestellt
- Nachrichten werden nur an die benötigten Server gesendet und sind dadurch effizient
- Einzelpersonen können auch auf günstiger Hardware einen Node betreiben
-
Bluesky: nutzt ein „Shared-Heap“-Modell
- Alle Nachrichten werden in einem zentralen „Relay“ gespeichert
- Nutzer filtern relevante Informationen aus dem Relay heraus
- Erfordert groß angelegte zentralisierte Infrastruktur
- Die Betriebskosten für Relays steigen stark an (in nur 4 Monaten von 1 TB → 5 TB)
Globale Sicht und Zentralisierungsproblem
-
Bluesky: konzentriert sich darauf, eine konsistente netzwerkweite Gesamtsicht aufrechtzuerhalten
- Alle AppViews benötigen Informationen wie globale Sperrlisten
- Sperrlisten sind öffentlich, was Datenschutzprobleme verursacht
- Ohne zentralisierte Kontrolle schwer umzusetzen
-
Fediverse: jeder Server setzt seine Richtlinien unabhängig durch
- Bietet den Nutzern mehr Autonomie
- Sperrinformationen sind so gestaltet, dass sie nicht öffentlich werden
Vergleich der Protokolloffenheit
-
Fediverse/ActivityPub: offener Standard, von der W3C angenommen
- Kann von jedem frei implementiert werden
- Gewährleistet Interoperabilität zwischen verschiedener Software
- Community-getriebene Weiterentwicklung über FEP
-
Bluesky/AT Protocol: unternehmensgetriebenes Protokoll
- Sein Status als offener Standard ist noch nicht etabliert
- Begrenzte Skalierbarkeit und Nachhaltigkeit
Zentralisierung von Direktnachrichten (DMs)
-
Bluesky: alle DMs laufen über einen zentralen Server
- Unabhängig vom PDS oder Relay des Nutzers werden sie über das Unternehmen Bluesky übertragen
- Das Unternehmen Bluesky kann auf alle DMs zugreifen
- Widerspricht dem Konzept des „vertrauenswürdigen Ausstiegs“
-
Fediverse: direkter Übermittlungsmechanismus zwischen Servern
- Nur der Administrator des eigenen Servers kann auf Nachrichten zugreifen
Probleme bei der Umsetzung portabler Identitäten
-
Bluesky: nutzt DIDs, ist aber weiterhin auf Zentralisierung angewiesen
did:webunddid:plcsind auf DNS und zentrale Register angewiesen- Anfangs nutzten alle Konten dieselben
rotationKeys - Nutzerschlüssel werden von Bluesky verwaltet
-
Fediverse: das Konzept nomadischer Identität entwickelt sich weiter
- Bietet mit Protokollen wie Zot umfassendere Portabilität
- Kontinuierliche Verbesserungen über FEP-ef61 usw.
Kommerzieller Druck und Nachhaltigkeit
-
Bluesky: abhängig von Venture-Capital-Finanzierung
- Wahrnehmung: „Organisationen sind der Feind der Zukunft“
- Kommerzieller Druck durch die Einführung kostenpflichtiger Konten und Werbung
- Renditedruck von Investoren könnte Dezentralisierung behindern
-
Fediverse: vielfältige Betreiber und Finanzierungsmodelle
- Ein Ökosystem aus kommerziellen, nichtkommerziellen und privaten Nodes
- Kein Single Point of Failure
Fazit
- Bluesky kann mit seiner nutzerfreundlichen Oberfläche und der Twitter-ähnlichen Erfahrung eine hervorragende Alternative zu X sein
- Aufgrund des zentralisierten Designs, der Betriebskosten, der Datenschutzanfälligkeit und der Abhängigkeit von einem Unternehmen ist es jedoch keine Alternative zum Fediverse
- Beide Systeme verfolgen grundlegend unterschiedliche Ziele und Designphilosophien und könnten sich idealerweise so weiterentwickeln, dass sie einander ergänzen
1 Kommentare
Es gibt auch dieses Gegenargument: https://hackers.pub/@yurume/0195cc17-b1ed-712e-9ecf-dcc49158220a