The Core Argument

There's a thought that's been rattling around my head for a while now, one that feels almost heretical to admit in certain circles: I don't actually care if Bluesky as a company survives. Not really. What I care about – what I'm genuinely invested in – is whether the AT Protocol itself makes it.

This probably sounds strange coming from someone who's clearly bought into the ecosystem. I've built tools, written extensively about the technical implementation, run my own infrastructure, created feeds, migrated content between platforms. I'm hardly a casual observer. But that's precisely why I can make this distinction with clarity: the protocol matters infinitely more than any single company using it.

The Company vs The Protocol

Let me be clear about what I mean here. Bluesky PBC has done genuinely impressive work on the technical side. They've built a usable, functional social network that demonstrates the viability of decentralised identity and data portability. The engineering is solid, the user experience is smooth enough for non-technical users, and they've managed to attract millions of people to something that could easily have remained a niche experiment.

But here's the thing: that was always meant to be the point. Bluesky was supposed to prove that the AT Protocol could support a proper social media platform, not become the only platform that matters. The whole architecture – DIDs, personal data servers, AppViews, federation – was designed around the idea that no single entity should control the ecosystem.

And increasingly, I'm watching Bluesky PBC demonstrate why that separation matters. Not because the protocol is failing, but because the company's leadership is making decisions that highlight exactly why we need alternatives.

The Growing Leadership Problem

When Technical Skill Isn’t Enough

I want to be careful here because I genuinely respect the technical work this team has done. Building a functioning decentralised social protocol is no small feat, and their background as networking engineers at Twitter gave them insight into what actually needs to work at scale. But technical competence doesn't automatically translate into good platform governance, and that's becoming painfully apparent.

Community Harm and Marginalisation

The recent controversy around their updated Terms of Service and Community Guidelines has exposed something troubling: a tone-deafness in how they engage with marginalised communities that feels almost systematic. When users point out that Bluesky should "worry less about whether or not a cartoon has rights and more about whether real life trans and Palestinian people do," that's not just criticism – it's highlighting a fundamental priority mismatch.

The pattern isn't new, either. There have been ongoing concerns about how Palestinian accounts are moderated, with accusations of disproportionate censorship and account suspensions. Trans creators have voiced outrage over what they describe as inconsistent moderation, particularly around suspensions linked to criticism of J.K. Rowling. These aren't isolated incidents; they're revealing a consistent issue with how the platform handles content from vulnerable communities.

When I look at my own setup – running did:plc:ofrbh253gwicbkc5nktqepol, hosting content across WhiteWind, maintaining feeds, building conversion tools – none of that fundamentally depends on Bluesky PBC continuing to exist. That's not an accident. That's the architecture working as intended.

And frankly, given Bluesky's recent handling of community concerns, I'm increasingly grateful for that independence.

Why the Protocol Needs to Move Beyond Bluesky PBC

Carrying Twitter’s DNA

Here's what concerns me: Bluesky was conceived as a Twitter decentralisation project, built by engineers who came from that environment. That pedigree gave them technical expertise, but it also seems to have given them some of the institutional blindness that plagued Twitter itself. The inability to recognise when you're causing harm to marginalised communities, the prioritisation of abstract policy consistency over actual community safety – these are Twitter's mistakes being repeated.

Governance vs PR

The company desperately needs professional PR and community management that isn't engineering-led. When you're receiving over 14,000 pieces of feedback on policy changes – much of it expressing concern about how those changes affect marginalised voices – and your response still comes across as tone-deaf, that's not a technical problem. That's a governance problem.

I genuinely hope they pass stewardship of the AT Protocol to a neutral body. Not because I want to see Bluesky PBC fail, but because the protocol deserves leadership that isn't carrying Twitter's institutional DNA. The background that helped them build a functioning social protocol is increasingly the same background that's limiting their ability to govern it well.

My Conflicted Position

This is where I need to be honest about my own position. I like this team. I respect their technical work enormously. The AT Protocol is brilliantly designed, and they deserve credit for that. But liking someone's work doesn't mean blindly supporting their leadership, and I'm seriously starting to doubt their ability to lead the ecosystem they've created.

The technical foundation they've built is sound. The governance decisions they're making increasingly aren't. And those are two separate things that we need to evaluate independently.

What Actually Matters

Protocol as Infrastructure

