Wie BlueSky funktioniert

• BlueSky ist eine Microblogging-App ähnlich wie Twitter oder Mastodon, aber das größere Ziel ist zu prüfen, ob auf dem AT Protocol (atproto) groß angelegte verteilte soziale Anwendungen möglich sind
• atproto ist keine Blockchain, kein DAO und kein NFT, sondern ein föderiertes Protokoll, bei dem mithilfe von Kryptografie und Merkle trees von Nutzern signierte Einträge auf PDS, Relay und App View verteilt verarbeitet werden
• Die Skalierbarkeit kommt aus einer Struktur, in der der Personal Data Server (PDS) eines Nutzers Beiträge nicht direkt an alle Follower sendet, sondern Relays die Netzwerkdaten sammeln und als Firehose bereitstellen
• Moderation ist in das Modell „speech vs reach“ aufgeteilt, wobei die Replikation von Inhalten und die Steuerung ihrer Sichtbarkeit getrennt werden und Labeler, Feed-Generatoren und App Views Filterung und Blockierung anwenden
• Stabile DIDs und domainbasierte Handles ermöglichen Kontoportabilität, aber der von BlueSky betriebene Auflösungsdienst für did:plc bleibt ein Zentralisierungsthema

---

Die Beziehung zwischen BlueSky und atproto

• BlueSky funktioniert derzeit als Microblogging-Anwendung, ist im Gesamtkonzept aber eine frühe Anwendung, die das Potenzial des Authenticated Transfer Protocol, also atproto, belegen soll
• Auf der BlueSky-Website heißt es, „soziale Medien sind zu wichtig, um von einigen wenigen Unternehmen kontrolliert zu werden, und wir bauen eine offene Grundlage für ein soziales Internet, an dessen Zukunft alle mitwirken können“
• Weil BlueSky ein Unternehmen ist, kann es die skeptische Sicht geben, dass „ein Unternehmen etwas baut, das nicht von Unternehmen kontrolliert werden sollte“, doch der Kern des Designs liegt eher in atproto als in der App
• atproto ist ein föderiertes Protokoll für groß angelegte verteilte soziale Anwendungen

Ein verteiltes Protokoll, keine Kryptowährung

• atproto kann wegen Formulierungen wie „verteiltes Netzwerk“ und „Protokoll“ wie eine Kryptowährung wirken, ist aber keine Kryptowährung
• Es ist keine Blockchain, kein DAO und kein NFT, sondern nutzt nur einige Techniken wie Kryptografie und Merkle trees

Die Grundstruktur von atproto

• atproto setzt auf eine föderierte Struktur, in der mehrere Akteure verschiedene Teile des Systems betreiben und miteinander kommunizieren
• Mit Blick auf eine große Nutzerbasis wurde es so entworfen, dass Akteure, die Last tragen können, mehr Aufgaben übernehmen, während die Belastung für andere reduziert wird
• BlueSky hatte zum Zeitpunkt des Schreibens in jener Woche mehr als 5 Millionen Nutzer und gilt als deutlich stabiler als Twitter in der Anfangszeit
• Aktuell basiert atproto zu 100 % auf Öffentlichkeit und bietet keine Funktionen wie private Nachrichten
  • Weil sich private Funktionen in einem föderierten System nur schwer korrekt umsetzen lassen, wurde entschieden, lieber sauber zu implementieren als eine Funktion mit gravierenden Einschränkungen zu veröffentlichen
  • Im Moment eignet es sich daher für Inhalte, die öffentlich sein dürfen

Records, Repositories, App View und Relay

• Nutzer erzeugen kryptografisch signierte Records, und diese Signatur belegt den Urheber
• Records folgen einem Schema namens Lexicon
• Records werden in einem Repository gespeichert, das als Dienst mit HTTP und WebSocket arbeitet
  • Solche Dienste werden gewöhnlich PDS (Personal Data Server) genannt
  • Nutzer können ihren PDS selbst betreiben oder einen von anderen gehosteten PDS verwenden
• Anwendungen lesen die im Netzwerk gespeicherten Records und bauen darauf ihre Funktionen auf
  • Solche Dienste heißen App View, weil sie eine bestimmte Sicht auf die Informationen bereitstellen
  • Eine Anwendung zu bauen bedeutet, ein Lexicon zu definieren, Records zu lesen, die dieses Lexicon verwenden, und den Rest zu ignorieren
