Waag’s post says it moved its Bluesky account data from Bluesky’s own Personal Data Server, or PDS, to Eurosky, a European hosting provider for AT Protocol accounts. The point was not that Waag built its own social network. It was to test whether a Bluesky user can actually move account hosting without losing their social graph or app experience, and to reduce dependence on a US platform while staying inside the same network.
That basic portability held up. Several people clarified that your PDS, which stores your account data, is separate from the app you use to read and post. So a “follow us on Bluesky” link can still point at bsky.app even if the account’s data lives elsewhere. That distinction mattered because many readers initially thought the post was claiming more than it was. In practice, this was a host migration, not some full exit from Bluesky.
The sharper point was how partial the decentralization still is. One commenter cited atproto.barn.city showing about 98.5 percent of repos still hosted by Bluesky. That makes moves like this meaningful as proof that migration works, but not yet evidence of a widely distributed network. People also pushed on what “decentralized” means here. Defenders of AT Protocol argued that identity is anchored in DIDs and can be moved, especially if users register their own rotation keys, so the host is not supposed to own the account forever. Critics replied that for almost all users Bluesky still stores the practical signing keys, which means the default experience remains strongly custodial even if the protocol allows more independence.
Privacy landed as the clearest limitation. AT Protocol is designed for public replication of posts, which some people said is fine for public social media and others said makes it a bad fit for anyone who hears “data sovereignty” and assumes confidentiality. Moving from Bluesky hosting to Eurosky may help with jurisdiction, resilience, and institutional control. It does not make public social content private. The overall mood was that this is a useful milestone for portability and European hosting, but also a reminder that Bluesky’s ecosystem is still early, still heavily centralized in practice, and not a privacy system.
If you are evaluating Bluesky or AT Protocol for an organization, separate three layers before committing: where account data is hosted, which app people use, and who ultimately controls identity keys. This move shows account portability is real, but it does not solve public-data exposure or the fact that most of the network still sits on Bluesky infrastructure.
Cautiously positive. People liked seeing a real account migration away from Bluesky hosting and treated it as proof that AT Protocol portability is not just marketing, but they were blunt that the network is still heavily centralized in practice and offers little privacy for public content.
Key insights
01
Identity control depends on key custody
AT Protocol can separate identity from hosting, but only if the user takes control of rotation keys instead of leaving Bluesky to hold everything. The useful distinction is between what the protocol permits and what the default product does. By default Bluesky stores the private keys for most users. A user who registers their own rotation key in the PLC directory can later swap hosts or remove Bluesky-managed keys without losing the account identity.
If portability is a business requirement, do not stop at “supports DIDs.” Ask who holds signing and rotation keys today, and whether your team has a tested process to move them before an outage, dispute, or policy change forces the issue.
The important signal here is not mass decentralization. It is that host migration appears to work before users make a permanent infrastructure choice. That lowers lock-in, but the current network is still overwhelmingly concentrated on Bluesky hosting. The cited figure of roughly 98.5 percent of repos on Bluesky shows how far the system is from the distribution people usually imagine when they hear decentralized.
Treat this as an interoperability proof point, not a market structure shift. If concentration risk matters to you, watch the share of accounts hosted outside Bluesky over time rather than the existence of a few successful migrations.
A Bluesky account can move its stored data to another PDS without changing the app people use to interact with it. Following an account is just writing a record against that identity, so links into bsky.app still work even when the account is hosted elsewhere. That is a practical usability win because migration does not require dragging users onto a new client at the same time.
When assessing migration risk, split user experience from backend custody. You may be able to change hosting providers or jurisdiction first, then decide later whether you also need a different app surface.
AT Protocol is built to replicate public data widely, which is great for resilience and third-party app access but bad for anyone expecting privacy from where the data is hosted. That means a Europe-based PDS can improve control over operators and legal exposure, yet it does not change the fact that public posts are designed to spread across the network. Calling this a sovereignty move is fair. Calling it a privacy move is not.
Do not use AT Protocol for workflows where confidentiality is the goal. If your organization needs social reach and public archiveability, it fits. If you need private communications or limited disclosure, use a different system.
A former Inrupt SDK team member said AT Protocol delivered much of the user-portability vision people wanted from Tim Berners-Lee’s Solid, but without the adoption drag of RDF and JSON-LD. That frames this story as part of a longer pattern. The technical architecture that wins is often the one that asks less of developers, not the one with the most ambitious semantic model.
If you are betting on open identity or data portability, inspect the implementation burden as hard as the governance story. Developer friction can kill a standards effort long before the principles do.
People doing infrastructure work said there is real demand from European public and quasi-public bodies to move services off US clouds or at least map dependencies on US providers. The work exists, but it sounds messy. Expect layers of contractors, vague specs, and slow approvals. The notable part is that hands-on Linux and self-hosting experience is becoming commercially valuable again because cloud-only operators often lack the skills needed for repatriation.
If you sell infrastructure services in Europe, package migration and dependency-audit offerings now. Teams with practical operations experience can turn sovereignty concerns into near-term revenue, especially outside pure software companies.
For organizations that mainly want an independently run social presence, moving Bluesky hosting can look like solving the wrong problem. Starting a Mastodon server gives you direct control on a network already built around many independently operated instances, instead of relying on an ecosystem where Bluesky still dominates hosting and user attention.
Before investing in AT Protocol migration, compare it against the simpler path of adopting an already federated network. The better choice depends on whether you value Bluesky’s audience more than cleaner independence.
Claims that decentralized infrastructure is mainly built by VC-backed companies drew skepticism. Several people pointed instead to nonprofit governance as the sturdier home for digital commons, citing Internet Archive, Let’s Encrypt, ICANN, and the Linux Foundation. The useful correction is not that companies are irrelevant. It is that governance and control matter more than where early funding came from when you are trying to prevent future capture.
When evaluating “open” platforms, look past protocol claims and startup funding narratives. Ask which entity can change the rules, who controls the assets if the company is sold, and whether key infrastructure sits behind a mission-locked institution.