W Social & das AT-Protokoll: Wenn europäischer Ehrgeiz am Onboarding scheitert

Es gibt Momente in der IT, in denen man als Infrastruktur-Architekt instinktiv hofft, dass ein Projekt abhebt. Man sieht den Entwurf, nickt die Kernentscheidungen ab und denkt sich: Ja. Genau das fehlt uns in Europa.

Der Gedanke, ein datenschutzorientiertes soziales Netzwerk aufzuziehen, das auf dem offenen, föderierten AT-Protokoll basiert, eigene Personal Data Server (PDS) in europäischen Rechenzentren betreibt und eine verlässliche Alternative zu den etablierten Plattformen darstellt, ist strategisch überfällig.

Genau mit diesem Versprechen trat die europäische Plattform-Initiative W Social an.

Positioniert als europäischer Gegenentwurf:

Fokus auf Datenschutz und EU-Hosting.
Verifizierte Identitäten über eine vorgeschaltete Prüfung zur Bot-Bekämpfung.
Physische Datenhaltung auf europäischen Servern.
Nutzung offener, dezentraler Netzwerkstandards.

Die Vision verdient natürlich Respekt und das zugrundeliegende Netzwerkprotokoll ist technisch durchdacht.

Doch was sich im geschlossenen Early-Access-Rollout von W Social abgespielt hat, zeigt exemplarisch, wie schnell Vertrauen leidet, wenn Marketing-Kommunikation, sensible Identitätsprüfung und ein geänderter Onboarding-Prozess nicht sauber ineinandergreifen.

Wenn Support-Tickets mit QR-Codes aus Print-Kampagnen beantwortet werden, während der offizielle Registrierungslink fehlschlägt, gerät selbst ein vielversprechendes Konzept ins Wanken.

Also DevTools auf und nachgesehen, was beim Klick auf Next tatsächlich passiert.

Hier ist die Dokumentation eines bemerkenswerten Onboarding-Ablaufs.

1. Die technologische Eleganz: Warum das AT-Protokoll begeistert

Um zu begreifen, warum der holprige Start so bedauerlich ist, lohnt ein Blick auf die Architektur des AT-Protokolls (Authenticated Transfer Protocol).

Wer aus der Linux- und Sysadmin-Welt kommt, kennt die Einschränkungen klassischer, monolithischer Plattformen.

Dort sind Identität, Daten und sozialer Graph untrennbar an die Server eines einzelnen Betreibers gebunden. Wird ein Konto gesperrt oder die Plattform eingestellt, sind Kontakte, Inhalte und digitale Reputation weg.

Auch das Fediverse rund um ActivityPub (wie Mastodon) hat Eigenheiten:

Zieht man von einer Instanz zu einer anderen um, lässt sich die Follower-Liste zwar migrieren, die bisherigen Beiträge und Medien verbleiben jedoch auf dem alten Server.

Das AT-Protokoll wählt hierfür eine dreigliedrige Schichtentrennung:

+-------------------------------------------------------------------------+
|                              AppView / UI                               |
|        (Aggregiert Feeds, Indizes, Suchdaten und Interaktionen)         |
+-------------------------------------------------------------------------+
                                    ^
                                    | Firehose (Event-Stream / WebSocket)
+-------------------------------------------------------------------------+
|                            Relay / Indexer                              |
|         (Kriecht Repositories ab, validiert kryptografische Signaturen) |
+-------------------------------------------------------------------------+
                                    ^
                                    | Synchronisation (MST-Commits)
+-------------------------------------------------------------------------+
|                   PDS (Personal Data Server / Repos)                    |
|       (Speichert Records im Merkle Search Tree, signiert Commits)       |
+-------------------------------------------------------------------------+
                                    ^
                                    | DID-Resolution (did:plc / did:web)
+-------------------------------------------------------------------------+
|                           Identity / DIDs                               |
|               (Kryptografische Wurzel der Nutzer-Identität)             |
+-------------------------------------------------------------------------+