• Wenn PDSs einander direkt benachrichtigen, entstehen große Skalierungsprobleme
  • Wenn bei jedem neuen Beitrag direkt an die Repositories aller Follower gesendet werden müsste, wäre das ineffizient und würde den Betrieb beliebter Repositories teuer machen
• Relay verringert dieses Problem, indem es Netzwerkinformationen sammelt und als Firehose bereitstellt
  • Eine tatsächliche App View betrachtet in der Regel nicht direkt die Repositories, sondern das Relay
  • Wenn ein Publisher einen Beitrag erstellt, benachrichtigt das Repository das Relay, und Follower sehen das Ergebnis, nachdem die App View die Relay-Ausgabe gefiltert hat
  • Relays können groß und teuer im Betrieb sein, aber man kann sich auch kleinere Relays vorstellen, die nur eine bestimmte Teilmenge von Nutzern weiterverbreiten

Das Moderationsmodell „speech vs reach“

• atproto ist ein Protokoll für soziale Anwendungen und betrachtet daher nicht nur, wie Menschen verbunden werden, sondern auch, wie Verbindungen unterbrochen werden
• Das Moderationsmodell von BlueSky ist in speech vs reach aufgeteilt
  • Die Ebene „speech“ repliziert Inhalte im Netzwerk unabhängig von ihrer Bedeutung
  • Die Ebene „reach“ stellt Werkzeuge bereit, um die Reichweite von Inhalten zu begrenzen, die Nutzer nicht sehen möchten
• Zu sagen, BlueSky „moderiere nicht“ oder lege „nur Wert auf freie Rede“, ist ungenau
  • Moderationswerkzeuge sind bereits in das Protokoll selbst eingebaut und können auch auf Inhalte von Anwendungen wirken, die nicht BlueSky sind
  • Nutzer sind nicht an die Moderationsentscheidungen oder das Fehlen von Moderation anderer gebunden, sondern können ihren eigenen Moderator wählen

Feed-Generator

• In atproto werden Feeds in einen separaten Dienst, den Feed-Generator, ausgelagert
• Der Feed-Generator nimmt die vom Relay erzeugte Firehose entgegen, filtert und sortiert Inhalte nach gewünschten Kriterien und zeigt sie als Liste an
• Nutzer können ihre selbst erstellten Feeds mit anderen teilen
• Beispiel-Feeds:
  • Quiet Posters: zeigt Beiträge von Menschen, die nicht häufig posten
  • the ‘Gram: zeigt nur Beiträge mit angehängten Fotos
  • My Bangers: zeigt die eigenen beliebten Beiträge
• Eine der Stärken von BlueSky ist, dass Nutzer ihren eigenen algorithmischen Feed erstellen und leicht teilen können
• Feeds sind eine vergleichsweise neue Ergänzung in atproto, daher möglicherweise noch nicht vollständig ausgereift und künftig veränderbar

Labeler und Moderation auf Netzwerkebene

• Ein Labeler ist ein Dienst, der Inhalten oder Konten Labels zuweist
• Nutzer können einen bestimmten Labeler abonnieren und ihre Erfahrung je nach Labels eines Beitrags unterschiedlich gestalten
• Ein Labeler kann so arbeiten, wie es die Betreiber möchten
  • Er kann automatische Algorithmen auf Beiträge anwenden
  • Menschen können Inhalte direkt freigeben oder ablehnen
  • Er kann als Blockliste oder NSFW-Filter dienen
• Die Label-Funktion existiert, aber zum Zeitpunkt des Schreibens ist unklar, ob Nutzer selbst direkt einen Labeler betreiben können
  • BlueSky betreibt einen eigenen Labeler
  • Eine externe Veröffentlichung ist bislang nicht bekannt
• Durch die Kombination aus Feed, App View und Labeler können Nutzer ihre Moderationserfahrung innerhalb und außerhalb einer Anwendung wählen
  • In einem Feed kann man nur SFW sehen, an anderer Stelle NSFW-Inhalte zulassen
  • Man kann Blocklisten erstellen und teilen
