I am excited about what BlueSky is doing. Their folks are working in the open on their platform, and that kind of dogfooding is something that deeply attracted me to joining Slack back in 2021. (I've since left).
That said, there are legitimate criticisms about the present BlueSky experience, along with components of the AT Protocol that raise safety concerns. In this post, I'll share a few of the ones that stand out to me.
1️⃣ All human users of any social technology assume some level of risk.
2️⃣ Some human users of social technology assume more risk than the average person.
3️⃣ Since all human users have their own individual level of risk tolerance, not every human user will feel the same level of comfort with the same social technology.
The following criticisms are meant to cultivate curiosity and conversation—not to suggest that BlueSky is unsafe or that you should avoid BlueSky.
You (yes you) must make your own judgement about the level of social and personal risk you are willing to assume with any social technology.
With that out of the way, let's get started:
Centralized control, "decentralized" marketing
BlueSky's architecture creates a form of "faux decentralization" where technical openness exists but practical control remains concentrated.
This matters because some users who believe they're joining and participating in a truly decentralized network may make different risk calculations and investment decisions if they were aware that significant parts of the current BlueSky infrastructure is centralized.
For example, users building communities on BlueSky may assume they have more autonomy and protection from corporate decisions than they actually do.
The practical impact of this comes from historical examples of social technology company decisions, like Twitter's API changes or Tumblr's content policy shifts. When a central authority controls key infrastructure, they can effectively force changes on the entire network regardless of theoretical protocol openness. This fundamentally undermines the resilience and user autonomy that true decentralization should provide.
This centralization also creates a single point of pressure for government regulation, advertiser demands, or market forces. If BlueSky PBC faces financial pressure or regulatory challenges, their decisions will cascade through the network in ways users can't meaningfully resist despite the "decentralized" architecture.
If I were building something like BlueSky, I would have made the same decision to centralize the same parts of the infrastructure. It's just not realistic to assume that a brand new protocol with only a growing social proof would instantly have a globalized network of federated infrastructure components.
In fact, folks on the BlueSky team have been very clear about the fact that AT Protocol and BlueSky experimenting with market capture on top of a decentralized protocol are, in fact, two separate things.
"You can just move your data somewhere else"
The current limitations on account portability create a kind of soft lock-in that undermines one of decentralization's key promises—that accounts (your data, your "identity" is truly portable, not theoretically portable).
While users theoretically "own their identity," the practical difficulty of migrating between providers means most users will remain tied to their initial provider. This matters because genuine account portability is how users maintain leverage against platform decisions.
The technical barriers to migration combined with network effects create a situation similar to early email, where users could technically move providers but practically found it too difficult or costly. This reduces competitive pressure on providers to maintain user-friendly policies and can lead to gradual degradation of service quality or user rights.
For everyday users, this means the theoretical benefits of decentralization—like being able to "vote with your feet" when unhappy with a provider—remain largely theoretical. This particularly impacts vulnerable communities who may need to rapidly migrate away from hostile providers but find themselves effectively trapped by technical and social barriers.
Personally, I don't think BlueSky has any obligation in our current economic reality to make migrating accounts easy. They are using the same protocol that everyone else has access to, so ease of account migration is something that anyone can work on.
That being said, my opinion is that a public benefit corporation ought to clearly articulate what is and is not within the bounds of "public benefit." I personally feel like account data and ipso facto the ability to transfer PDS hosts is part of the whole 'public benefit' part of being a social technology PBC.
Scalability and capital costs
The decision to build a custom protocol rather than building on proven standards creates significant technical risk that may not be apparent to early adopters. Social platforms face unique scaling challenges around real-time content delivery, federation overhead, and abuse prevention. Without extensive real-world testing at scale, there's substantial risk of degraded performance or even system failures as the network continues to grow.
This particularly matters because social networks rely heavily on reliability and responsiveness for their core functions. Users engaged in real-time discussions or breaking news situations need and rely on consistent performance. If the protocol struggles to scale across non-BlueSky infrastructure, it could fragment the user experience in ways that undermine the network's utility, especially during high-traffic events.
The scaling challenges of federation add another layer of complexity that could lead to practical limitations on how decentralized the network can actually become. If performance issues force consolidation around a few large providers, it could recreate the same centralization problems BlueSky aims to solve.
There is no social technology in the past, present, or future that will not run into this issue.
Corporately consolidated governance
The lack of formal community governance creates a fundamental misalignment between BlueSky's decentralization claims and its actual power structure. In practice, this means users have no guaranteed voice in protocol decisions that could fundamentally impact their ability to communicate, conduct business, or maintain communities.
The history of social platforms shows that corporate interests often diverge from community needs, especially around issues of monetization, privacy, and content moderation. Without robust community governance, BlueSky risks repeating the pattern of gradually prioritizing business metrics over user experience and community health.
This matters intensely for marginalized communities, who often suffer first and worst from corporate policy changes. Without guaranteed representation in governance, these communities risk building on a platform that could become hostile to their needs with no real recourse.
I have no evidence to suggest that BlueSky is prioritizing business metrics over user experience and community health. Rather, all we collectively have is what social platforms have done in the past.
If we want to believe that we can have better social technology, at some point we need to adopt a kind of cautious faith with BlueSky; we have to hold space for them to do and build the things they say they're going to do and build. So far, they've generated a LOT of goodwill with the open source community.
From https://atproto.com/specs/atp:
Protocol Governance and Formal Standards Process: The current development focus is to demonstrate all the core protocol features via the reference implementation, including open federation. After that milestone, the intent is to stabilize the lower-level protocol and submit the specification for independent review and revision through a standards body such as the IETF or the W3C.
Default privacy model is not that private
The public-by-default approach with limited privacy options creates particular risks in an era of increasing surveillance and data mining. While public discourse is valuable, users often don't fully understand the implications of having their entire social graph and content history publicly accessible and federated across multiple providers.
The metadata exposure through federation creates additional privacy concerns that may not be apparent to average users. Every interaction potentially creates traces across multiple servers, making it difficult to truly control one's digital footprint. This matters increasingly as artificial intelligence and data analysis tools make it easier to build detailed profiles from seemingly innocuous public data.
For vulnerable users—including activists, journalists, or individuals in hostile environments—these privacy limitations could create serious in-person risks. The inability to fully control data flows across the federated network makes it difficult for users to make informed decisions about their safety and privacy.
As an example, I know individuals who block people they know IRL due to legitimate concerns about their behavior and/or ideologies. Since blocks on the AT Protocol are public, one's control over exposing their PII becomes delegated to the information that the people who they blocked share. (When a user blocks another user, this action creates a public app.bsky.graph.block
record that anyone can access).
The protocol design decisions that were made led to blocks being public. This is an example of the implicit risks that we accept (whether we know it or not) when using any social technology.
BlueSky as a business will probably end up working because the vast majority of people likely have not dealt with their online data being used to facilitate in-person harassment/stalking.
However, for anyone who has experienced their online activity leading to in-person harassment—especially when that harassment is centered around their in-person identity—blocks being public is a non-starter.
∎