The technical foundation is what deserves preservation. The elegance of how ATProto handles identity through DIDs means my digital presence isn't tied to any particular company's continued solvency. My did:plc identifier, my repository of posts and records, the cryptographic proofs of ownership – all of this exists independently of whether Bluesky's servers stay online.

Lessons from did:web Experiments

I've written before about experimenting with did:web as an alternative identity method. That entire exercise reinforced something crucial: the protocol's flexibility allows for multiple approaches to the same problems. If Bluesky's infrastructure disappeared tomorrow, the community could (and would) spin up alternative AppViews, alternative discovery mechanisms, alternative hosting solutions. The data would persist because it lives in repositories we control.

This is fundamentally different from how traditional social media works. When Twitter (or X, or whatever we're calling it this week) makes decisions I disagree with, my only recourse is to leave and lose everything I've built there. When Reddit imploded over API pricing, communities had to rebuild from scratch elsewhere. But with ATProto, the relationship between user and platform is fundamentally altered.

The Federation Question

Where We Are Now

Now, I'll be honest: federation in the ATProto ecosystem isn't quite where I'd like it to be yet. Bluesky still operates the primary Personal Data Server hosting for most users, and the network effects around their AppView are substantial. We're not yet at the point where dozens of thriving AppViews compete on equal footing, or where running your own PDS is as trivial as it should be.

Where We Could Be

But that's an implementation detail, not an architectural limitation. The protocol supports full federation; we're just early in the adoption curve. I've seen enough of the technical internals to know that the foundations are sound. As more people run their own infrastructure (and I've certainly tried my hand at PDS experiments enough times), the ecosystem will naturally decentralise further.

The crucial bit is that the protocol doesn't prevent this decentralisation – it actively enables it. Contrast this with platforms that claim to be decentralised but have federation as an afterthought, where the reality is a handful of large instances dominating everything.

Why This Matters to Me

Escaping Platform Decay

I grew up watching platforms rise and fall. MySpace became a digital ghost town. Google+ shut down entirely. Vine disappeared. Countless smaller platforms came and went. Each time, the communities built on those platforms had to scatter, rebuild, start over. Content was lost. Connections were severed. The digital history simply evaporated because it was tied to a company's continued existence.

Owning My Digital Identity

ATProto offers a different model. When I write blog posts, they're stored as records in my repository. If WhiteWind ceased operations tomorrow, I could migrate that content to Leaflet or any other compatible platform. I've literally built the tooling to do exactly this migration. The data isn't held hostage by any particular service provider.

This portability extends to social connections too. My followers aren't tied to a specific server; they're following my DID. My posts, my interactions, my identity – all of it is protocol-level rather than platform-level. That architectural choice cascades into real sovereignty over one's digital presence.

The Network Effects Problem

Why Bluesky Still Matters for Now

Of course, there's a practical reality here that can't be ignored: network effects matter enormously in social media. If everyone I want to interact with is using Bluesky's AppView and nowhere else, then Bluesky's continued operation has real implications for my ability to participate in those conversations.

But Portability Still Wins

But here's where I think the distinction becomes important. If Bluesky as a company disappeared but the protocol survived, the community could (theoretically) spin up alternative services remarkably quickly. The infrastructure isn't proprietary. The codebase is open source. The real challenge would be coordinating that transition, not the technical implementation.

Compare this to a scenario where Twitter shuts down. The community can't just "spin up another Twitter" because the entire stack is proprietary and the data is locked away. With ATProto, the transition would be messy and chaotic, certainly, but it would be possible. That possibility matters.

The Wider Implications

What excites me about ATProto isn't just the technical elegance – though I do appreciate clean architecture – it's what it represents for the broader evolution of online spaces. We've spent the last two decades building platforms where the relationship between user and service is fundamentally extractive. Your data, your content, your connections all exist at the pleasure of the platform operator.

ATProto suggests an alternative model: infrastructure as utility rather than as capture mechanism. The protocol provides the plumbing, various services provide the interface, and users maintain sovereignty over their own data. It's not perfect – no system is – but it's a substantial improvement over what we've accepted as normal.

This matters beyond just social media, too. The same principles could apply to other digital services where we've accepted vendor lock-in as inevitable. If the AT Protocol approach proves viable at scale, it demonstrates that truly decentralised systems can provide good user experiences without compromising on sovereignty.