• Weil Moderationswerkzeuge nicht auf Anwendungsebene, sondern auf Protokollebene arbeiten, lässt sich derselbe Labeler auch in anderen Anwendungen auf atproto nutzen
  • Selbst wenn auf atproto ein Instagram-Klon entstünde, könnte derselbe Blocklisten-Labeler verwendet werden
  • Einen Nutzer, den man an einer Stelle blockiert hat, kann man auf Wunsch überall blockieren

Unterschiede zum Mastodon-Instanzmodell

• Das atproto-Modell unterscheidet sich von Mastodon, wo ein bestimmtes „Konto“ auf einer bestimmten „Instanz“ liegt
• Fragen wie „Was passiert, wenn meine Instanz defederiert wird?“ lassen sich nicht direkt übertragen
• Ein ähnliches Ziel kann erreicht werden, indem man Beiträge von einem bestimmten PDS ignoriert, die man nicht sehen möchte
• Diese Entscheidung trifft jedoch nicht der Serverbesitzer stellvertretend für das Nutzerkonto, sondern der Nutzer selbst

DID, Handle und Kontoportabilität

• Der Kern der Identität in atproto ist die DID (Decentralized Identifier)
  • Eine beispielhafte DID hat die Form did:plc:3danwc67lo7obz2fmdg6jxcr
• Für die tatsächlich sichtbare Identität wird zusätzlich ein Handle verwendet, und dieses Handle ist ein Domainname
  • Beispiel: @steveklabnik.com
  • BlueSky-Nutzer können ein Handle im Format @username.bsky.social erhalten
• Weil die DID stabil ist, führt ein Wechsel des Handles von @steveklabnik.bsky.social zu @steveklabnik.com nicht zu Unterbrechungen für Follower; in der UI ändert sich nur das Handle
• Um eine Domain als Handle zu verwenden, übernimmt man die vom PDS erzeugte DID und fügt im DNS dieser Domain einen TXT-Record hinzu
• Auch Nutzer ohne DNS-Kenntnisse können über die Partnerschaft von BlueSky mit NameCheap eine Domain registrieren und als Handle einrichten, ohne technisches Wissen zu benötigen
• Die Kontoportabilität basiert auf DID und kryptografischen Signaturen
  • Inhalte, die von einer Person mit einer bestimmten DID erstellt werden, werden signiert und im Netzwerk repliziert
  • Um ein „Konto“ zu beenden, müsste man die Nutzung des Schlüssels des Nutzers zwangsweise unterbinden, doch nach dem Netzwerkdesign hat kein anderer Akteur Zugriff auf diesen Schlüssel
  • Selbst wenn ein PDS ausfällt, lassen sich Inhalte aus dem Netzwerk zurückholen und der Umzug zu einem neuen PDS bekannt machen

Die Debatte um did:web und did:plc

• BlueSky unterstützt zwei DID-Varianten
  • did:web: ein domainbasierter Ansatz
  • did:plc: ein eigener von BlueSky implementierter Ansatz
• Das plc in did:plc steht für „placeholder“, und BlueSky plant, es weiterhin zu unterstützen
• did:plc hat die Schwäche, dass die korrekte Information über einen von BlueSky betriebenen Dienst aufgelöst werden muss
  • Eine Beispielabfrage ist unter plc.directory möglich
  • Deshalb gibt es Kritik, dass BlueSky Nutzer dadurch stärker bannen kann, als es das Netzwerkdesign eigentlich vorsieht
• Es gibt aber auch Gründe, das Problem nicht als fatal anzusehen
  • Wer das nicht möchte, kann did:web verwenden
  • Das System ist so gestaltet, dass ein Wechsel möglich ist, wenn später etwas Besseres entsteht
  • Künftig könnte die Governance von did:plc auf ein Konsensmodell umgestellt werden
  • Auch andere Akteure könnten einen did:plc-Dienst betreiben und verwendet werden

Wie BlueSky auf atproto aufsetzt

• BlueSky ist eine Anwendung, die auf dem atproto-Netzwerk aufbaut
• BlueSky betreibt eine App View und die dazugehörige Webanwendung
• Für Nutzer, die sich über die Web-App registrieren, betreibt es auch PDSs sowie das Relay, über das diese PDSs kommunizieren
• BlueSky veröffentlicht zwei Arten von Lexicons
  • com.atproto.*: Low-Level-Operationen, die jede Anwendung im Netzwerk benötigt
  • app.bsky.*: Operationen, die speziell auf BlueSky zugeschnitten sind
