A technical user documents their frustrating attempt to set up a personal PDS (Personal Data Server) for Bluesky using ATProto, revealing critical gaps in documentation, tooling, and user experience that make true decentralization practically impossible for anyone but the most determined system administrators.
The Promise vs. The Reality
The ATProto protocol theoretically enables true social media decentralization, but the chasm between that promise and actual user experience remains vast. After attempting to set up a personal PDS instance and migrate away from Bluesky's infrastructure entirely, the reality proves far more complicated than the protocol's documentation suggests.
The journey begins with setting up the PDS software, which on NixOS proved surprisingly straightforward. However, this initial success masked the labyrinth of undocumented steps ahead. The core challenge centers on DID (Decentralized Identifier) management, specifically did:web implementation - a critical piece of infrastructure that Bluesky's documentation treats as an afterthought rather than a primary use case.
The Documentation Void
Following Mai Lapyst's tutorial for did:web setup revealed the first major problem: community documentation is rapidly outdated and incomplete. The tutorial missed a critical step that only became apparent through trial and error. Creating the public-private keypair and publishing the did.json document requires specific CORS headers on the webserver - a detail that breaks the entire flow if missed, yet appears nowhere in official documentation.
The official Bluesky documentation for the getRecommendedDidCredentials endpoint exemplifies this documentation crisis. The endpoint's description reads: "Describe the credentials that should be included in the DID doc of an account that is migrating to this service." This framing assumes migration from an existing account, not new account creation. Worse, the JSON keys returned are "almost, but not quite" the same as standard DID document format, requiring manual editing before use. The documentation provides no examples, no warnings about this discrepancy, and no explanation of why this deviation exists.
The Blacklist Problem
Perhaps most concerning is what happens when things go wrong. After creating an account that appeared in a "deactivated" state, attempts to activate it manually via curl requests and PDS log analysis proved fruitless. Seeking help in the ATProto Touchers Discord led to advice to delete the account and start fresh - a seemingly reasonable suggestion that turned catastrophic.
Upon re-creating everything with the correct key format, logging into Bluesky's web interface revealed a "Profile does not exist" error. Investigation through GitHub issues revealed the brutal truth: the AppView (Bluesky's primary interface) maintains a blacklist of DID identifiers. Once an account is deleted, even a completely empty, unused account, that DID becomes permanently blacklisted from the centralized AppView infrastructure.
This creates a paradox: users are encouraged to experiment with self-hosting and decentralization, but the system punishes experimentation by permanently blocking access to the primary social network interface. The only recourse is contacting Bluesky's corporate support - exactly the centralized dependency the protocol was supposed to eliminate.
The PKI Burden
This experience validates a fundamental criticism: requiring users to manage their own Public Key Infrastructure without proper tooling or documentation is untenable. The complexity here exceeds setting up a Mastodon instance in 2017, yet Bluesky expects average users to navigate this landscape while choosing between self-hosting and centralization.
The technical barriers include:
- Understanding DID document format and key rotation
- Managing CORS policies for decentralized identity
- Navigating undocumented API endpoints and their non-standard responses
- Understanding that deletion creates permanent blacklists
- Recognizing that "decentralized" protocols still rely on centralized AppViews for basic functionality
The Centralization Paradox
Blacksky's AppView implementation demonstrates that theoretical decentralization is achievable, but Bluesky's own infrastructure remains the default and nearly the only practical option. The protocol may be decentralized, but the social network built on top of it is not - at least not in any way that actual users can access.
This reveals a deeper pattern in "decentralized" social media: the protocol layer enables federation, but the application layer remains heavily centralized around a single company's infrastructure. Users who want true independence must navigate undocumented complexity, accept permanent blacklisting for minor mistakes, and ultimately rely on corporate support to regain access.
The result is a system that claims to solve the problems of centralized social media while actually just moving the dependency from the protocol level to the application level. Until Bluesky invests in comprehensive documentation, user-friendly tooling for key management, and removes the blacklist penalty for experimentation, ATProto's decentralization will remain theoretical rather than practical.
For now, the promise of user-controlled social media remains just that - a promise. The technical foundations exist, but the user experience gap prevents meaningful decentralization from reaching anyone beyond the most dedicated system administrators willing to spend days debugging undocumented APIs and manually editing cryptographic keys.
Comments
Please log in or register to join the discussion