The Practical Reality

Now, I should acknowledge the elephant in the room: we're not yet at the point where Bluesky's disappearance would be trivial to recover from. The ecosystem is still young. Most users rely on Bluesky-operated infrastructure. The network effects around their AppView are substantial. Alternative implementations exist but aren't yet mature enough to absorb millions of users overnight.

But that's precisely why thinking about this distinction matters now, while the ecosystem is still forming. If we treat Bluesky the company as synonymous with ATProto the protocol, we risk recreating the same centralisation dynamics we're trying to escape. The whole point of the protocol approach is that no single entity should be indispensable.

I want Bluesky PBC to succeed, genuinely. They're doing good work, they've built something impressive, and their continued operation makes the ecosystem stronger. But I want them to succeed as one participant in a thriving ecosystem, not as the sole linchpin that everything depends upon.

What Success Actually Looks Like

For me, success would look like an ATProto ecosystem where Bluesky is one of many viable options. Where running your own PDS is as straightforward as setting up a WordPress blog. Where different AppViews compete on features and user experience rather than network effects. Where identity is truly portable across services without friction.

We're not there yet, obviously. The ecosystem is still early, still forming, still finding its shape. But the architectural foundations support that vision, which is more than can be said for most alternatives. The question isn't whether the technology enables this future – it does – but whether the community and ecosystem develop in ways that realise that potential.

My Own Investment

I've put considerable time into this ecosystem. I've written extensively about the technical implementation, built tools for content migration, experimented with running my own infrastructure, created feeds and bots and various other projects. This isn't casual dabbling; I'm genuinely invested in seeing this succeed.

But that investment is in the protocol, not any particular company. When I build tools that work with ATProto, they'll continue functioning regardless of Bluesky's corporate status. When I write posts that live in my repository, they're mine to migrate elsewhere if needed. When I establish my digital identity through a DID, that identity isn't dependent on any single service provider's continued existence.

This is what digital sovereignty actually means, I think. Not complete independence from all infrastructure – that's neither practical nor desirable – but the ability to move between service providers without losing your digital identity and content. The difference between renting and owning, in a sense.

The Comparison Game

ActivityPub’s Trade-offs

It's worth contrasting this with other approaches to decentralised social media. ActivityPub has genuine federation, which is valuable, but the server-centric model means your identity is tied to wherever you're hosted. I've created and abandoned more Mastodon accounts than I care to count, each time leaving digital ghosts scattered across the fediverse when servers shut down or became untenable.

Nostr’s Direction

Nostr takes a different approach entirely, with the cryptographic key as the fundamental identifier. There's elegance to that, but the ecosystem has gone in directions I find less compelling. The protocol itself is sound; the community implementation tends toward cryptocurrency integration I'm not interested in.

Why ATProto Feels Different

ATProto sits in an interesting middle ground. Your identity is cryptographically verifiable but not dependent on managing raw private keys for everything. Your data is portable but doesn't require every client to implement full node functionality. The architecture acknowledges that most users want someone else to handle the infrastructure complexity whilst still preserving real sovereignty.

What Keeps Me Up At Night

The Gmail Problem

If I'm honest, what concerns me isn't just Bluesky dying – it's Bluesky becoming too successful in a way that undermines the protocol's decentralised nature whilst simultaneously being terrible at platform governance. Network effects are powerful, and there's a real risk that Bluesky's infrastructure becomes so dominant that the theoretical portability never gets tested at scale, all while the company makes increasingly questionable decisions about moderation and community management.

We've seen this pattern before with email. Technically, email is a decentralised protocol. Practically, most people use Gmail, and Google's decisions about spam filtering and authentication requirements effectively dictate standards for the entire ecosystem. The protocol survived, but the decentralisation largely didn't.

Bluesky’s Governance Risks

But at least Google has professional communications teams and (usually) understands PR. Bluesky PBC seems to be learning these lessons in real-time, and marginalised communities are bearing the cost of that education. That's not acceptable, and it's exactly why the protocol needs to exist independently of any single company's growing pains.

I'd rather see a vibrant ecosystem of mid-sized service providers than one massive platform that happens to use an open protocol but still makes the same mistakes as centralised platforms. The technical capability for decentralisation doesn't automatically translate into actual decentralisation if the incentive structures and network effects pull toward consolidation – especially when the dominant platform is actively alienating significant portions of its user base.