• Das Produktziel von BlueSky ist, dass Nutzer all diese technischen Details nicht kennen müssen, um es zu verwenden
  • Da es keine Instanzen gibt, entfällt der Schritt, zur Kontoerstellung eine Instanz auswählen zu müssen
  • Selbst wenn ein Host ausfällt, kann man umziehen, und Follower müssen das nicht einmal bemerken

Neue Anwendungen auf atproto entwickeln

• Eine atproto-Anwendung beginnt mit der Erstellung eines Lexicons
• Danach betreibt man eine App View, die aus den Daten des Netzwerks die Daten verarbeitet, die zu diesem Lexicon gehören
• Die Anwendung muss es Nutzern ermöglichen, mit diesem Lexicon Daten in ihren eigenen PDS zu schreiben

Zentrale Trennung im Design

• Die Trennung der Rollen von atproto und BlueSky ist ein wichtiges Designelement
• Eine „Killer-App“ wie BlueSky liefert einen Grund, das Netzwerk zu nutzen
• BlueSky selbst dient auch als Dogfooding, also als praktischer Nachweis, dass sich auf atproto tatsächlich reale Anwendungen bauen lassen

[GN⁺]

Meinungen auf Hacker News

• Wirkt extrem gut durchdacht und scheint einige der großen Probleme von ActivityPub zu lösen.
  Früher hatte ich kein Interesse an Bluesky, aber jetzt überlege ich, mir einen Account anzulegen.

  • Das Hauptproblem von Bluesky und dem AT Protocol liegt weniger in den technischen Vorzügen als in einer ausgeprägten NIH-Haltung (Not invented here).
    Statt bestehender Protokolle wie dem überall verwendeten user@host und WebFinger hat man sich für „Domains als Identität verwenden“ entschieden; und man hat sich nicht an dem orientiert, was ACME bei Zertifikaten bereits erledigt, sodass jemand die Domain s3.amazon.com auf Bluesky übernehmen konnte https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
    Außerdem wurde mit XRPC ein neues Remote-Call-Protokoll geschaffen, und man nutzt mit Lexicon ein codegenerierungsbasiertes Datenschema, dessen Vorteile gegenüber protobuf oder jsonld unklar sind – abgesehen davon, dass es neuer ist.
    Es ist schwer, einem „offenen Netzwerk“ zu vertrauen, das immer wieder zeigt, dass es andere Ökosysteme nicht respektieren oder mit ihnen sprechen will; und man fragt sich, wie viele typische Designfehler noch hineingeraten sind, weil man gemeinsames Wissen ablehnt.
  • Das AT Protocol sieht technisch besser aus, wirkt sozial aber wie eine Struktur, die leicht scheitern kann.
    Es gibt keinen sozialen Anreiz dafür, dass jemand Relays und Moderationsdienste installiert und betreibt, die von realen Communities getrennt sind; übrig bleiben nur finanzielle Anreize wie kostenpflichtige Dienste, eingefügte Werbung, Data Mining oder Informationsmanipulation.
    Wenn Datenverteilung und Moderation zentralisiert werden, werden sowohl Hostingkosten als auch Personalaufwand zu einem großen Geschäft, und es läuft praktisch darauf hinaus, dass andere als Bluesky daran gehindert werden, eigene Relays oder Moderationsdienste zu betreiben.
    Trotz der Nachteile von ActivityPub sorgt ein Ansatz wie „Communities mit Tor“ dafür, dass Nutzer sich einem Server zugehörig fühlen und Betreiber sowie Moderatoren stolz darauf sind, den Nutzern einen Dienst bereitzustellen.
    Das AT Protocol erlaubt technisch mehrere Relays und Moderationsdienste, aber es ist fraglich, wie viele davon in der Realität entstehen werden.
    Ich halte es für einen Fehler, ein Social-Network-Protokoll ausschließlich aus einer rein technischen und adversarialen Perspektive zu beurteilen. Man ist zwar nicht an einen Server gebunden, wird dafür aber auch von engmaschigen Communities getrennt, und es steht nichts mehr auf dem Spiel.
    Dass man in Bezug auf Daten, Identität und Community nichts zu verlieren hat, ist ein zweischneidiges Schwert.

