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!