Die Kernkomponenten im Detail

Dezentrale Identität (DID): Die Identität basiert auf einem kryptografischen Identifier (meist did:plc oder did:web). Dieser Identifier verweist auf ein DID-Dokument, das die öffentlichen Schlüssel sowie den aktuellen Service-Endpunkt des Daten-Servers enthält. Der Benutzername (z. B. @handle.domain.tld) dient als menschenlesbarer Alias und wird über DNS-TXT-Records (_atproto.handle...) oder HTTPS-Ressourcen aufgelöst.
Der Personal Data Server (PDS): Auf dem PDS liegt das Daten-Repository des Nutzers. Einzelne Einträge (Posts, Likes, Profildaten) werden in einem Merkle Search Tree (MST) strukturiert. Kryptografisch signiert werden im AT-Protokoll die jeweiligen Repository-Commits, wodurch der gesamte Zustand des Datenbaums nachweisbar und integer bleibt.
Portabilität: Das Protokoll sieht vor, dass Nutzer ihren PDS wechseln können. Dies ist kein banales Kopieren im Hintergrund, sondern ein mehrstufiger Prozess: Das gesamte Daten-Repository wird übertragen, und anschließend werden die Service-Informationen im DID-Dokument aktualisiert.
Relays & AppViews: Relays aggregieren die Commit-Streams der PDS-Instanzen über die Firehose, validieren die Signaturen und bereiten Datenströme auf. AppViews generieren daraus Suchindizes, Algorithmen und Feeds für die Benutzeroberfläche.

Ein europäisches PDS-Hosting mit klar definierten Datenschutz- und Datenhoheitskonzepten aufzubauen, ist technisch ein sinnvoller Schritt.

Soweit das Protokoll. Und dann kam die Praxis.

2. Die Schranke: Die Identitätsprüfung als Vorbedingung

Um an der geschlossenen Early-Access-Phase von W Social teilzunehmen, reichte vor einigen Monaten nicht einfach die Eingabe einer E-Mail-Adresse.

Die Betreiber verfolgen das Ziel, eine Plattform mit verifizierten Teilnehmern aufzubauen, um Bots und Spam von Beginn an einzudämmen.

Die gewählte Hürde: Eine Identitätsprüfung für Tester.

Wer sich für den Testbetrieb vormerken lassen wollte, wurde in das Portal von W Identity geleitet:

Erforderlich war die Prüfung anhand eines amtlichen Personalausweises oder Reisepasses.
Der Verifikationsprozess lief über einen Identitätsdienstleister, ähnlich wie man es von KYC-Prüfungen im Finanz- oder Krypto-Sektor kennt.
Die Vorregistrierung wurde mit dem verifizierten Klarnamen verknüpft.

Für ein soziales Netzwerk ist das eine erhebliche Einstiegshürde. Kaum jemand lädt leichtfertig Identitätsnachweise hoch.

Wer den Ansatz einer europäischen Qualitätsplattform unterstützen wollte, ging diesen Schritt dennoch. Die Zusage lautete, dass die Verifikation den reservierten Zugang freischaltet, sobald die Early-Access-Phase startet.

Danach vergingen drei Monate ohne weitere Statusmeldung.

3. Die Einladung: Erwartung und Fehlermeldung

Nach der Wartezeit traf vor wenigen Tagen die Einladungsmail ein:

„Welcome to W — You have been selected for early access and are among the first users to help us test and shape W before the public rollout. Getting started: Step 1 – Create your account.“

Der Klick auf die Schaltfläche „Create Your Account“ in der E-Mail führte über einen Tracking-Link des Marketing-Dienstleisters Brevo auf die Onboarding-Applikation (https://wsocial.eu/onboarding).

In der Adresszeile des Browsers waren die Parameter bereits gesetzt:

https://wsocial.eu/onboarding?inviteCode=pds-wsocial-network-xxxx-xxxx&email=user%40example.com&handle=username

Das Webformular übernahm E-Mail und Wunsch-Handle aus den URL-Parametern.

Nach Eingabe von Name und Passwort folgte im Onboarding-Schritt 1 der Klick auf Next.

Das Formular reagierte mit einer eindeutigen Fehlermeldung:

Provided invite code not available

Kein Hinweis auf ein Formatproblem, keine differenzierte Erklärung im Interface.

+---------------------+      Invite-Link via Brevo        +----------------------+
| Early-Access-Mail   | --------------------------------> | Onboarding-Frontend  |
| (Brevo-Redirect)    |                                   | (liest URL-Parameter)|
+---------------------+                                   +----------------------+
                                                                     |
                                                               POST Validierung
                                                           (server.createAccount)
                                                                     v
                                                          +----------------------+
                                                          | Backend / PDS        |
                                                          | Token: NOT AVAILABLE |
                                                          +----------------------+

4. Technische Betrachtung: Was wir beobachten und was unklar bleibt

Was passiert an dieser Stelle technisch?

Ein Blick in die Entwickler-Tools des Browsers zeigt die Kommunikation beim Absenden des Formulars.

Das Frontend sendet einen Request an den entsprechenden Account-Endpunkt:

POST /xrpc/com.atproto.server.createAccount HTTP/2
Host: pds.wsocial.eu
Content-Type: application/json

{
  "email": "user@example.com",
  "handle": "username.wsocial.eu",
  "inviteCode": "pds-wsocial-network-xxxx-xxxx",
  "password": "****************"
}

Das Backend antwortet mit HTTP 400:

HTTP/2 400 Bad Request
Content-Type: application/json

{
  "error": "InvalidInviteCode",
  "message": "Provided invite code not available"
}

Die Faktenlage (Incident-Analyse)

Um sachlich zu bleiben, müssen wir klar trennen, was dokumentiert ist und was wir von außen nicht wissen können:

Tatsächlich beobachtet (OBSERVED):

Die Einladungs-E-Mail wurde über einen Brevo-Tracking-Link zugestellt.
Die Ziel-URL enthielt inviteCode, email und handle als Query-Parameter.
Das Frontend las diese Parameter ein und zeigte sie im Formular an.
Beim Absenden antwortete der Server mit InvalidInviteCode / Provided invite code not available.

Vom Anbieter bestätigt (CONFIRMED BY W SOCIAL): Auf Nachfrage erklärte der Support wörtlich:

„We've just made an update to our onboarding process, which is why the invitation you received is no longer working.“ Der Onboarding-Prozess wurde also zwischenzeitlich geändert – und meine zuvor verschickte Einladung funktionierte deshalb nicht mehr.

Nicht bekannt (UNKNOWN): Wie die Backend-Architektur im Detail strukturiert ist, wie die Token-Generierung intern abläuft oder an welcher Stelle die Zuordnung zwischen Einladungs-Batch und Account-Erstellung verloren ging, lässt sich von außen nicht verifizieren.

Plausible Fehlerklassen (HYPOTHESES):

Ungültig gewordener Token-State: Im Zuge der Prozessumstellung wurden bestehende Einladungscodes serverseitig invalidiert oder nicht in das neue Schema migriert.
Inkonsistenz zwischen Release und E-Mail-Versand: Das Versenden der Einladungskampagne und der Rollout des neuen Onboarding-Workflows liefen zeitlich auseinander.
Fehlende Zustandskopplung: Der Early-Access-Datensatz aus der Vorregistrierung wurde im neuen Account-Workflow nicht mehr als berechtigt geführt.

Da der Fehler serverseitig auftrat, ging eine entsprechende Support-Anfrage mit genauen Parametern und Fehlermeldungen an support@wsocial.eu.

5. Die Support-Lösung: Der Londoner QR-Code

Die Antwort des Supports folgte zeitnah, hielt jedoch eine bemerkenswerte Lösung bereit:

„We've just made an update to our onboarding process, which is why the invitation you received is no longer working. Please scan the attached QR code instead, and you'll be able to create your W Social account from there.“

An die E-Mail war eine PNG-Grafik mit einem QR-Code angehängt.

Statt den Code mit dem Smartphone abzufotografieren, lässt sich das Bild auf der Konsole (etwa mit zbarimg) dekodieren, um die Ziel-URL direkt zu prüfen.

Das Ergebnis:

https://studio.wsocial.eu/direct-onboarding/subscribe?code=74a327d4&utm_campaign=london&utm_medium=print&utm_source=qr

Ein Blick auf die Tracking-Parameter:

utm_campaign=london
utm_medium=print
utm_source=qr

Der Support antwortete nicht mit einer individuellen Freischaltung, sondern mit einem QR-Code, dessen Ziel-URL laut UTM-Parametern einer Print-Kampagne namens london zugeordnet war.

Die Zielseite unter studio.wsocial.eu/direct-onboarding/subscribe bot jedoch:

Keine Account-Erstellung,
keine Vergabe von Passwörtern,
keine direkte PDS-Provisionierung,
sondern ein Formular zur Erfassung von E-Mail, Wunsch-Handle und Wohnsitzland für eine Warteliste.

Für einen Tester, der vor Monaten eine Ausweisprüfung durchlaufen und gerade eine Einladung erhalten hatte, bedeutete das den Schritt zurück auf Start.

6. Der Prozessbruch im Support

Auf die Rückfrage per E-Mail:

„The QR code does not replace the invalidated invite. It opens a waitlist capture form with print-campaign tracking from a London event (utm_campaign=london, utm_medium=print). It is not account creation. I already completed ID verification with my national ID months ago. Please activate the verified record and send a working create-account link.“

...antwortete der Support mit einer weiteren Frage:

„Thanks for clarifying. Just to make sure I understand where you are in the process: have you already successfully created an account in W Social? And have you already completed the verification process in W Identity?“

Hier zeigt sich die eigentliche operative Schwachstelle:

Der Support hatte offenbar keinen unmittelbaren Einblick in den Gesamtstatus meines Profils. Weder lag vor, ob der W-Social-Account bereits existiert, noch war für den First-Level-Agenten direkt ersichtlich, ob die Prüfung bei W Identity erfolgreich abgeschlossen worden war.

Das ist keine theoretische Frage über interne APIs, sondern eine konkrete organisatorische Beobachtung:

Wenn der Status aus Identitätsprüfung, Account-Erstellung und Einladung für den Support nicht konsistent sichtbar ist, entstehen genau an diesen Nahtstellen solche Brüche.

7. Die Datenschutzfrage: Was passiert mit dem Identity-State?

Neben dem technischen Ablauf wirft das Verfahren wichtige Fragen hinsichtlich des Umgangs mit sensiblen Identitätsdaten auf.

W Social und W Identity betonen in ihren öffentlichen Dokumenten, dass W Social selbst keine Ausweisdaten erhält und W Identity nach erfolgreicher Prüfung Identitätsattribute primär lokal auf den Nutzergeräten verwalten möchte, statt dauerhafte serverseitige Profile aufzubauen.

Aus Nutzersicht bleiben nach einem abgebrochenen Onboarding dennoch zentrale Fragen nach den Grundsätzen von Art. 5 DSGVO und Art. 17 DSGVO offen:

Zweckbindung & Transparenz (Art. 5 Abs. 1 lit. b): Welche Daten wurden während der Prüfung temporär verarbeitet und welchen Status hat der resultierende Verifikationsdatensatz?
Datenminimierung (Art. 5 Abs. 1 lit. c): Wenn der Onboarding-Workflow auf ein generisches Formular umgestellt wird, für welchen Zweck existiert die vorherige Verknüpfung zur Identitätsprüfung?
Speicherbegrenzung & Löschung (Art. 5 Abs. 1 lit. e, Art. 17): Wie lange verbleiben temporäre Prüfprotokolle bei zwischengeschalteten Verifikationsdienstleistern, wenn der anschließende Account nie erfolgreich provisioniert wird?

Das Problem ist hierbei nicht zwingend ein vorsätzlicher Verstoß, sondern mangelnde Transparenz:

Wer Nutzer für die Verifikation mit einem amtlichen Ausweisdokument durch einen Identity-Prozess schickt, sollte anschließend transparent erklären können, welcher Verifikationsstatus besteht, welche Daten noch verarbeitet werden und wie dieser Status mit dem eigentlichen Account verknüpft ist.

8. Was wir für verteilte Onboarding-Architekturen lernen

Der Vorfall ist ein lehrreiches Beispiel dafür, welche Herausforderungen beim Zusammenspiel von Identitätsdiensten, Einladungslogik und Anwendungs-Backends entstehen.

Fünf grundlegende Erkenntnisse für Software- und System-Architekten:

Sensible Identitätsprüfungen an den fertigen Lifecycle koppeln Eine Identitätsprüfung mit amtlichen Dokumenten sollte erst dann in den Produktivpfad integriert werden, wenn die anschließende Provisionierung der Benutzerkonten vollständig automatisiert und erprobt ist. Unvollständige Übergänge belasten das Vertrauen.
Konsistenz zwischen Einladungen und Kontenverwaltung Einladungs-Tokens müssen stets einen wohldefinierten Lebenszyklus im Backend haben. Werden Kampagnen verschickt, muss der Token-Zustand (ISSUED, VALID, CONSUMED, EXPIRED) transaktional abgesichert sein — beispielsweise über koordinierte Release-Gates oder Entwurfsmuster wie die Transactional Outbox, um ein Auseinanderdriften von E-Mail-Versand und Datenbankstand zu verhindern.
Frühzeitige Validierung im Frontend Ein Registrierungsformular sollte den übergebenen Token möglichst frühzeitig überprüfen. Eine beispielhafte Implementierung könnte so aussehen:

GET /api/onboarding/invites/{token}/status

(Hinweis: Dies ist ein illustratives Architekturbeispiel, kein nativer ATProto-XRPC-Endpunkt.)

Schlägt die Prüfung fehl, erfährt der Nutzer dies sofort beim Laden der Seite — und nicht erst, nachdem er Name, E-Mail und Passwort eingetippt hat.

Konsolidierte Observability für den Support Der Kundenservice ist Teil des operativen Systems. Support-Mitarbeiter benötigen bei geschlossenen Betas ein Dashboard oder ein Tooling, das den Status eines Nutzers über alle Prozessschritte hinweg (Verifikation → Invite → Provisionierung) eindeutig abbildet, statt Statusfragen an den Nutzer zurückzuspielen.
Saubere Entkopplung von Identitätsprüfung und Protokoll Das AT-Protokoll selbst benötigt für die Erstellung eines Repositories keinen Personalausweis. Wenn Plattformbetreiber zusätzliche Vertrauensprüfungen wünschen, sollten diese als optionale oder nachgelagerte Attestierung konzipiert sein, damit der grundlegende Protokollbetrieb unabhängig von Drittsystemen stabil bleibt.

Vertrauen muss man sich erarbeiten

W Social wirbt selbst mit dem Leitgedanken: „Trust should be earned.“

Dieser Satz bringt es auf den Punkt.

Ein europäisches soziales Netzwerk kann technisch auf offene Protokolle, Föderation, EU-Rechenzentren und Datenschutz setzen — all das sind richtige und notwendige Schritte.

Aber Vertrauen entsteht nicht allein durch das Versprechen digitaler Souveränität oder das Einfordern von Ausweisen. Vertrauen entsteht dort, wo der gesamte Weg von der Registrierung über den Invite bis zum funktionierenden Account verlässlich, transparent und handwerklich sauber funktioniert.

Und wer dieses Vertrauen bei seinen ersten Testern aufbauen will, liefert am Ende eine funktionierende Registrierung — und keinen QR-Code aus einer Londoner Print-Kampagne.

Inhalt