• Soweit ich weiß, gibt es derzeit nur ein Relay.
  Wenn mehrere Relays entstehen, werden sie jeweils eine andere Sicht auf das Netzwerk haben, und das Relay, das mehr Beiträge enthält, wird das bessere Relay sein.
  Relay-Vielfalt statt eines einzelnen dominierenden Relays zu erreichen, könnte ziemlich schwierig werden; es wirkt ähnlich wie der Versuch alternativer DNS-Systeme, traction zu gewinnen. Wenn mein Beitrag dann nicht vom dominierenden Relay erfasst wird, scheint es keinen Ausweg zu geben.
  Es ist noch sehr früh, also muss es nicht so kommen; und selbst wenn es ein dominierendes Relay gibt, ist GitHub auch nicht so schlimm, und Alternativen gibt es ebenfalls.

  • Früher fand ich Bluesky ziemlich verwirrend, aber inzwischen habe ich gemerkt, dass das vor allem an der Terminologie lag.
    Wenn man das System [Microblog] -> [Indexer] -> [Client] nennt, ist es leichter zu verstehen.
    Tatsächlich gibt es mehr Komponenten, aber so funktioniert Bluesky im Kern ungefähr; nur die Namen scheinen anders gewählt zu sein, als man erwarten würde.
    Ein Indexer ist nötig, weil User-IDs im System nicht statisch bleiben. DID:PLC beginnt als Teilstring eines Hashes, aber wegen „Key Rotation“ kommt es im Laufe der Zeit zu einer merkwürdigen kryptografischen Umordnung, bei der sich die User-ID ändert, ohne dass der Nutzer es merkt.
    Man kann sich das wie ein System à la LiveJournal vorstellen, bei dem sich Handles ständig ändern und man eine Autorität braucht, die diese Änderungen verfolgt. Natürlich kann man nur kurze Nachrichten posten, ohne Titel oder Markdown-Unterstützung.
    Persönlich warte ich auf ein neues DID:PLC, das einen statischen öffentlichen Schlüssel entgegennimmt und Nachrichten mit einem privaten Schlüssel signiert. Dann gäbe es viel weniger zu verfolgen, und Self-Hosting sowie local-first-Entwicklung würden deutlich einfacher.
  • Falls nötig, könnte der Client, also App View, meiner Meinung nach mehrere Relays parallel verwenden.
    Das wäre wie eine lokale GitHub-UI, die Daten aus mehreren GitHub-Instanzen holt, die unterschiedliche, aber möglicherweise überlappende Repository-Mengen hosten.
    Es ähnelt auch einem Usenet-Client, der Newsgroups von mehreren NNTP-Servern zusammenführt und anzeigt.
  • Ich würde erwarten, dass alle Relays – abgesehen von unterschiedlichen Einschätzungen zu illegalen Inhalten – die gesamten Daten besitzen.
    Mich würde interessieren, warum du denkst, dass jedes Relay eine andere Sicht auf das Netzwerk haben wird.

• Mich interessiert, wie BlueSky verlässlich zusichern kann, dass es nur die offenen Teile des Protokolls verwenden wird.
  BlueSky wirkt tatsächlich ziemlich zentralisiert, daher sehe ich keinen technischen Grund, warum der First-Party-Client zwingend ein ATProto-Client sein müsste.
  Kurz- oder mittelfristig wäre das ein massiver Vertrauensbruch gegenüber den Nutzern, aber die faktisch verteilte Struktur von ActivityPub wirkt hier wie eine stärkere Absicherung.

  • Ich weiß nicht, was mit einem First-Party-BlueSky-Client gemeint ist.
    Falls gemeint ist, dass First-Party-Relay und PDS über ein anderes Protokoll kommunizieren könnten, verstehe ich nicht recht, worin die Sorge besteht.
    Auch zwei ActivityPub-Clients könnten über ein Protokoll miteinander sprechen, das nicht ActivityPub ist.
  • Der gesamte Code ist Open Source, deshalb kann man darauf vertrauen.
    Genau das machen sie auch, und wenn sie anfangen würden, davon abzuweichen, würden die Leute das sehr schnell bemerken.