The Long Game

This is fundamentally a long-term perspective. In the short term, Bluesky's success or failure matters enormously because the ecosystem is still nascent. But in the longer arc – five years, ten years, beyond – what matters is whether the protocol has established itself as genuine infrastructure that outlives any particular implementation.

I want ATProto to become boring infrastructure. Not in the sense of being uninteresting – I find it genuinely fascinating – but in the sense of being so reliable and fundamental that people stop thinking about it. Like how most people don't think about TCP/IP or HTTP; they just expect the internet to work.

For that to happen, the protocol needs to prove its value independently of any single company. It needs to demonstrate that the architectural choices enable genuine portability, genuine sovereignty, genuine decentralisation. Not as theoretical possibilities, but as practical realities that users experience.

Why I'm Optimistic

Blacksky: Community-Governed Alternative

Despite my concerns and caveats, I'm actually fairly optimistic about where this is headed – not because of Bluesky PBC's leadership, but because of projects building alternatives within the ecosystem.

Blacksky is the most advanced alternative implementation so far, built in Rust and specifically prioritising community safety and self-governance for marginalised groups. Founded by Rudy Fraser, it emerged from the need to create space for Black users to "discuss the Black everyday in a way that feels affirming" and to "de-centre whiteness as the default" – exactly the kind of community-driven governance that Bluesky PBC seems to struggle with.

Northsky: Safer Spaces for LGBTQ+ Communities

Then there's Northsky, working to create a safer social media experience specifically for 2SLGBTQIA+ people. These aren't just theoretical alternatives; they're active projects with real communities, demonstrating that the protocol can support exactly the kind of diverse, community-governed spaces that the architecture promised.

The fact that these projects exist and are gaining traction is precisely why I don't care if Bluesky dies. The protocol works. The architecture enables exactly what it was designed to enable. Blacksky has raised over $50,000 in community funding and is building full PDS implementations, relay infrastructure, and custom moderation tools. Their GitHub repository shows active development on rsky, a full AT Protocol implementation in Rust that prioritises community safety over corporate growth targets.

This is decentralisation actually happening, not just theoretical possibility. When marginalised communities can build their own infrastructure with their own governance models, that's when the protocol's design shows its real value.

I've seen enough of the technical internals to know that the protocol is well-designed. I've built enough tooling to understand that the portability is real, not just theoretical. And now I'm watching community-led projects demonstrate that when you give people the actual tools for self-governance rather than top-down platform rules, they build something better.

Will there be challenges? Absolutely. Will every decision get made correctly? Probably not. But the fundamental architecture creates possibilities that simply don't exist with traditional platforms, and projects like Blacksky and Northsky are proving that those possibilities can become reality when the governance model prioritises community safety over corporate convenience.

The Takeaway

So when I say I don't really care if Bluesky dies, what I mean is that I care about the protocol succeeding more than any particular company – especially when that company is demonstrating concerning patterns in how it treats vulnerable communities. I want Bluesky PBC to improve, genuinely. But I want them to improve as one participant in a healthy ecosystem rather than as the indispensable linchpin everything depends upon.

The distinction matters because it shapes how we think about building on this infrastructure. If we're just recreating Twitter with extra steps – including Twitter's institutional problems around moderation and community safety – we've missed the point entirely. If we're building genuine protocols for social interaction that outlive any particular company's governance failures, we're onto something genuinely valuable.

The protocol deserves leadership that takes community concerns seriously, that understands the stakes for marginalised users, that has professional communications infrastructure rather than engineering-first responses to social

problems. Whether Bluesky PBC can become that leadership or whether the protocol needs to move to neutral governance is an open question. But watching their recent struggles, I'm increasingly convinced that separating protocol governance from platform operation isn't just theoretically important – it's practically necessary.

I'm investing my time and energy in the protocol vision, not blind loyalty to any particular implementation or company. The infrastructure, not the current stewards. That's what deserves to survive, and that's what I'm optimistic will actually matter in the long run – assuming we can separate the technical brilliance from the governance missteps before the latter damages the former's reputation irreparably.

After all, good infrastructure outlives the companies that built it, and sometimes it outlives those companies' ability to govern it well. The question is whether we recognise when it's time for that transition, or whether we let institutional loyalty prevent the protocol from reaching its full potential under better stewardship.