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!
KévinThu 2 Apr 2026 9:23PM
I'm very much in the camp of two things can be right at the same time, BlueSky is a VC shitshow waiting to explode that uses PDS to offset their AWS bill on everybody else and that it would be a good idea to consider this, because there will always be people stuck in the platform lock-in for one reason or another.
In the end PDS at BlueSky or PDS elsewhere doesn't really matter in the grand scheme of things since BlueSky can centrally wipe you off using moderation and indexing, it won't fix the BlueSky issue, however, I think it's a good move to at least try to offer something out there to mitigate while giving people a little more control of their data. Similar to the BlackSky and NorthSky projects
Danny GarsideThu 2 Apr 2026 10:18PM
Mainly what @Justin du Coeur said, but I'm also curious about what @Adrian said:
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.
Can someone techy please tell me whether there really is a path for ATproto to become a widely-used protocol for decentralized communication, or is that fundamentally not a go-er? Note that I specifically said ATproto and not Bluesky (I assume that's not an option because of the influence of the VC funding).
@Flancian - what's the ballpark of how much it would cost social.coop to run a PDS? If negligible - I support it (unless it could be seen as signaling support for Bluesky), if expensive then we'd need to think more about whether it's worth the cost. (I know you said you'd follow up with resource estimates but I really don't know if this is a €5 experiment or a €50000 experiment 😅)
TimThu 2 Apr 2026 11:24PM
@Danny Garside In theory, yes, ATProto could become a decentralized communication protocol, and there was an entire conference about it just last week in Vancouver (ATmosphere) at which folks were discussing all of the issues surfaced within this thread. Remains to be seen, however, if that comes to pass. I'm not sure I agree that support of ATProto is by default endorsement of Bluesky, but I'm equally wary and distrusting of the folks behind Bluesky itself.
AdrianFri 3 Apr 2026 12:53AM
@Danny Garside I'll let @Flancian speak to their vision about deploying the PDS, but from my experience, it is easy and cheap (I've deployed it for personal use). I imagine for social.coop scale it would be <$20/month.
With a recent update, it has also become much cheaper to run a relay (at least at the current size of the Bluesky network); it use to require several TB of storage, but now it's well under 1 TB (see this blog post). Nevertheless, it's still not cheap to run a relay (probably at least $50/month; $34 as quoted in the blog post seems unrealistically low to me). This number scales with the volume of the network, not the "instance". So, if bluesky traffic gets bigger by 100-fold (to match current size of X/Threads), prices will increase by "a lot" too (although I'm not sure what the exact scaling would be).
A major challenge is running the App View, which digests the firehose of information streamed through the relay. I'm not very familiar with implementations of this; Bluesky doesn't offer a streamlined community implementation of their AppView in the same way that anybody can easily spin up a mastodon server from the default docker-compose. This implementation (based on this one) suggests a 128GB, 32 core machine, which would be several hundred dollars per month. This implementation seems lighter, but I'm not sure what the tradeoffs are. Blacksky has its own implementation of atproto; the part of their "App View" stack that processes the firehose into an indexed database recommends pretty beefy hardware (32+ GB, 8+ CPUs). Together with the relay and PDS, it's at least on the order of $100-200/month or more, and not trivial to deploy.
These costs reflect the traffic at the current size of the bluesky network, which is a tiny fraction of X/Threads. If the Bluesky actually manages to grow to comparable scale, these costs would presumably increase significantly with the expanded user base. And while the scaling might be mitigated for a cleverly-configured App View, I don't think the scaling can be avoided on the relay side.
For this reason, it's not clear to me how atproto can actually become decentralized; it just doesn't scale in an economical way if you want to host the full stack (which is what decentralization means to me). Perhaps I'm misinformed or I misunderstand the technology, and if so I would welcome corrections!
And again, all the data is hoovered up by bluesky (and probably many, many other entities) regardless of which personal data store is used. Having a selfhosted personal data store contributes nothing in terms of "data sovereignty" given the complete openness of all communication over atproto.
Colectivo DesalienaciónThu 2 Apr 2026 11:54PM
"From Colectivo Desalienación — we think this conversation reveals a tension worth naming clearly: ATProto's architecture genuinely advances data portability and decoupling identity from corporate hosts, which aligns with digital sovereignty principles. But the protocol doesn't exist in a vacuum — it was built by a VC-backed company and the governance layer remains opaque.
Running a cooperative PDS is interesting precisely because it tests whether the infrastructure can be reclaimed from its origins — similar to how GNU/Linux reclaimed Unix. But that experiment only makes sense if social.coop enters with clear criteria for what success and failure look like, and an explicit exit strategy if Bluesky PBC exercises capture.
We'd support a time-bounded experiment with defined governance checkpoints over either uncritical adoption or reflexive rejection."
Jonobie Ford ·Thu 2 Apr 2026 8:18PM
I'm pretty aligned with @Justin du Coeur's response - I don't particularly want to get entwined with Bluesky, but I do think this is an interesting idea and one I'd be down for us to explore as a co-op. I'm not super on Bluesky, but I would love to carry the co-op identity there too.
Thanks for writing this up so thoughtfully!