• Dass die Unterscheidung zwischen „Äußerung und Reichweite“ so weit getrieben wurde, ist gut, aber langfristig fühlt sich Mastodon wegen seiner Einfachheit wie die klügere Wahl an
  Kurzfristig kann Mastodon allerdings weniger unterhaltsam oder weniger nützlich sein, weil die Auswahl der Feeds dort definitiv schwieriger ist
  Die Kernfrage ist, was ein hypothetischer, vermutlich wohlhabender oder mächtiger böswilliger Akteur tun könnte, wenn er hier das Spielfeld beeinflussen wollte
  Im Text wird dieser Punkt mit Formulierungen wie „Ich weiß nicht genau, wie Feeds funktionieren“ viel zu oberflächlich abgetan, was sehr verdächtig wirkt. Es sieht so aus, als wüsste man sehr wohl, wie Feeds funktionieren werden, und auch, dass dort Macht und Geld liegen, und als wolle man genau diesen Punkt festhalten

  • Die Zusammenfassung „Ich weiß nicht genau, wie Feeds funktionieren“ scheint nicht passend zu sein
    Der Autor sagt Folgendes: „Feeds sind eine jüngere Ergänzung zu atproto; sie existieren also, aber die Funktion ist möglicherweise noch nicht vollständig ausgereift und könnte sich künftig ändern. Warten wir es ab. Aus meiner Sicht funktioniert es gut, aber ich verfolge nicht alle technischen Details auf niedriger Ebene.“
    Direkt im Absatz darüber steht auch dieser Kontext: „Eine der Killerfunktionen von BlueSky gegenüber anderen Microblogging-Tools ist die vollständige Wahlfreiheit der Nutzer. Wenn ich meinen eigenen Feed-Algorithmus bauen möchte, kann ich das tun und ihn einfach mit anderen teilen.“
  • Ich weiß nicht, aus welchem Teil hervorgehen soll, dass man nicht wisse, wie Feeds funktionieren
    Feeds sind Open Source, existieren bereits und man kann sie selbst betreiben
    Auch ist nicht klar, was mit „das Spielfeld beeinflussen“ gemeint ist, also welches Spielfeld in welchem Sinne. Hier gibt es viele bewegliche Teile

• Die Idee, dass Nutzer einen vom Hosting-Anbieter unabhängigen Moderationsanbieter wählen können und sich dadurch weniger Gedanken über die Wahl der Instanz machen müssen, klingt gut
  Allerdings müssen Instanzen wohl weiterhin moderieren, um keine Inhalte zu hosten, die vor Ort illegal sind
  Am Ende wird das für die Betreiber von Instanzen eine ziemlich schwierige Aufgabe und kann zu erheblichem Chaos führen. Vielleicht verstehe ich es auch falsch

  • Wer Inhalte hostet, muss mit den rechtlichen Folgen der gehosteten Inhalte umgehen, und daran führt letztlich kein Weg vorbei
    Das gilt aber unabhängig davon, welches Protokoll man verwendet
  • Du verstehst das nicht falsch. Ich halte die Dezentralisierung von Bluesky eher für Schein
    Ein PDS läuft zwar auf einer brauchbaren Ubuntu-Kiste, aber selbst dieser Text räumt ein, dass Relays teuer sind und einen riesigen zentralen Kontrollpunkt darstellen
    Wie sieht Blueskys Plan gegen Spam aus? Vermutlich wird auf Relay-Ebene blockiert
    Der DID-Server ist ein weiterer zentraler Kontrollpunkt
    Immerhin kann man PDS nach Belieben betreiben

• Eine interessante Kleinigkeit zu Bluesky, die an einen kürzlichen Artikel anknüpft: Auch das ist gewissermaßen nach einer Person benannt
  Der Name der CEO bedeutet auf Chinesisch wörtlich blue sky

  • Interessanterweise hatte Twitter das Projekt bereits bluesky genannt, bevor ich dazugekommen bin
    Das ist Zufall. Allerdings bedeutet mein zweiter Vorname auf Chinesisch bluesky

• Dieser kurze Comic ist auch gut: https://bsky.social/about/welcome-to-bluesky-comic

