Would Social.coop want to experiment with running a Bluesky PDS?
Hi, all! Eduardo from the Tech Working Group here, but posting on my personal capacity. I wanted to gauge community interest informally on a possibility, with the potential of running an actual proposal later if there's enough appetite.
As you might know, Bluesky is built on a protocol called AT Protocol (ATProto), which is distinct from, but increasingly interconnected with, our ActivityPub/Mastodon world. I'd like to explore whether Social.coop might want to run a Personal Data Server (PDS) as a cooperative experiment.
What is a PDS?
In the ATProto architecture, a PDS is the component that stores your identity and data. It holds your posts, follows, and other records, and it's what lets you participate in the wider ATProto network (including users on Bluesky, Blacksky and other apps).
A PDS is intentionally minimal. It doesn't run its own timeline, discovery, or algorithms. Those live at higher layers of the stack (relays, app views, feed generators). Of course we would need to size these if this proposal moves forward and before it is approved, and we could time bound the experiment as needed.
Users on a PDS can use any ATProto-compatible client (not just Bluesky's app), and they can migrate their account and data to a different PDS at any time, taking their identity, social graph, and content with them. This is a fundamentally different model from Mastodon, where migrating posts between instances remains unsupported.
Why might this be interesting for Social.coop?
A few reasons that feel relevant to our values:
Data sovereignty and portability: One of the strongest properties of ATProto is that your identity is decoupled from your host. A cooperatively-run PDS gives our members ATProto presence under community stewardship, rather than under Bluesky PBC (a VC-backed company). Interested people could get an address like @flancian.social.coop this way, and also have the option to migrate all their data to a different PDS later on if they wish.
The commons case: Free Our Feeds (https://freeourfeeds.com/vision), a public interest initiative working on independent ATProto infrastructure, frames the protocol as enabling "a kind of data commons: apps can share infrastructure, while users can change applications and keep their identities, their social networks, and their data." The IndieSky working group (https://atprotocol.dev/indiesky-working-group-50k-donation-from-free-our-feeds/) is specifically focused on helping communities like ours run parts of the ATProto stack for community benefit rather than corporate capture. This feels aligned with social.coop's mission, which is why I'm bringing up this question to you today.
Low stakes, good learning: A PDS does not commit us to running the full ATProto stack, building feeds, or moderating an entirely new community. It seems promising as a well-scoped experiment. There are now more than a thousand independent PDS servers (https://atproto.wiki/en/wiki/reference/core-architecture/pds) in the network that people could migrate their data if we choose to not run one indefinitely. The reference implementation has a straightforward installer and an active community.
What this would and wouldn't be
This would not be about Social.coop endorsing Bluesky the company or encouraging members to abandon the Fediverse. It would be about Social.coop offering members who want an ATProto identity a place to host it under cooperative governance, as an optional additional service -- similar to how we are experimenting with Bonfire alongside Mastodon.
It would also be an opportunity to participate in an emerging ecosystem of commons-oriented ATProto infrastructure, connect with the IndieSky and Free Our Feeds communities, and learn together as a coop whether this kind of multi-protocol presence makes sense for us long-term.
Questions I'd love to hear your thoughts on
Is there interest among members in having a Social.coop-hosted ATProto identity?
Are there concerns about ATProto or Bluesky PBC's role that feel like blockers vs. things we'd want to watch carefully?
Would anyone want to be involved in a small working group to investigate feasibility?
If there's enough interest here, I'd discuss results and possibilities with the TWG and the CWG and then follow up with a more formal proposal including technical details, resource estimates, and a framework for how the experiment could be run.
Thanks for reading — curious what people think!
Sam WhitedThu 2 Apr 2026 5:47PM
We should absolutely avoid this. Bluesky, ATProto, and the people who make and own it are antithetical to the cooperative values. This is a co-op that was formed around the fediverse and we don't need to be getting in bed with billionaires just because they made some shiny new technology that we want to play with. We can't run a node without endorsing Bluesky the company or the people who make it, it's as simple as that.
Games CommonsThu 2 Apr 2026 6:17PM
Bluesky exists to capture social value and sell it. I understand that people would want to reach a different audience, but personally I think a greater separation from Bluesky is a good thing and my preference would be to block interoperability with Bluesky in general. I think that reposting to a Bluesky account is sufficient to address the audience there, if it's desired.
I appreciate the time you took to write up this post and the consideration of the pros and cons of using the ATProto. From what you've said though I'm not really able to understand why you are passionate about supporting ATProto as an alternative to ActivityPub. Is your objective here to migrate users away from Bluesky? What are the reasons for attaching this effort to social.coop?
drewmcaThu 2 Apr 2026 6:18PM
I’d personally love this, especially combined with bridgyFed’s efforts to make data accessible across networks.
There is a lot of alignment between folks interested in ATproto and cooperatives, too: https://bsky.app/profile/jluther.net/post/3micvh6wlk222
Ray GulickThu 2 Apr 2026 6:34PM
Zero interest in pursuing this.
AdrianThu 2 Apr 2026 6:56PM
I also oppose any efforts to engage with Bluesky at this point. Their governance and funding structure is problematic, and it's not really reasonable to expect decentralization from the atproto architecture. The ability to host personal data stores is a red herring when the underlying architecture requires assimilation of the entire network feed through a relay. There is no privacy in atproto/bluesky, nor is there any semblance of an ecosystem of "instances" due to the prohibitive technical costs of running the full atproto stack — again, due to the architectural decision that fundamentally imposes centralization of feeds across the entire network. It's worth noting that these costs will only go up with increasing usage of Bluesky, which is still nowhere near X or Threads, further limiting the capacity for federation to well-funded communities.
So there is no real benefit to having personal data stores, because there's nowhere meaningful to take them (i.e., the higher levels of the tech stack are overwhelmingly dominated by bluesky), and the data is available to everybody through the relay anyway. Unlike mastodon, where you have the choice of moving to another instance (because other instances actually exist), and accounts can be private.
Justin du CoeurThu 2 Apr 2026 7:16PM
Somewhat mixed feelings. I'm skeptical about ATProto per se, but extremely interested in the PDS idea in and of itself.
This is currently a big gap in the fediverse ecosystem, AFAICT. Identity should be decoupled from your messaging provider -- this is an area where Bluesky seems to be doing it right and Mastodon is not. Personally, I think it's an embarrassment that the open-source community is focused on an architecture that is less open than the VC-backed one.
I haven't dug into the PDS technology enough to have strong opinions about whether it's worth kicking the tires on this specific implementation of the idea; IMO it largely depends on how separable it is from Bluesky per se. But if:
The PDS implementation is potentially severable from ATProto per se;
It's truly open-source;
There are folks enthusiastic about playing with this.
Then IMO it might be interesting to experiment with that, to understand whether and how it could be adapted to the Fediverse.
To be clear: I don't think we should be getting in bed with Bluesky or ATProto. But IMO we should totally be open to looking at their code and architecture, especially where it works better than Mastodon does, with an eye towards whether it would be possible to improve the Fediverse by adapting some of those ideas.
SievaThu 2 Apr 2026 7:31PM
I'd be very interested in that. I currently use brid.gy, it is not ideal.
Denman RookeThu 2 Apr 2026 7:36PM
I personally use Bluesky a lot. And while I also enjoy Mastodon there are connections on Bluesky I don't have here. So I'm interested in having a PDS version. But if others here don't want it, I don't mind I can continue my Bluesky use separately from social.coop.
AlexanderThu 2 Apr 2026 7:59PM
I'd be interested in exploring this. Whilst I have serious reservations about Bluesky as a company, it is a large network which I do find myself referring to for information. Would be nice to be able to do so through the co-op, even if there are practical limits to sovereignty from the main Bsky infrastructure under the AT Protocol.
Kris Warner ·Thu 2 Apr 2026 5:29PM
I'm not interested in the AT Protocol because 1) I feel like BlueSky is just another VC-funded tech company that will do a rug-pull 2) BlueSky has touted its use of AI and 3) I don't pay close enough attention but it seems centralized while talking platitudes about decentralization.