There are moments in IT when, as an infrastructure architect, you instinctively root for a project to succeed. You see the architectural blueprint, nod at the core decisions, and think: Yes. This is exactly what Europe needs.
The idea of building a privacy-oriented social network based on the open, federated AT Protocol, running dedicated Personal Data Servers (PDS) in European data centers, and establishing a reliable alternative to established platforms is long overdue.
That was precisely the promise made by the European platform initiative W Social.
Positioned as a European alternative:
- Focus on data privacy and EU hosting.
- Verified identities through an upfront check to combat bots.
- Physical data residency on European servers.
- Adoption of open, decentralized network standards.
Of course, the vision deserves respect and the underlying network protocol is well thought-out.
Yet what unfolded during the closed early-access rollout of W Social shows how quickly user trust erodes when marketing communications, sensitive identity checks, and a modified onboarding workflow fail to align cleanly.
When customer support answers tickets with QR codes from print campaigns while the official invite link fails, even a promising concept begins to falter.
So I opened the browser DevTools to see what actually happens upon clicking Next.
Here is the documentation of a remarkable onboarding workflow.
1. The Technological Elegance: Why the AT Protocol Excites
To understand why a bumpy start is so regrettable, it is worth examining the architecture of the AT Protocol (Authenticated Transfer Protocol).
Anyone coming from the Linux and sysadmin world knows the constraints of classical, monolithic platforms.
There, identity, data, and social graph are permanently locked to the servers of a single provider. If an account is suspended or the platform is discontinued, contacts, content, and digital reputation disappear.
Even the Fediverse around ActivityPub (like Mastodon) has its characteristics:
If you migrate from one instance to another, your follower list can be ported, but historical posts and media remain on the old server.
The AT Protocol addresses this through a three-tiered layer separation:
+-------------------------------------------------------------------------+
| AppView / UI |
| (Aggregates feeds, search indexes, and interactions) |
+-------------------------------------------------------------------------+
^
| Firehose (Event-Stream / WebSocket)
+-------------------------------------------------------------------------+
| Relay / Indexer |
| (Crawls repos, validates cryptographic signatures) |
+-------------------------------------------------------------------------+
^
| Sync (MST Commits)
+-------------------------------------------------------------------------+
| PDS (Personal Data Server / Repos) |
| (Stores records in Merkle Search Tree, signs commits) |
+-------------------------------------------------------------------------+
^
| DID Resolution (did:plc / did:web)
+-------------------------------------------------------------------------+
| Identity / DIDs |
| (Cryptographic root of user identity) |
+-------------------------------------------------------------------------+
Core Components in Detail
- Decentralized Identity (
DID): Identity is anchored in a cryptographic identifier (typicallydid:plcordid:web). This identifier points to a DID document containing public keys and the active service endpoint of the data server. A user handle (e.g.@handle.domain.tld) serves as a human-readable alias resolved via DNS TXT records (_atproto.handle...) or HTTPS resources. - Personal Data Server (
PDS): The PDS hosts the user's data repository. Individual records (posts, likes, profile data) are structured inside a Merkle Search Tree (MST). In the AT Protocol, cryptographic signatures are applied to the repository commits, ensuring the entire state and history of the data tree remains verifiable and tamper-evident. - Portability: The protocol explicitly supports account and PDS portability. This is not a trivial background copy, but a multi-step process: the full repository data is transferred, and the service information in the DID document is subsequently updated.
- Relays & AppViews: Relays consume commit streams from PDS instances via the Firehose, validate signatures, and aggregate data streams. AppViews build search indexes, algorithms, and feeds for the user interface.
Building European PDS hosting with clearly defined data privacy and data sovereignty concepts is technically a sound direction.
That was the protocol design. Then came production reality.
2. The Gatekeeper: Identity Verification as a Prerequisite
To participate in the closed early-access phase of W Social a few months ago, submitting an email address was not enough.
The operators aimed to establish a platform with verified participants from day one to eliminate bots and spam.
The chosen barrier: Identity verification for beta testers.
Anyone wanting to register was directed to the W Identity portal:
- Verification required an official government ID card or passport.
- The process was handled by an identity service provider, similar to KYC workflows in the banking or crypto sector.
- The pre-registration was tied to the verified real name.
For a social network, this is a significant barrier to entry. Few people casually submit national identity documents.
Those who wanted to support a European quality platform took this step nonetheless, backed by the promise that verification would unlock the reserved account once early access commenced.
Then followed three months without any status updates.
3. The Invitation: Anticipation and Error State
After months of waiting, the official invitation email arrived a few days ago:
“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.”
Clicking the “Create Your Account” button in the email triggered a redirect through the Brevo marketing platform onto the onboarding application (https://wsocial.eu/onboarding).
In the browser address bar, the parameters were already set:
https://wsocial.eu/onboarding?inviteCode=pds-wsocial-network-xxxx-xxxx&email=user%40example.com&handle=username
The web form populated the email and preferred handle directly from the URL.
After entering a name and strong password, clicking Next in step 1 of the onboarding wizard produced an immediate error message:
Provided invite code not available
No format explanation, no further context in the interface.
+---------------------+ Invite link via Brevo +----------------------+
| Early-Access Email | --------------------------------> | Onboarding Frontend |
| (Brevo Redirect) | | (Reads URL params) |
+---------------------+ +----------------------+
|
POST Validation
(server.createAccount)
v
+----------------------+
| Backend / PDS |
| Token: NOT AVAILABLE |
+----------------------+
4. Technical Analysis: Observed Facts vs. Hypotheses
What happens under the hood at this stage?
Inspecting the browser DevTools reveals the request upon submitting the form.
The frontend dispatches a request to the corresponding account endpoint:
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": "****************"
}
The backend responds with HTTP 400:
HTTP/2 400 Bad Request
Content-Type: application/json
{
"error": "InvalidInviteCode",
"message": "Provided invite code not available"
}
Incident Breakdown
To maintain objectivity, we must strictly separate documented facts from unprovable assumptions:
Observed Facts (OBSERVED):
- The invitation email arrived via a Brevo tracking redirect.
- The destination URL contained
inviteCode,email, andhandleparameters. - The frontend parsed these parameters into the form.
- Upon form submission, the server responded with
InvalidInviteCode/Provided invite code not available.
Confirmed by W Social (CONFIRMED BY W SOCIAL): When asked, support explicitly replied:
“We've just made an update to our onboarding process, which is why the invitation you received is no longer working.” The onboarding workflow was therefore modified in the interim – and my previously issued invitation no longer functioned as a result.
Unknown (UNKNOWN): How the backend architecture is structured internally, how token generation operates, or where the linkage between invite batches and account creation broke down cannot be verified from the outside.
Plausible Failure Modes (HYPOTHESES):
- Invalidated token state: During the process transition, existing invite codes were invalidated or not migrated into the new schema.
- Inconsistency between deployment and email dispatch: Campaign distribution and the rollout of the new onboarding workflow diverged in timing.
- Missing state linkage: The early-access record from pre-registration was no longer recognized as authorized in the new account workflow.
Because the failure occurred on the server side, a detailed ticket with full parameters and error traces was sent to support@wsocial.eu.
5. The Support Solution: The London QR Code
Support replied promptly, proposing an unexpected workaround:
“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.”
Attached to the email was a PNG image containing a QR code.
Rather than scanning the image with a phone camera, running it through a command-line decoder (such as zbarimg) reveals the target URL directly:
The result:
https://studio.wsocial.eu/direct-onboarding/subscribe?code=74a327d4&utm_campaign=london&utm_medium=print&utm_source=qr
A glance at the tracking parameters:
utm_campaign=londonutm_medium=printutm_source=qr
Support did not resolve the ticket by provisioning the account, but instead provided a QR code whose destination URL was attributed by UTM parameters to a print campaign named london.
The destination page at studio.wsocial.eu/direct-onboarding/subscribe offered:
- No account creation,
- no password setup,
- no direct PDS provisioning,
- but a generic capture form for email, handle, and residency for a waitlist.
For a beta tester who had completed ID verification months prior and just received an official invitation, this was a step back to square one.
6. Process Boundaries in Customer Support
Following an email clarification:
“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.”
...support responded with a follow-up inquiry:
“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?”
Here lies the actual operational friction:
Support apparently lacked immediate visibility into the consolidated lifecycle state of the user. Neither was it known whether the W Social account already existed, nor was it directly evident to the first-level agent whether verification in W Identity had been completed.
This is not a theoretical critique of internal APIs, but a concrete operational observation:
When the status across identity verification, account provisioning, and invitation is not consistently visible to support, fractures naturally emerge along these organizational seams.
7. The Privacy Question: What Happens to Identity State?
Beyond the technical workflow, the scenario raises valid questions regarding the handling of sensitive identity data.
W Social and W Identity state in their public documentation that W Social itself does not receive ID documents, and that W Identity aims to manage identity attributes locally on user devices rather than building permanent server-side profiles.
From a user perspective, however, key questions under the principles of GDPR Art. 5 and GDPR Art. 17 remain open after an aborted onboarding:
- Purpose Limitation & Transparency (Art. 5(1)(b)): What data was processed during verification, and what is the current lifecycle status of that verification record?
- Data Minimization (Art. 5(1)(c)): If the onboarding workflow is transitioned to a generic waitlist form, for what purpose is the prior link to the identity verification maintained?
- Storage Limitation & Erasure (Art. 5(1)(e), Art. 17): How long are temporary verification logs retained by third-party identity providers if the corresponding account is never provisioned?
The issue here is not necessarily an intentional violation, but a lack of transparency:
Anyone directing users through an identity verification process with official government documents should subsequently be able to explain transparently what verification status exists, which data is still processed, and how this status links to the actual account.
8. Lessons for Distributed Onboarding Architectures
This case is an instructive example of the challenges that arise when orchestrating identity services, invitation tokens, and application backends.
Five fundamental takeaways for software and systems architects:
-
Couple sensitive identity checks to a complete lifecycle An upfront identity check involving government documents should only be placed in production once the subsequent account provisioning is fully automated, tested, and reliable. Incomplete transitions degrade user confidence.
-
Consistency between invitations and account management Invitation tokens must maintain a well-defined backend lifecycle. When campaigns are dispatched, token states (
ISSUED,VALID,CONSUMED,EXPIRED) must remain synchronized — for example via coordinated release gates or design patterns like the Transactional Outbox, preventing email distribution from drifting away from database reality. -
Early validation in frontends A registration frontend should validate incoming tokens as early as possible. An illustrative example:
GET /api/onboarding/invites/{token}/status
(Note: This is an illustrative architecture example, not a native ATProto XRPC endpoint.)
If a token is invalid or expired, the user is notified immediately upon page load — rather than after typing in credentials.
-
Consolidated observability for support Customer service is an integral component of the operational system. Support staff in closed rollouts require tooling or dashboards that clearly surface a user's status across all pipeline stages (Verification → Invite → Provisioning), rather than bouncing state questions back to the user.
-
Clean decoupling of identity verification from protocol mechanics The AT Protocol itself does not require a national ID to host a data repository. When platforms introduce additional trust requirements, these should be modeled as optional or downstream attestations to ensure protocol-level operations remain resilient and decoupled.
Trust Should Be Earned
W Social uses the guiding motto: “Trust should be earned.”
That statement captures the essence.
A European social platform can leverage open protocols, federation, EU data centers, and privacy-conscious design — all of which are sound and necessary steps.
However, trust is not established solely by promising digital sovereignty or requiring ID verification. Trust is built when the entire journey from registration and invite validation to a working account operates reliably, transparently, and with solid engineering craftsmanship.
And anyone looking to build that trust with their early testers delivers a functioning onboarding — not a QR code from a London print campaign.