• Wenn Bluesky die Unterstützung für did:plc einstellt, gehen dann alle bestehenden PLC-Identitäten kaputt?
  Ich frage, weil PLC so funktioniert, dass es deren Dienst anpingt

  • https://plc.directory kann gespiegelt werden, und falls so etwas passiert, könnte ein neuer Mirror zum autoritativen Server werden

• Gegenüber Drittanbieter-Labelern bin ich skeptisch
  Wie kann man Missbrauch verhindern?

  • Nutzer wählen aus, welche Drittanbieter-Labeler sie abonnieren
    Wenn ein Labeler-Dienst beginnt, seine Stellung zu missbrauchen, können Nutzer ihn einfach abbestellen
    Eine ausführliche Erklärung dazu, wie Bluesky Labeler in das Ökosystem einbinden will, gibt es unter https://github.com/bluesky-social/proposals/tree/main/0002-l...
  • Die Antwort hängt davon ab, welche Art von Missbrauch gemeint ist
    Ich kann meine Sicht dazu sagen, aber die Frage ist so breit, dass ich nicht weiß, wo ich anfangen soll
  • Wir werden bald deutlich mehr zum Thema Moderation veröffentlichen, aber die Grundlagen von Labelern sind folgende
    Jeder im Netzwerk kann alles labeln, einschließlich anderer Labeler
    Apps können Labeler, die Nutzer abonnieren können, ähnlich sichtbar machen wie derzeit die benutzerdefinierten Feeds in Bluesky
    Apps können außerdem kuratieren, wie Labeler angezeigt und gerankt werden, so wie sie benutzerdefinierte Feeds derzeit nach Beliebtheit anzeigen und ranken, die durch Likes und Speichern ausgedrückt wird

• Der Ansatz, dass „Moderationswerkzeuge zur Reichweitenebene gehören. Sie erfassen alle Äußerungen, bieten mir aber Möglichkeiten, die Reichweite dessen einzuschränken, was ich nicht sehen möchte“, wirkt am Ende wie eine Moderation nach dem Motto: „Wenn du es nicht sehen willst, mach die Augen zu.“
  Ich weiß, dass das im Silicon Valley eine beliebte Philosophie ist, halte sie aber für grundlegend fehlerhaft.
  Es gibt legitime Situationen, in denen verhindert werden sollte, dass andere, nicht betroffene Personen über eine bestimmte Angelegenheit sprechen oder bestimmte Inhalte erhalten.
  Typische Beispiele sind Cybermobbing, Doxing und Racheporno. Etwa wenn zwei oder mehr Personen darüber sprechen, wie sie einer dritten Person schaden können, oder private, erniedrigende oder falsche Informationen veröffentlichen.
  Diese Informationen aus dem Feed des Opfers zu entfernen, ist völlig nutzlos; wahrscheinlich würden sie dort von Anfang an gar nicht auftauchen. Der Schaden entsteht dadurch, dass andere Menschen diese Inhalte sehen oder sich an der Diskussion beteiligen, und dieser Schaden ist real.
  In traditionellen Moderationssystemen können Moderatorinnen und Moderatoren solche Handlungen stoppen, indem sie Beiträge für alle löschen oder Täter sperren. In einem System, das Inhalte „nur ausblendet“, ist das nicht möglich.
  Geteilte Blocklisten oder „Labels“ funktionieren ebenfalls nicht. Die Konsumenten der Inhalte haben keinen Anreiz, sie zu blockieren; im Gegenteil, sie wollen den Racheporno sehen.
  Blockieren möchte das Opfer, aber das Opfer hat nicht die Macht, alle anderen zur Nutzung einer bestimmten Blockliste zu zwingen. Denn der Kern dieses Systems besteht darin, dass niemand anderen eine Blockliste aufzwingen kann.

  • In diesem Bereich wird noch mehr kommen. In diesem Artikel habe ich mich auf den Normalfall konzentriert und die schlechten Fälle nicht behandelt.
    Das Team hat sich diese Probleme angesehen und sich „auch mit Experten beraten“, aber da es noch laufende Arbeit ist, fühle ich mich nicht berechtigt, dazu etwas zu sagen.
    Der Punkt, dass „Labels nicht funktionieren, weil die Leute es sehen wollen, statt es zu verhindern“, gehört zu dem Problemraum, den das Team ausdrücklich anerkannt hat.
    Zusätzlich hier als Referenz: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei