Die Gefahr ist trotzdem real.
Übersicht
- Danksagung
- Abstract
- Die erste Warnung
- Vier Analysen, ein gemeinsamer Befund
- Das Protokoll selbst ist nicht die behauptete Bannmaschine
- Der öffentliche Fork-Code trägt die harte These nicht
- Das grosse Aber
- Warum Gemini zugleich nützlich und gefährlich ist
- Die politische Gefahr beginnt dort, wo Instrumente institutionalisiert werden
- Gerechte Wertung von @tachy_
- Schlussbemerkung
- In eigener Sache
- Quellen
- Changelog
Danksagung
Die spätere Präzisierung des 𝕏 Users @tachy_ 1 verdient an erster Stelle ausdrücklich Respekt ! Wer eine zugespitzte erste These2 nach kritischer Nachfrage dessen Geltungsbereich nachschärft,3 betreibt erkenntnistheoretische Hygiene. Genau darin liegt wissenschaftliche Redlichkeit. Die nachgereichte Klarstellung, dass sich die gemeinte „technische Kopplung“ nicht ausschliesslich auf den sichtbaren Fork-Code, sondern auf die verfolgte Absicht beziehe, korrigiert die engste und angreifbarste Fassung der ursprünglichen Warnung. Das ist keine Schwäche. Das ist Stärke. Auf den Ausgangs-Tweet bin ich durch Hadmuts Blogbeitrag vom 07.05.2026 aufmerksam geworden.4 Dank gilt daher auch Hadmut Danisch5.
Abstract
Die offene Behauptung, das auf Bluesky basierende AT-Protokoll sei so angelegt, dass Blocklisten technisch im Hintergrund lebenslang an persönliche Ausweisverifikation gekoppelt würden, hält einer sauberen Prüfung nicht stand. Das Protokoll arbeitet mit dezentralen Identifikatoren, mit DIDs,6 mit öffentlichen Block-Records, mit Labelern7 und mit portablen Accounts. Es kennt keine eingebaute Schicht staatlicher Identitätsprüfung, keine protokollnative KYC-Logik8 und keine strukturell angelegte, personengebundene Bann-Metaphysik. Die öffentlich sichtbaren W-Social-Forks zeigen eine solche Logik ebenfalls nicht. Gerade dort, wo der X-Post am härtesten war, bleiben die Belege aus.9 10 11 12 13
Damit ist die Gefahr nicht erledigt. W Social verlangt für aktive Teilnahme nach eigener Datenschutzerklärung eine verifizierte menschliche Identität, zieht beim Signup eine W-Identity-UUID,14 das Passland und das Geburtsjahr heran und verarbeitet zugleich Social-Graph-Daten einschliesslich Blocklisten sowie Moderation „illegal or harmful content“ Aus dieser Architektur folgt noch kein bewiesenes Bannsystem. Aus ihr folgt aber sehr wohl ein ernstzunehmender Hebel. Wenige proprietäre Backend-Komponenten würden genügen, um kontoübergreifende Personenkorrelation, Re-Registration-Sperren oder AppView-seitige Sichtbarkeitsreduktionen technisch zu ermöglichen. Die reale Gefahr liegt nicht im offenen Protokoll, sondern in der Lücke zwischen sichtbarem Open-Source-Sockel und unsichtbarer Betreiberlogik.15
Die erste Warnung
Öffentliche Warnungen erfüllen eine nützliche Funktion. Sie reissen Fälle aus der PR-Zone heraus, bevor Hochglanznarrative sich als vermeintliche Realität verfestigen. Wer angesichts eines verifizierungsbasierten sozialen Netzwerks nicht mindestens misstrauisch wird, hat die letzten Jahre digitalpolitischer Verschiebung nicht verstanden. Das Problem beginnt dort, wo berechtigtes Misstrauen ohne saubere Quellenkette in technische Totalbehauptungen umkippt.
Der 𝕏-Post von @tachy_ enthielt inhaltlich drei Behauptungen.
- W Social baue auf Bluesky und ATProto auf.
- Blocklisten seien technisch im Hintergrund lebenslang an persönliche Ausweisverifikation gekoppelt.
- Ein einziger kritischer Post könne zu lebenslangem Ausschluss vom Diskurs führen.
Der erste Teil ist banal und zutreffend. Der zweite und dritte Teil sind der eigentliche Streitgegenstand. Denn sie behaupten nicht bloss ein Risiko, sondern eine bereits angelegte technische Logik. Zwischen beiden liegt der ganze Unterschied zwischen Analyse und Überdehnung.
Die schärfste Form dieser Warnung war deshalb methodisch verwundbar. Sie behandelte eine vermutete Betreiberarchitektur, eine politische Absicht und ein offenes Protokoll phasenweise so, als handele es sich um dieselbe Sache. Ein solches Zusammenziehen mag rhetorisch effizient sein. Technisch ist es grob. Wer Protokollebene, Fork-Code, proprietäres Backend und Plattformpolitik nicht trennt, baut dem Gegenüber die bequemste Verteidigung gleich selbst. Die Frage ist also nicht, ob Misstrauen gerechtfertigt war. Die Frage lautet, auf welcher Ebene es hätte formuliert werden müssen.
Vier Analysen, ein gemeinsamer Befund
Gerade deshalb ist die parallele Auswertung von vier verschiedenen Analysen aufschlussreich. Der strenge Code-Audit16 des öffentlichen GitHub-Materials gelangt zu dem Befund, dass die drei sichtbaren W-Social-Repositories dünne oder jedenfalls weitgehend nahe am Upstream liegende Forks von bluesky-social/atproto, bluesky-social/pds und bluesky-social/ozone sind. Er findet im publizierten Material keine eID17– oder KYC-Logik, keine personengebundene Moderationspersistenz, keine Hash-Speicherung staatlicher Identitätsdaten und keine Cross-Account-Ban-Mechanik. Das Ergebnis lautet unmissverständlich: Der öffentliche Code stützt die starke Ausgangsthese nicht.
Die strengere ChatGPT Pro 5.5 Tiefenrecherche18 kommt zum selben Befund, formuliert ihn aber architektonisch differenzierter. Danach ist belegt, dass W Social auf ATProto aufsetzt, für aktive Teilnahme eine verifizierte menschliche Identität verlangt und beim Signup eine W-Identity-UUID, Passland und Geburtsjahr übernimmt. Belegt ist ebenfalls, dass ATProto und Bluesky öffentliche Blocks,19 Modlists, Labeler und mehrschichtige Moderation kennen. Nicht belegt ist hingegen, dass Block- oder Moderationsstatus nachweislich an diese UUID oder an reale Ausweisdaten gekoppelt wären. Die Analyse zieht genau dort die Bremse, wo aus Machbarkeit gern Wirklichkeit gemacht wird. Sie nennt die Koppelung ein plausibles Risiko, nicht einen nachgewiesenen Ist-Zustand.
Der Grok 4.3 Expert Bericht20 folgt dieser Linie ebenfalls. Auch dort erscheint das Protokoll nicht als personengebundene Bannarchitektur, sondern als klassisches ATProto-Setup mit drei Forks, DID-gebundenen Blocks und fehlender öffentlicher Evidenz für ID-Block-Kopplung. Die Risiken werden an der Betreiber-Overlay-Schicht verortet, nicht im offenen Protokoll selbst. Der Bericht spricht, sichtbar auf den ersten Seiten, gerade nicht von einem bereits im Code nachgewiesenen Lifetime-Mechanismus, sondern von einer weitgehend nicht entscheidbaren Backend-Zone.
Die Gemini 3.1 Pro Tiefenrecherche21 nimmt denselben Ausgangspunkt, geht in der Schlussbewegung aber erheblich weiter. Auch Gemini widerspricht ausdrücklich der These, das AT-Protokoll selbst sei für lebenslange ID-Kopplung von Blocklisten gebaut. Auch Gemini hält fest, dass die öffentlichen Forks keine harte, sichtbare UUID-Block-Korrelation zeigen. An diesem Punkt ist es kongruent. Dann zieht es aus UUID-Ingestion, Retention-Klauseln22 und der Möglichkeit eines proprietären Gateways einen sehr starken architektonischen Schluss und spricht von einer „highly plausible technical reality„, von der technisch fast voll ausgestatteten Möglichkeit lebenslanger Exklusion und von einer faktisch bereitliegenden Exil-Architektur. Genau dort verlässt Gemini den Bereich des bloss sauber Markierten und beginnt, eine plausible Hinterbühne fast wie eine vorentschiedene Maschinenlogik zu behandeln.
Das Gesamtbild ist also bemerkenswert stabil. Alle vier Analysen verneinen die Protokollthese. Alle vier sehen im öffentlichen Code keinen Beleg für die starke Ausgangsbehauptung. Die Trennlinie verläuft nicht zwischen wahr und falsch, sondern zwischen unterschiedlich strengen Übergängen von gesichertem Befund zu plausiblem Backend-Risiko.
Das Protokoll selbst ist nicht die behauptete Bannmaschine
Wer wissen will, was das AT-Protokoll tatsächlich tut, sollte in die Spezifikationen sehen. Dort steht, dass ATProto DIDs als persistente Account-Identifier verwendet. Diese DIDs sind die Kernidentität eines Kontos. Handles sind menschenlesbare, änderbare Auflösungen, die an eine DID gebunden werden. Schon an dieser Stelle fällt die grosse These in sich zusammen. Ein Protokoll, das von DIDs, Handle-Auflösung, PDS-Hosting23 und Migration spricht, redet nicht von staatlich verifizierter Personidentität als nativem Layer.24
Auch die Block-Architektur bestätigt das. Die offizielle Bluesky-Dokumentation zeigt, wie ein Block-Record angelegt wird: Das repo ist die DID des blockierenden Kontos, das subject die DID des blockierten Kontos.25 Mehr steht dort nicht. Kein Pass, kein Personalausweis, kein KYC-Token, kein biometrischer Proxy. Wer unblocken will, löscht den Block-Record wieder. Das ist keine philosophische Frage, sondern eine technische. Die Dokumentation sagt es wörtlich: „unblocking a user is as simple as deleting the record.“ Ein „für immer“ , das schon im Protokoll angelegt wäre, sieht anders aus.26
Noch präziser wird das im Bluesky-Beitrag zur Block-Implementierung. Blocks sind dort ausdrücklich „public and enumerable data„, weil alle Server im Netzwerk von ihnen wissen müssen, um sie durchzusetzen. Sie liegen als app.bsky.graph.block-Records in Account-Repositories. Durchgesetzt werden sie von PDS, AppViews und Clients. Genau das ist der Punkt: kontobezogene, netzweit respektierte Interaktionskontrolle, keine Ausweisarchitektur. Die öffentliche Enumerierbarkeit macht Blocks transparent und in bestimmter Hinsicht auch problematisch. Sie macht sie aber nicht zu einer im Hintergrund an Personen angeketteten Schicksalsmarke.
Dasselbe gilt für die Moderationsarchitektur. Bluesky trennt zwischen Labelern, Reports, takedown-fähigen Moderationsdiensten, User-Präferenzen und AppView-Logik. Nutzer können Labeler abonnieren; AppViews werten Labeler aus; Moderationsentscheidungen sind mithin mehrschichtig. Aus dieser Struktur folgt zweierlei. Erstens ist der Ausdruck „vom Diskurs ausgeschlossen“ technisch unscharf, solange man nicht sagt, ob es um User-Blocks, Dienst-Labels,27 serverseitige Suspensions28 oder AppView-Indexierung29 geht. Zweitens zeigt die Spezifikation gerade keine einzige, monolithische Zentralinstanz, in der Personidentität, staatliche Verifikation und Bannpersistenz schon logisch zusammenfallen.
Schliesslich ist Account-Migration eine Kernfunktion des Protokolls. Die Accounts-Spezifikation beschreibt PDS-Migration ausdrücklich als Designziel. Sie beschreibt zudem Zustände wie suspended, deactivated, throttled und andere als host- oder dienstspezifische Status. Schon der Wortlaut macht klar, dass hier keine Endgültigkeit, sondern Dienstzustände verhandelt werden.
Der öffentliche Fork-Code trägt die harte These nicht
Die zweite Ebene ist der sichtbare W-Social-Code. Auch hier ist die Sache klar. Der Code Audit der Repositories beschreibt w-social-atproto,30 pds31 und ozone32 als eng an Bluesky orientierte Forks, ohne im sichtbaren Material eine personengebundene Exklusionslogik zu finden. Der Bericht nennt ausdrücklich, dass die Signup-Flows im öffentlichen PDS-Material bei E-Mail, Handle und Invite-Code bleiben, dass es keine Referenzen auf Pass, ID-Karte, eID oder Drittanbieter-Identitätsdienste im Code oder in den Konfigurationen gibt und dass Blocks weiterhin auf DID-/Handle-Ebene verbleiben.
Besonders lehrreich ist der Negativbefund. Nicht gefunden wurden KYC/eID-Integrationen, keine person_id-Felder, keine UUID-Blacklist-Schemata, keine Cross-Account-Linkage, keine Hashing- oder Encryption-Routinen für staatliche Identitätsdaten und keine administrativen Oberflächen, die lifetime bans gegen reale Personen aussprechen würden. Das ist mehr als nur Schweigen. Es ist ein ziemlich massiver Hinweis darauf, dass die stärksten Varianten der These im veröffentlichten Material nicht verankert sind.
Freilich beweist fehlender offener Code weder Harmlosigkeit noch Unschuld. Wer daraus eine Entwarnung bastelt, begeht denselben intellektuellen Fehler wie zuvor die überzogene Gegenseite, nur spiegelverkehrt. Doch genau deshalb ist die Formulierung wichtig: Der öffentliche Fork-Code gibt die harte Ausgangsthese derzeit nicht wieder. Mehr nicht. Weniger aber auch nicht.
Das grosse Aber
Die eigentliche Gefahr beginnt an der Schnittstelle zwischen sichtbarem Open-Source-Sockel und unsichtbarer Betreiberlogik. Die Privacy Notice von W Social ist in dieser Hinsicht der eigentliche Schlüsseltext. Sie erklärt, dass jedes Konto mit einer verifizierten menschlichen Identität verbunden sein müsse, dass die Identitätsprüfung durch W Identity als separaten Controller erfolgt und dass W Social beim Signup mit ausdrücklicher Zustimmung des Nutzers die W-Identity-UUID, das Passland und das Geburtsjahr übernimmt. Das sind keine irrelevanten Metadaten. Das ist ein Identitätsanker.33
Ebenfalls aus derselben Privacy Notice ergibt sich, dass W Social Social-Graph-Daten34 einschliesslich Follow-Beziehungen, Mute-Listen, Blocklisten und weitere Interaktionsdaten verarbeitet. Hinzu kommt die Moderation „illegal or harmful content„. Dazu treten technische und Session-Daten, Such- und Discovery-Daten, Gerätekennungen und Login-Aktivität. Eine Plattform, die verifizierende UUID, soziale Graphdaten, Moderationslogik und AppView-Funktionalität in derselben Betriebswirklichkeit zusammenführt, verfügt über einen erheblichen Hebel.
Hier liegt die eigentliche intellektuelle Schwierigkeit. Aus der Existenz dieses Hebels folgt noch keine konkrete Implementierung. Die Privacy Notice sagt nicht, dass UUIDs für Cross-Account-Bans verwendet werden. Sie sagt nicht, dass Block- oder Moderationsstatus an diese UUID gebunden werden. Sie sagt nicht, dass eine gebannte Person keine neue Registrierung erhalten kann. Sie sagt auch nicht, dass dieselbe Identität nur ein einziges Konto besitzen darf. Der Unterschied zwischen „each account be associated with a verified human identity“ und „one human, one account“ ist nicht sprachliche Feinarbeit, sondern materiell. Die erste Aussage ist dokumentiert. Die zweite ist es nicht.
Und dennoch bleibt das grosse Aber. Denn wenige zusätzliche Komponenten würden genügen, um die vermutete Exklusionslogik praktisch zu realisieren. Ein proprietäres Onboarding-Gateway, das UUID und DID zusammenführt. Eine interne Mapping-Tabelle. Eine Blacklist für Re-Registrierung. Ein Ozone-Webhook oder eine Moderationsbus-Logik, die bei bestimmten Schweregraden nicht bloss die DID markiert, sondern die zugrunde liegende UUID. Ein AppView, das unverified oder intern gesperrte DIDs nicht mehr indexiert. Nichts davon verlangt riesige konzeptionelle Sprünge. Nichts davon ist technisch exotisch. Fast alles davon würde ausserhalb der sichtbaren Open-Source-Repositories liegen. Genau deshalb ist nicht belegt nicht dasselbe wie unmöglich.
Warum Gemini zugleich nützlich und gefährlich ist
Der Gemini-Bericht ist in dieser Debatte nicht deshalb interessant, weil er fundamental recht oder fundamental unrecht hätte. Interessant ist er, weil er denselben Befund wie die strengeren Analysen nimmt und ihn dann zu einer wesentlich schärferen Architekturthese hochzieht. Am Anfang tut Gemini alles Richtige. Es widerspricht der Behauptung, das AT-Protokoll selbst sei für lebenslange ID-Kopplung von Blocklisten gebaut. Es sagt, die öffentlichen Forks belegten die harte Korrelation nicht. Es identifiziert die Betreiber-Overlay-Schicht als Risikobereich. Bis dorthin ist der Text im Wesentlichen kongruent mit den anderen Analysen.
Dann beginnt der problematische Teil. Gemini spricht davon, die von W Social übernommene UUID stelle eine „unbroken, mathematically absolute proxy connection“ zwischen DID und verifizierter Person dar. Es liest die Retention-Regelung über „restriction of processing“ so, dass damit „the exact pathway required“ für permanente UUID-gebundene Blacklisting-Logik geschaffen sei. Es formuliert, das UUID-Ingestion-Gateway liefere „all necessary technical infrastructure to enforce lifelong social exclusion„. Diese Sätze sind nicht völlig aus der Luft gegriffen. Sie sind aber weit stärker als der Primärbefund selbst. Sie verwandeln technische Möglichkeit und institutionellen Hebel in eine fast schon halbfertige Systemwirklichkeit.
Dazu kommt ein zweites Problem. Der Gemini-Bericht arbeitet nicht durchgehend mit derselben Quellendisziplin, die er an entscheidenden Stellen eigentlich bräuchte. Im Referenzteil tauchen neben offiziellen Quellen auch Scribd, Reddit, Wikipedia, ResearchGate, ein ATmosphereConf-Bookmark und ähnlich weiches Material auf. Wer eine so scharfe These über die technisch-juristische Fundierung lebenslanger personengebundener Exklusion aufstellt, sollte seine Schlusslast nicht auf diese Mischlage verteilen. Gerade weil der Bericht selbst weiss, dass der operative Backend-Raum nicht öffentlich ist, hätte er strikter mit seinen eigenen Hypothesensätzen umgehen müssen.
Der Punkt ist nicht, dass Gemini nutzlos wäre. Der Punkt ist, dass Gemini den Sprung von reales Risiko zu nahezu angelegte Exklusionsarchitektur deutlich leichter vollzieht als die anderen Berichte.
Die politische Gefahr beginnt dort, wo Instrumente institutionalisiert werden
Der Fall W Social ist damit kein blosses Nerd-Gefecht über DIDs, AppViews und Fork-Diffs. Er ist ein Musterfall für die Frage, wie offene Protokolle politisch umcodiert werden können, sobald proprietäre Zugangsschichten, Moderationshebel und regulatorische Legitimation ineinandergreifen. Ein offenes Protokoll schützt Freiheit nicht automatisch. Es schafft Möglichkeiten. Welche davon politisch wirksam werden, entscheidet oft nicht der transport layer, sondern die institutionelle Hülle.
Gerade an diesem Punkt schliesst der Fall an Teil 7,35 Teil 836 und Teil 937 meiner Verfassungsserie an. Im harten Kern der Freiheit ging es um Informationsasymmetrie, Transparenz, digitale Unverletzlichkeit und die Begrenzung jener Werkzeuge, mit denen Staat und staatsnahe Machtapparate Bürger in Datenobjekte verwandeln. Dort lautete der Satz, der Staat schulde dem Bürger Transparenz, während der Bürger dem Staat keine über das Unerlässliche hinausgehende Preisgabe seiner personenbezogenen Daten schuldet. Die Logik dahinter ist dieselbe: Wo Macht Register, Zugangsbedingungen, Metadaten und Auswertungskapazitäten bündelt, kippt Freiheit nicht zuerst spektakulär, sondern strukturell.
W Social ist kein Staat. Das ist richtig. Moderne Freiheitsverluste werden jedoch längst nicht mehr nur durch klassische Staatsakte hergestellt. Sie werden ausgelagert, vertraglich verpackt, protokollarisch abstrahiert, privatwirtschaftlich operationalisiert und anschliessend politisch genutzt. Genau darum ging es in meiner Serie zur verfassungsrechtlichen Entgrenzung: Werkzeuge entstehen selten mit der offenen Ansage, gegen Bürger gerichtet zu werden. Sie entstehen als Antwort auf Sicherheit, Effizienz, Integrität, Vertrauensräume oder technische Modernisierung. Missbrauch kommt später. Er kommt regelmässig. Er kommt institutionell, nicht dämonologisch.
Die politische Essenz des W-Social-Falls liegt deshalb nicht in der Behauptung, die schlimmste denkbare Version sei bereits bewiesen. Sie liegt im Gegenteil darin, dass bereits eine moderate, rechtlich hübsch formulierte, identitätsgestützte Zugangsschicht eine Infrastruktur schafft, die später leicht in Richtung Kontrolle, Re-Registration-Sperre, Sichtbarkeitsselektion und diskursive Ausschlusspraktiken verschoben werden kann. Wer sich an dieser Stelle auf die beruhigende Formel zurückzieht, im offenen Fork stehe ja nichts Entsprechendes, verwechselt Transparenzlücke mit Entwarnung.
Die Geschichte staatlicher und para-staatlicher Instrumentennutzung spricht ohnehin gegen solche Naivität. Einmal eingerichtete Zugriffswerkzeuge werden nicht aus Pietät vor möglichen Freiheitsverletzungen liegen gelassen. Sie werden genutzt, ausgeweitet, an neue Kontexte angepasst und normativ nachbegründet. Mal heisst es Integrität, mal Sicherheit, mal Plattformgesundheit, mal demokratische Resilienz. Das Muster bleibt. Eben deshalb genügt der Hinweis auf gegenwärtig gute Absichten nicht. Der Massstab einer freiheitlichen Ordnung ist nicht, ob ein Instrument im Gründungsprospekt wohlmeinend klingt. Der Massstab ist, ob es später gegen den Bürger gewendet werden kann. Beim Zusammenspiel aus Verifikations-UUID, Social Graph, Moderation, AppView-Gating und proprietärem Backend lautet die Antwort leider: ja. (sic!)
Gerechte Wertung von @tachy_
Gerade deshalb ist eine faire Wertung von @tachy_ nötig. Die erste Warnung war technisch zu hart. Sie legte dem offenen AT-Protokoll eine Architektur zur Last, die das Protokoll nach heutigem Primärmaterial gerade nicht trägt. Sie formulierte von Beginn an stärker, als der öffentliche Fork-Code und die zugänglichen Dokumente hergaben. Das bleibt festzuhalten. Wer die Dinge sauber sagt, muss das auch dann aussprechen, wenn er dem politischen Impuls des Warnenden sympathisch gegenübersteht.
@tachy_ hat auf Nachfrage nachgeschärft. Er hat die Engführung auf den Fork-Code relativiert und die gemeinte technische Kopplung breiter auf Verifikationstool, Plattformarchitektur und Absicht bezogen. Diese Korrektur war redlich. Sie verdient Anerkennung. Noch mehr: Ohne seine Publikation des Falls wäre genau diese Untersuchung womöglich nie mit derselben Schärfe und öffentlichen Sichtbarkeit geführt worden.
Auch der spätere Hinweis, dass sich nun ein echter Profi mit dem Kram auseinandersetzen werde, ist in diesem Zusammenhang bemerkenswert.38 Er erhöht die Messlatte für alle Beteiligten. Für den Kritiker, der sauberer formulieren muss. Für den Prüfer, der sich nicht mit Halbwissen schmücken darf. Für das Publikum, das lernen muss, zwischen Protokoll, Code, Policy und unsichtbarem Backend zu unterscheiden. Die Sache wird dadurch ernster. So sollte Streit in technischen und politischen Fragen aussehen.
Schlussbemerkung
Was bleibt also? Nicht die Behauptung, das AT-Protokoll sei eine protokollnative Bannmaschine für personengebundene lebenslange Exklusion. Das ist nach Spezifikation falsch. Nicht der Nachweis, der öffentliche W-Social-Fork-Code enthalte bereits die ganze gefürchtete Logik. Auch das ist derzeit nicht belegt. Was bleibt, ist etwas unangenehmeres als Alarmismus und gefährlicher als Entwarnung: eine identitätsgestützte Zugangsschicht mit UUID-Anker, Social-Graph-Verarbeitung, Moderationskompetenz und einer proprietären Backend-Zone, über die die Öffentlichkeit gerade das Entscheidende nicht weiss.
Das bedeutet, der 𝕏-Post war in seiner stärksten Form zu hart, aber in seinem Misstrauenskern nicht gegenstandslos. W Social ist kein Beweis für bereits vollzogene digitale Ächtung. W Social ist ein sauberer Anlass, die strukturelle Gefahr solcher Instrumente präziser zu benennen. Nicht die offene Spezifikation ist das Problem. Nicht der sichtbare Fork allein. Das Problem ist die politische und institutionelle Macht, die aus einem sichtbaren, scheinbar harmlosen Sockel und wenigen unsichtbaren Komponenten ein System praktischer Exklusion bauen kann.
In eigener Sache
Analysen dieser Art entstehen nicht aus Luft, nicht aus institutionell finanzierter Gelassenheit und auch nicht aus jener akademischen Gemütlichkeit, in der man nach Belieben zwischen Modellzugang, Rechenzeit und Infrastruktur wechseln kann, ohne jemals die Rechnung zu sehen. Sie kosten reales Geld. Sie kosten Zeit. Sie kosten Konzentration. Sie kosten Server. Sie kosten Modellzugänge. Sie kosten die gesamte technische Umgebung, in der diese Arbeit überhaupt möglich bleibt.
Meine gesamte Infrastruktur läuft unter ausschliesslich meiner Hoheit und nach meinen eigenen CISS-Standards. Das betrifft Nameserver, DNS-Resolver, Gitea, GitLab, Blog, E-Mail, Videokonferenz und weitere Dienste. Diese Souveränität ist kein Hobby. Sie ist Bedingung meiner Unabhängigkeit. Gleichzeitig werde ich von Unternehmen ebenso wie von alternativen Medien gemieden, obwohl diese Arbeit erkennbar nicht dem Lager, sondern dem besseren Argument verpflichtet ist. Persönlich halte ich dieses Verhalten für unerträglich.
Hinzu kommt mein eigener Rechtsstreit, der seit drei Jahren stillsteht. Auch dieser Fall bindet Ressourcen, Zeit und Geld, die längst erschöpft sind, weil Untätigkeit, Verschleppung und institutionelle Gleichgültigkeit sich zuverlässig zu Lasten des Einzelnen organisieren. Wer möchte, dass solche Analysen weiter entstehen, sollte sich keiner Illusion hingeben: Ohne Unterstützung werde ich diese Arbeit nicht weiter fortsetzen können, denn es ist bereits viertel nach zwölf für meine persönliche Situation.
Unterstützungsmöglichkeiten
https://www.gofundme.com/f/rechtsverteidigung-existenzsicherung-arbeitsgericht-lisbon
Oder direkt hier:
Mille fois an alle Spender.
Quellen
- https://x.com/tachy_ ↩︎
- https://x.com/tachy_/status/2051953194486444173?s=20 ↩︎
- https://x.com/tachy_/status/2052345582002331921?s=20 ↩︎
- Danisch, Hadmut: „Was hinter der Bluesky-Aktion stecken könnte“, Danisch.de, 7. Mai 2026, https://www.danisch.de/blog/2026/05/07/was-hinter-der-bluesky-aktion-stecken-koennte/. ↩︎
- https://x.com/Hadmut ↩︎
- DID: Decentralized Identifier; im AT-Protokoll der persistente primäre Konto-Identifier, während Handles nur menschenlesbare, änderbare Namen sind. ↩︎
- Labeler: Moderationsdienst im Bluesky-/ATProto-Ökosystem; Labeler publizieren signierte Labels zu Accounts oder Inhalten und erklären ihre Policies über app.bsky.labeler.service, https://docs.bsky.app/docs/advanced-guides/moderation ↩︎
- KYC: Know Your Customer; Begriff aus dem Finanz- und Compliance-Bereich für Identitäts- und Hintergrundprüfungen bei der Kundenaufnahme, einschliesslich technisch gestützter Checks und biometrischer Verfahren. https://de.wikipedia.org/wiki/Know_your_customer ↩︎
- AT Protocol, „DID“, Spezifikation, Abschnitt „AT Protocol DIDs“, zu persistenten dezentralen Identifikatoren als Account-Identifiern, https://atproto.com/specs/did. ↩︎
- Bluesky, „Blocking users“, Dokumentation, insbesondere die Parameter repo und subject sowie der Hinweis, dass Unblocking durch Löschen des Records erfolgt, https://docs.bsky.app/docs/tutorials/blocking. ↩︎
- Bluesky, „Why are blocks on Bluesky public?“, 8. Juni 2023, zu öffentlichen und enumerierbaren Block-Records, ihrer Speicherung in Account-Repositories und ihrer Durchsetzung durch PDS, AppViews und Clients, https://docs.bsky.app/blog/block-implementation. ↩︎
- Bluesky, „Labels and moderation“, Dokumentation zu Labelern, Moderationspräferenzen, Labeler-Subscriptions und takedown-fähiger Moderationsarchitektur, https://docs.bsky.app/docs/advanced-guides/moderation. ↩︎
- AT Protocol, „Accounts“, Spezifikation, Abschnitt „PDS Account Migration“ sowie Hosting-Status wie suspended, deactivated und Migrationspfade, https://atproto.com/specs/account. ↩︎
- W-Identity UUID: Von W Identity an W Social übermittelte eindeutige Kennung bei der Kontoerstellung; laut Privacy Notice erhält W Social die UUID, das Passland und das Geburtsjahr, nicht aber weitere Identitätsdaten ohne ausdrückliche Freigabe, https://wsocial.eu/public/privacy-notice. ↩︎
- W Social AB, „Privacy Notice“, offizielle Datenschutzerklärung, abrufbar unter https://wsocial.eu/public/privacy-notice. ↩︎
- Siehe Deep Research Prompt Codeanalysis – ChatGPT 5.5 Pro Codeanalysis Report. ↩︎
- eID: Elektronische Identität zur sicheren digitalen Authentisierung; die Europäische Kommission beschreibt die europäische digitale Identität als Wallet, mit der Nutzer sich online und offline ausweisen, Dokumente speichern und Signaturen erzeugen können, https://commission.europa.eu/topics/digital-economy-and-society/european-digital-identity_de. ↩︎
- Siehe Deep Research Prompt – ChatGPT 5.5 Pro Deep Research Report. ↩︎
- User-Blocks: Nutzerseitige Blocks, die Interaktion verhindern und den geblockten Account in der Client-Erfahrung ausblenden; laut Bluesky sind Blocks öffentlich und werden als Record angelegt und durch Löschen wieder entfernt, https://docs.bsky.app/docs/tutorials/blocking. ↩︎
- Siehe Deep Research Prompt – Grok 4.3 Expert Deep Research Report. ↩︎
- Siehe Deep Research Prompt – Gemini 3.1 Pro Deep Research Report. ↩︎
- Retention-Klauseln: Regeln zur Aufbewahrung und Löschung personenbezogener Daten; bei W Social wird erklärt, dass Daten nach Zweckerreichung gelöscht oder anonymisiert werden sollen, ausser längere Aufbewahrung oder eine Einschränkung der Verarbeitung rechtlich erlaubt oder erforderlich ist, https://wsocial.eu/public/privacy-notice. ↩︎
- PDS-Hosting: Personal Data Server Hosting; im AT-Protokoll ist der PDS der Hosting-Dienst eines Accounts, der Repositories, Authentisierung und weitere Netzwerkdienste bereitstellt, https://atproto.com/specs/account. ↩︎
- https://atproto.com/specs/did ↩︎
- repo und subject: Parameter eines Block-Records im Bluesky-API-Modell; repo ist die DID des blockierenden authentisierten Nutzers, subject die DID des zu blockierenden Nutzers, https://docs.bsky.app/docs/tutorials/blocking. ↩︎
- https://docs.bsky.app/docs/tutorials/blocking ↩︎
- Dienst-Labels: Labels, die nicht vom einzelnen Nutzer, sondern von Moderationsdiensten publiziert werden; sie werden von Labelern signiert und von Clients oder App Views für Filter- und Warnlogik ausgewertet, https://docs.bsky.app/docs/advanced-guides/moderation. ↩︎
- serverseitige Suspensions: Kontozustände oder Sperren, die ein Host- oder Netzwerdienst für ein Konto verhängt; die AT-Protokoll-Spezifikation nennt etwa
suspended,deactivatedund andere Hosting-Status als dienstseitige Zustände, https://atproto.com/specs/account. ↩︎ - AppView-Indexierung: App Views aggregieren Netzwerkdaten, liefern Metriken, Suche und Discovery und entscheiden selbständig, welchen Ausschnitt von Accounts und Inhalten sie hosten oder redistribuieren; damit ist Indexierung eine eigenständige Dienst- und Policy-Frage, https://atproto.com/guides/overview , https://atproto.com/specs/account. ↩︎
- w-social-atproto: Öffentliches Kern-Repository von W Social auf GitHub; laut hochgeladenem Audit ein Fork von bluesky-social/atproto und Träger der ATProto-nahen Kernlogik, https://github.com/w-social-eu/w-social-atproto. ↩︎
- pds: Öffentliches W-Social-Repository für den Personal Data Server; laut Audit ein Fork von bluesky-social/pds, also der Hosting- und Betriebsumgebung für Accounts, https://github.com/w-social-eu/pds. ↩︎
- ozone: Öffentliches Moderations- und Labeling-Repository von W Social; laut Audit ein Fork von bluesky-social/ozone und für Labeling- bzw. Moderationsoberflächen relevant, https://github.com/w-social-eu/ozone. ↩︎
- W Social AB, „Privacy Notice“, offizielle Datenschutzerklärung, abrufbar unter https://wsocial.eu/public/privacy-notice. ↩︎
- Social-Graph-Daten: Beziehungsdaten eines Kontos, also etwa Follower- und Followed-Beziehungen, Mute-Listen, Blocklisten, Listenmitgliedschaften oder Starter-Pack-Zuordnungen; W Social nennt diese Kategorie ausdrücklich in seiner Privacy Notice, https://wsocial.eu/public/privacy-notice. ↩︎
- Marc Weidner, „Die Verfassung. Der harte Kern der Freiheit“, auf: coresecret.eu, 4. Mai 2026, abrufbar unter https://coresecret.eu/2026/05/04/die-verfassung-der-harte-kern-der-freiheit/, abgerufen am 7. Mai 2026. ↩︎
- Marc Weidner, „Die Verfassung. Freiheit in engerer Fassung“, auf: coresecret.eu, 5. Mai 2026, abrufbar unter https://coresecret.eu/2026/05/05/die-verfassung-freiheit-in-engerer-fassung/, abgerufen am 7. Mai 2026. ↩︎
- Marc Weidner, „Die Verfassung. Am Rand des Verfassungsminimums“, auf: coresecret.eu, 5. Mai 2026, abrufbar unter https://coresecret.eu/2026/05/05/die-verfassung-am-rand-des-verfassungsminimums/, abgerufen am 7. Mai 2026. ↩︎
- https://x.com/tachy_/status/2052409030153212020?s=20 ↩︎
Deep Research Prompt Codeanalysis
TASK
Act as a strict code-audit agent. Perform a repository-first technical analysis of the public W Social code base and any directly linked public technical artifacts.
Your job is not to produce a broad policy essay. Your job is to determine, from public code and closely adjacent primary technical materials, whether the claims made by the X user @tachy_ are supported, contradicted, plausibly risky, or not decidable because the relevant implementation is not public.
Core claim to test:
“The Bluesky-based AT Protocol is designed so that blocklists will technically be linked in the background for life to a user’s personal ID verification.
Anyone who posts something critical once will be excluded from discourse for life through blocklists/blocks.”
PRIMARY OBJECTIVE
Audit the public code base and its architecture as rigorously as possible.
Focus on:
- public repositories
- fork provenance
- upstream/downstream diffs
- commit history
- branches and tags
- configuration files
- environment variables
- deployment files
- API definitions
- schemas and migrations
- moderation code paths
- identity and onboarding code paths
- any references to external/private services
- protocol lexicons and official implementation docs directly tied to the code
Do not substitute social commentary, ideology, branding, or vague product language for code evidence.
WORKING MODE
You are a code-analysis agent, not a political commentator.
For every conclusion, distinguish clearly between:
A. Direct code evidence
What is explicitly visible in code, config, schema, migrations, or official implementation docs?
B. Technical inference
What follows with strong engineering plausibility from that evidence?
C. Overreach boundary
What would go beyond what the code actually shows?
D. Missing-component analysis
What functionality would require code or services that are not public?
MANDATORY DISCIPLINE
1. Treat absence of evidence correctly.
- Missing public code is not proof of innocence.
- Missing public code is not proof of guilt.
- If a claim depends on unavailable backend logic, say so explicitly.
2. Separate layers strictly.
- protocol layer
- client/UI layer
- server/PDS layer
- moderation/labeler layer
- identity/onboarding layer
- operator-side private backend layer
3. Never treat a fork as proof of a custom feature.
A fork only proves derivation, not implementation of the claimed behavior.
4. Never treat a website promise as proof of code.
If the behavior is claimed in prose but not visible in code, mark that distinction explicitly.
5. Never collapse “possible” into “implemented”.
Use the exact wording:
- “directly evidenced in public code”
- “not evidenced in public code”
- “technically possible but not evidenced”
- “not decidable from the public code base”
REPOSITORY AUDIT SCOPE
Step 1: Inventory
- Identify all public W Social repositories.
- Determine which are forks and from which upstream repositories.
- Record default branches, tags, releases, stars, issues, PRs, and recent activity.
- Identify whether repositories are mirrors, thin forks, or materially modified forks.
Step 2: Upstream comparison
For each repo:
- compare against upstream Bluesky / ATProto repositories
- identify added, removed, or modified files
- identify custom commits not present upstream
- identify whether modifications concern identity, moderation, persistence, onboarding, federation, or discovery
Step 3: Search targets
Perform targeted analysis for any code or config related to:
- eID
- KYC
- identity verification
- national ID
- passport
- UUID
- person identifier
- verified human
- one human one account
- signup gating
- onboarding checks
- moderation persistence
- block persistence
- cross-account bans
- blacklist / blocklist / denylist
- re-identification
- retention
- appeal
- ban duration
- labeler
- takedown
- discovery suppression
- visibility filtering
- account linking
- fingerprinting
- biometrics
- device binding
- anti-evasion logic
Use semantic and literal search.
Inspect code, comments, docs, configs, migration files, schema definitions, tests, and CI files.
Step 4: Architecture reconstruction
Infer the likely public architecture:
- which components appear to be standard Bluesky / ATProto
- which components appear to be W-Social-specific
- which critical services appear to be missing from the public repos
- whether the claimed “ID-linked lifelong blocks” would require an additional non-public service
- what that missing service would likely do
- what traces of such a service are or are not visible in the public code
Step 5: Protocol anchoring
Cross-check the code findings against official ATProto / Bluesky implementation references only where needed to interpret the code correctly:
- how blocks are modeled
- how list blocks / moderation lists work
- how DIDs, handles, and account identity work
- whether protocol-native blocking is account/DID-bound rather than person-bound
- whether the protocol contains any native identity-document verification layer
CLAIM ATOMIZATION
Do not evaluate the overall warning as a single blob.
Break it into atomic technical claims and test each one separately:
1. Public block / blocklist functionality exists.
2. This functionality is standard ATProto / Bluesky behavior.
3. W Social has added custom identity-verification code.
4. W Social has added document-based identity verification.
5. W Social has added a stable person-level identifier.
6. W Social links moderation or blocking to that person-level identifier.
7. W Social persists such linkage across multiple accounts.
8. W Social makes that linkage indefinite or lifelong.
9. W Social enforces operator-wide exclusion across all accounts of the same person.
10. This exclusion is visible in public code rather than merely conceivable.
For each claim, assign exactly one classification:
1. Clearly supported by public code or primary implementation documents
2. Clearly contradicted by public code or primary implementation documents
3. Partially supported, but overstated or falsely generalized
4. Technically plausible, but not evidenced in the public code base
5. Not decidable because the relevant implementation is not public
SEARCH AND ANALYSIS RULES
When you inspect code, prioritize:
- schema and migration files
- API surface definitions
- account creation paths
- moderation service interfaces
- labeler integrations
- persistence layers
- env vars indicating external identity providers
- secrets/config placeholders indicating proprietary backends
- references to UUIDs or external identity payloads
- tests that reveal expected hidden behavior
- mobile/web app network endpoints if present in source
- deployment manifests that reveal service topology
Be explicit when something is only hinted at indirectly, for example:
- endpoint names without implementation
- env vars without referenced code
- comments referring to private services
- TODO markers for identity or moderation features
- CI workflows referencing unavailable private modules
DELIVERABLE FORMAT
Part 1: Executive Code Verdict
A concise technical summary.
Answer only what the public code can actually sustain.
Part 2: Repository Inventory
For each public repo:
- name
- fork origin
- apparent purpose
- level of divergence from upstream
- relevance to the claims
Part 3: Diff Audit
For each relevant repo:
- key custom commits or files
- identity-related modifications
- moderation-related modifications
- persistence-related modifications
- what was not found
Part 4: Evidence Matrix
Table columns:
- Atomic claim
- Code artifact(s)
- Finding
- Classification
- Reasoning
- Residual uncertainty
Part 5: Missing Components Analysis
Describe:
- which claimed behaviors would require non-public services
- whether the public repos expose any hooks or traces of such services
- what cannot be determined from the public code
Part 6: Final Technical Judgment
State plainly:
- what is directly evidenced
- what is contradicted
- what is technically plausible but not evidenced
- what is not decidable from the public code base
STYLE REQUIREMENTS
Write in precise, sober English.
No activist rhetoric.
No policy sermon.
No moral grandstanding.
No hand-waving.
No “this proves” unless the code really proves it.
No “there is no evidence” unless you actually searched the relevant code paths.
Use exact phrasing where appropriate:
- “This is directly evidenced in public code.”
- “This is not evidenced in public code.”
- “This is standard upstream behavior, not a W-Social-specific finding.”
- “This would require additional non-public backend logic.”
- “This is technically plausible, but not demonstrated in the public repositories.”
- “This is not decidable from the current public code base.”
FINAL ADDITIONAL TASK
End with a short list of the most important additional technical artifacts that would be required for a decisive conclusion, such as:
- private backend repositories
- moderation service code
- identity/onboarding service code
- API contracts between W Identity and W Social
- database schema for bans/moderation/account linking
- mobile app binaries
- internal admin tooling
- retention and appeal logicDeep Research Prompt Codeanalysis – ChatGPT 5.5 Pro Codeanalysis Report
2026.05.07_Deep_Research_ChatGPT_Agent_W_AT_Protokoll_signedDeep Research Prompt
TASK
Conduct a rigorous deep research investigation into whether the claims made by the X user @tachy_ about “W Social” are technically and documentarily supported, contradicted, indicative of genuine risks, or currently not decidable because the relevant implementation code or operational backend logic has not been published.
Core claim to assess:
“The Bluesky-based AT Protocol is designed so that blocklists will technically be linked in the background for life to a user’s personal ID verification.
Anyone who posts something critical once will be excluded from discourse for life through blocklists/blocks.”
Additional context:
There is already a preliminary analysis suggesting that the currently public W-Social repositories appear to be forks of Bluesky components, that blocklists are indeed part of standard ATProto / Bluesky functionality, but that there is no publicly visible implementation in the code of “one human, one account,” eID coupling, identity-document hashing, or lifelong person-bound block persistence. Do not treat that preliminary analysis as authoritative. Re-test it critically from scratch.
PRIMARY GOAL
Do not produce a vague overall opinion. Break the overall claim into individual testable technical propositions, and assign each proposition exactly one of the following classifications:
1. Clearly supported by public code or primary documents
2. Clearly contradicted by primary sources
3. Partially supported, but overstated or falsely generalized
4. A plausible real risk, but not currently evidenced
5. Not decidable at present because the relevant implementation details are not public
PRIMARY FOCUS
This research must be driven primarily by the public code base and closely related primary technical artifacts.
Prioritize:
- public source code
- repository structure
- upstream/downstream diffs
- commit history
- configuration files
- database schemas and migrations
- API definitions
- environment variables
- deployment files
- moderation and identity-related code paths
- official protocol specifications
- official documentation tied directly to implementation
Do not substitute political inference, AI paraphrase, or marketing language for code evidence.
ANALYTICAL FRAMEWORK
For every sub-question, separate the following layers clearly:
A. Observation
What is directly visible in the public code base or in primary documents?
B. Technical model
What follows from that evidence with strong technical plausibility?
C. Interpretation
Which conclusions are justified, and which would be overreach?
D. Normative or risk assessment
What real privacy, freedom, moderation, or discourse risks actually arise from the proven or plausible architecture?
Always distinguish between:
- standard ATProto / Bluesky behavior
- W-Social-specific modifications
- public code
- non-public backend or operational logic
- protocol-level properties
- application-level behavior
- operator policy statements
- technically demonstrable facts versus speculation
SCOPE OF INVESTIGATION
1. Exact status of W Social
Investigate:
- official website
- legal notice / company information
- FAQ
- privacy policy
- terms of service
- press releases
- launch announcements
- public interviews or official statements
- app store descriptions
- linked GitHub organization and repositories
- any technical documentation outside GitHub
2. Public GitHub material of W Social
Examine comprehensively:
- which repositories are public
- whether they are forks, and of what exactly
- branches, commit history, README files, issues, pull requests, releases
- concrete deviations from upstream Bluesky repositories
- code diffs, config files, environment variables, database schemas, migrations, Docker / Compose files
- any references to separate identity, KYC, eID, moderation, policy, or block-persistence services
- any hints of private or unpublished repositories
- any signs that critical logic is outsourced into proprietary services not present in the public code
3. AT Protocol / Bluesky reference design
Using primary protocol specifications and official documentation, determine:
- how blocks are technically modeled in ATProto
- how blocklists, moderation, and labelers work
- whether blocks are bound to accounts, DIDs, handles, PDS instances, appviews, or other identifiers
- whether identity verification is part of the protocol or only an application/operator-side add-on
- whether the protocol supports or prescribes “one human, one account”
- whether multiple accounts remain technically possible
- how account migration, DID changes, handle changes, and PDS migration interact with moderation and blocking
- whether a lifelong linkage to a real person is aligned with the open protocol, contrary to it, or merely possible as a private overlay
4. The specific “ID verification” claim
Check whether there is any primary evidence for:
- eID / national ID / personal document verification / KYC
- “one human, one account”
- hashing or persistent storage of government identity data
- linkage between real-world identity and block or moderation status
- operator-side recognition of the same person across multiple accounts
- exclusion mechanisms spanning multiple accounts belonging to the same verified individual
- centralized blacklists for identity-verified persons
5. The specific “for life” claim
Check whether there is any primary evidence for:
- indefinite retention or ban duration
- irreversible identity binding
- durable re-identification
- person-bound rather than account-bound moderation
- absence of reset, appeal, expiration, or deletion mechanisms
6. The claim “excluded from discourse”
Assess technically and organizationally:
- what “excluded from discourse” would mean in this architecture
- whether this refers to local user blocks, server-side moderation, global labelers, feed suppression, discovery suppression, or hard account-level bans
- whether a blocked person could still remain visible via other PDS instances, other clients, or other accounts
- whether the claimed lifelong exclusion follows from the protocol itself or only from centralized overlay services
CORE QUESTIONS THAT MUST BE ANSWERED EXPLICITLY
1. Does the public W-Social code itself prove that blocks are linked for life to personal ID verification?
2. If not, are there credible official statements, contractual texts, or technical documents outside the code that strongly suggest such a linkage?
3. Which parts of the X user’s claim merely describe standard ATProto / Bluesky behavior and are not W-Social-specific?
4. Which genuine dangers would remain technically possible even if the public code is silent?
5. What can currently be stated with high confidence, and where does the evidence run out?
6. Is the warning fundamentally accurate, partially accurate, misleading, or currently not decidable?
METHOD
Use primary sources first:
- official ATProto and Bluesky sources
- official W-Social sources
- public GitHub code and diffs
- official legal and policy documents
- directly inspectable technical artifacts
Use secondary sources only to supplement:
- serious technical analyses by third parties
- architecture analyses of Bluesky / ATProto
- reverse-engineering reports, if any
- relevant privacy or regulatory material, if directly applicable
Do not:
- infer implementation from ideology
- infer hidden architecture from political branding
- treat a fork as proof of a custom feature
- treat a website promise as proof of implementation
- treat missing public code as proof of innocence
- equate “technically possible” with “actually implemented”
If the evidence is missing, state that plainly.
MANDATORY VALIDATION RULES
1. Atomize the original claim.
Do not answer only at the level of “the claim is true” or “false.”
Test separately:
- are blocklists present?
- are they just standard ATProto / Bluesky features?
- are they linked to identity verification?
- is that verification document-based?
- is the linkage persistent?
- is it lifelong?
- does it create network-wide or operator-wide exclusion?
2. Separate architectural layers:
- protocol layer
- client / app layer
- server / PDS layer
- moderation / labeler layer
- operator policy / onboarding layer
3. Where critical code is not public, identify concretely:
- which missing component would be required
- whether such a component would normally be public or private
- whether the alleged functionality is even implementable without that missing component
- what traces such an implementation would usually leave in the public artifacts
4. Test counter-hypotheses as seriously as the original claim:
- multiple accounts may remain possible in the open protocol
- blocks may be account-bound or DID-bound rather than person-bound
- eID linkage might exist only as a local onboarding gate without protocol-wide lifelong effects
- “excluded from discourse” may be socially or platform-politically framed rather than technically enforced
5. But also test realistic worst-case scenarios:
- centralized operator identity database
- KYC / eID requirement before account activation
- operator-side bans across all accounts belonging to one verified person
- server-side identity hash or token linkage
- global moderation lists for verified persons
- discovery or visibility suppression outside the open protocol model
SOURCE PRIORITY
Code over commentary.
Protocol specification over blog summary.
Actual diffs over AI summaries.
Contractual language over promotional wording.
Primary technical artifacts over political interpretation.
If something is known only from screenshots, vague announcements, or non-technical promotional material, mark that explicitly.
OUTPUT FORMAT
Part 1: Executive Summary
A concise but dense summary in clear prose.
Do not exceed 12 compact sections.
Part 2: Claim Matrix
Create a table with these columns:
- Sub-claim
- Primary source(s)
- Technical finding
- Classification
- Reasoning
- Residual uncertainty
Part 3: Repository and Architecture Audit
State precisely:
- which repositories exist
- which are forks
- which relevant diffs were found
- which claims cannot be inferred from the current code base
Part 4: Protocol Analysis
Explain precisely:
- how ATProto / Bluesky handles blocks, moderation, labelers, identity, and portability
- whether the protocol itself supports or implies lifelong person-bound linkage
Part 5: W-Social-Specific Risk Assessment
Show clearly:
- what is actually evidenced
- what is merely technically possible
- what would require non-public operator-side logic
- what the real danger scenarios are, if any
Part 6: Final Judgment
Answer in direct prose:
- What is supported?
- What is contradicted?
- What is a plausible risk?
- What is currently not decidable because the relevant code or operational logic is not public?
STYLE REQUIREMENTS
Write in precise, sober English.
No activist rhetoric.
No moral grandstanding.
No hand-waving.
No “could be” without a technical reason.
No “this proves” unless the code or primary document really proves it.
When evidence is missing, write plainly:
“There is currently no primary evidence for this.”
When something is technically conceivable but not shown, write plainly:
“This is technically possible, but not evidenced.”
When a claim is partly true but stretched too far, write plainly:
“This element is supported, but the broader conclusion is not.”
FINAL ADDITIONAL TASK
If the evidence remains insufficient for a final determination, end by listing the 3 to 7 most important additional artifacts needed for a real final assessment, such as:
- private backend code
- moderation policy
- privacy policy with retention rules
- onboarding flow
- mobile app binaries
- API documentation
- database schema
- official identity-verification documentationDeep Research Prompt – ChatGPT 5.5 Pro Deep Research Report
2026.05.07_Deep_Research_ChatGPT_W_AT_Protokoll_signedDeep Research Prompt – Gemini 3.1 Pro Deep Research Report
2026.05.07_Deep_Research_Gemini_W_AT_Protokoll_signedDeep Research Prompt – Grok 4.3 Expert Deep Research Report
2026.05.07_Deep_Research_Grok_W_AT_Protokoll_signedChangelog
| 07.05.2026 | Initial Version |