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!
Experimenting and playing with new systems is what I do for fun. I have no problem with funding other people to try some experiments. I have done this myself with some of the CoopCloud systems.. :D
The problem that I have with the ATProto protocol, is that it's created and controlled by a VC-funded company. I can see this becoming a federation-washing exercise on BSky's part. That's something I wouldn't be happy about taking part in.
We support the experiment. Our suggestion: define explicit success/failure criteria before the trial begins — not after. A time-bound, budget-constrained working group is the right scope, but without predetermined checkpoints, "reporting back" risks becoming open-ended. What would make this a clear success? What would trigger an early exit? Answering those questions upfront is what separates a governed experiment from a drift.
It's good to at least experiment within agreed limitations. I used to bridge but stopped due to its inherent frustrations. Then tried Wafrn which is just run on quite a low cost netcup host. As a solution to identity portability it's interesting. Fedisky is a recent solution for using a PDS with an activitypub connection. I cautiously wait to see what is explored.
Thanks for moving a proposal forward, Nathan. This seems workable in principle, but before agreeing to commit budget to this I'd need to know first:
1) who are the members of the working group
2) a preliminary budget estimate based on measurable goals (e.g., setting up a PDS) rather than an arbitrary budget scope
3) clear understanding about the tradeoffs in operational capacity wrt the tech working group (more in comment)
4) clear goals and conditions for success to frame report-back
The proposal lacks detail on what the goals of an experiment would be, where the budget will be allocated and what will be delivered. There isn't any definition on why this is beneficial for social.coop. Bluesky is brushed aside in some responses, while in others it is mentioned as the primary reason for running a PDS; this is unclear. I'm concerned this may help Bluesky to capture social value, rather than providing members with social value. Lastly, I think there is no harm in delaying.
@Games Commons
Bluesky is brushed aside in some responses, while in others it is mentioned as the primary reason for running a PDS
Which ones do you mean? I haven't seen any comments here that are in any way supportive of BS-the-company, nor even BS-the-AppView.
This proposal has moved on and a large number of other people agree with me that this should be blocked, so forgive me but I'm going to refrain from re-reading the comments or attempting to construct a clearer view on my reading.
@Games Commons
a large number of other people agree with me that this should be blocked
For the record, I'm not sure this is fair summary of anything said here either.
Supporting this, in the context of all the (sometimes clashing) points of view within these comments, at this date.
We also have had discussions (here https://www.loomio.com/d/skQB64Lb/ecosystems-and-instances-beyond-mastodon- and ongoing in TWG/OC) about the desire and effort to support experiments with more fediverse platforms (Bonfire, others suggested in that Dec 25 discussion). I appreciate the narrower framing of this as a time-limited experiment, and dependence on a specific-purpose Working Group. I'd like to see a broader confirmation too of approach to running and evaluating these experiments.
I would be in favor even at a higher budget. Experimentation with a different flavor of decentralization would be good for us.
Dipping the coop’s toes into the ATproto as a PDS seems like a low stakes way to see if it makes sense to be involved with the project in the long term. BS being VC owned is a huge red flag, but access to the larger community and new projects that are plugging in to the protocol sounds like a worthwhile experiment. It may also elevate social.coop as an example of a democratically run option for social media.
I would be happy to spend more on this than £500, given the potential upside for members. I also support the proposal as proposed.
While I tend to distrust Bluesky because of it's founding/founders and so will not participate personally in this experiment, I have no objections (I see no danger to our shared mission) and I like to see someone expanding the decentralization/ federation limits.
Something that gives me peace is that it is somewhat bounded, at least in money. It would help even more in this sense to define time and/or other criteria for limits/ sucess.
I can help with that in a short, sync session if it helps.:)
If there is a willing group, I support funding it. Not too late to have this included in 2026 budget (strategic / community contribution / other) which is still in draft.
Based on prior concerns raised.
Surely getting involved with Bluesky in any form is a mistake for the same reasons this community was against Threads. I support the Arab Center for Social Media Advancement's analysis of Mastodon versus Bluesky. Bluesky has a lot of problems, including advertisements, and has departed significantly from its initial vision. Is it really open? No. Instead, energy should be spend on making recommendations and improvements to Mastodon. Why are we going towards corporate-adjacent tech?
@chrispomeroyhale
Surely getting involved with Bluesky in any form is a mistake for the same reasons this community was against Threads.
Why? These are totally different cases, with almost nothing in common.
Mastodon versus Bluesky
... is not what this is about. Nobody is proposing to replace the social.coop Mastodon with an ATProto stack.
Bluesky has a lot of problems, including advertisements, and has departed significantly from its initial vision. Is it really open?
Great question! One way to answer that question would be to stand up some ATProto infrastructure and experiment with how independent it really is from BS. Experience-based reports on this published by social.coop could inform other co-ops in their decision-making about whether or not to engage with BS and their protocol.
Why are we going towards corporate-adjacent tech?
This seems like kind of a meaningless question. Many of the components that Mastodon and other fediverse servers depend on are "corporate-adjacent", including the Linux kernel. Surely the important criteria here is whether they are corporate-controlled? See above.
@Danyl Strype when you replied to (one) of my critical concerns with a debate-formatted argument, I saw that it would be a drain on my energy and I declined to address it. I observed that you are doing the same to this person's comments, and that some of the wording here is likely to require some effort to hear, e.g. "your question seems meaningless". I think that this thread, a vote which has already past, is the wrong place for you to sound off on this, and that you should remember that you're not entitled to emotional labour such as empathy and rhetoric from people on this thread. If you want to change our minds, it would be more interesting to read a well constructed article, addressing concerns generally and proposing your vision. You could post a link to this to the social.coop Loomio , and it would be less energy-draining for your readers. It's more likely to have the desired effect and it may reach a wider audience.
@Games Commons
when you replied to (one) of my critical concerns with a debate-formatted argument
My apologies, what's the correct way to format an argument?
some of the wording here is likely to require some effort to hear, e.g. "your question seems meaningless".
That's not what I said. What I said was;
This seems like kind of a meaningless question.
See the difference? My comment was focused on the question, your version is targeted at the person ("your question"). My comment was chatty in tone, with room for my being wrong ("seems like kind of"), your version is a much closer to a statement of fact (although the "seems" prevents it quite arriving there).
I think that this thread, a vote which has already past, is the wrong place for you to sound off on this
That's potentially quite hard to hear. But I'm choosing to interpret "sound off" as friendly banter, rather than the attempted humiliation it could be seen as, and your opinion is noted. This particular poll has closed, but the issue isn't going away. The place where questionable comments were made seems like an appropriate place to respond to me. YMMV.
If you want to change our minds, it would be more interesting to read a well constructed article, addressing concerns generally and proposing your vision.
Thanks for the suggestions. I've got a long backlog of things to blog about. Correcting BS/ ATProto misinformation (both pro and con) is one of them, but it's a fair way down the list. I've been commenting on this here because a decision was being made about it here, with implications for the future direction of social.coop.
I'd be interested to read the blog post if/when you share it.
Would prefer engagement with and experimentation with Bonfire, or generally with improving the new and regular user experience on ActivityPub protocols rather than starting to experiment with one part of AT protocol which, as far as i can tell, currently needs the whole stack.
@benjamin melançon
one part of AT protocol which, as far as i can tell, currently needs the whole stack.
It does, but it doesn't need the whole stack to be hosted by one entity. There are a range of non-BS Relays and AppViews people experimenting with a social.coop PDS could try.
Some very interesting discussion here.
I am not sure on my own position on using it at this point in time, but I don't see a reason to block a limited investigation.
Thank you all for expressing your opinions as text, reactions and votes!
Thank you so much @Nathan Schneider for starting the pulse check, I really appreciate it!
One update of note since this thread was initially posted: https://github.com/msonnb/fedisky exists and can add ActivityPub support to the PDS. This means the PDS would essentially be in the Fediverse instead of "only" in the "Atmosphere".
@Flancian
[FediSky] exists and can add ActivityPub support to the PDS. This means the PDS would essentially be in the Fediverse instead of "only" in the "Atmosphere".
TIL Wafrn supports ATProto as well as AP, so hosting an instance of that is another option for experimenting with ATProto infra. With the advantage of simultaneously offering an AP service with a totally different UX from Mastodon.
Registered my vote on @Nathan Schneider 's proposal—in addition to my skepticism of Bluesky, it seems important to consider what the trade-offs are in terms of tech working group capacity. I'm concerned about follow-through after watching it take years to implement the 1000-word character limit and then seeing our videoconferencing tool go kaput with no notice. I'd be hesitant to commit to any project within the scope of the TWG without assurances that it won't detract from ensuring that the basic operation of current functionality won't be impacted by TWG members working on this. Since nobody is being paid much, there's only so much "free time" to go around.
Also, I'd encourage folks who are enthusiastic and curious about this to go ahead and tinker as you see fit, I just don't think we're ready to commit to funding anything unless we know more about how it impacts other things.
Thanks for thinking of TWG capacity! This and any other experiments are gated on capacity of coop members indeed; I think the question is always 'are there enough people, time and resources' and 'do others mind if people use their free time for the coop in this way'.
About the 1k character limit: I agree it took quite long to implement but as I wrote in the relevant threads we tried doing the "right" thing even though it was slower. Note that the extra VPS we got to install alpha.social.coop **to test the change safely and without disruption to all cooperators** could now incidentally be reused for this PDS experiment.
I personally don't have an opinion on ATProto/PDS. We also have had discussions (here https://www.loomio.com/d/skQB64Lb/ecosystems-and-instances-beyond-mastodon- and ongoing in TWG/OC) about the desire and effort to support experiments with more fediverse platforms (Bonfire, others suggested in that Dec 25 discussion). There has been a mix of excitement in evaluating new platforms and hesitation over the capacity to:
install/maintain something new - the effort to e.g. configure SSO or determine/provision suitable VPS.
safely operate as an evaluation - what limits on signups, federation, moderation make sense, what (non-)promises are we making about data retention.
commit to offering to full membership access and support. how to handle expansions of TWG/CWG scope to these new platforms.
I'd be comfortable with either a PDS-specific WG or an Experiment-Tech WG to represent this addtional volunteer interest, but especially in a general policy from membership on what it means/takes for Social.Coop to operate services "experimentally" vs "fully supported".
That reminds me—what happened to the Bonfire experiment? I remain super curious about that and would be disappointed if this ATProto thing came at the expense of that
@alexrodriguez3 I'm all for exploring Bonfire as well!
@Alex Rodriguez
what happened to the Bonfire experiment?
@Nathan Schneider
@Danyl Strype yes I see that and have tried to set up an account but still no dice
@Dan Phiffer helped me get one set up. Dan, can you help @Alex Rodriguez with this?
Would you like to explore ATproto together?
proposal by Nathan Schneider Closed Fri 17 Apr 2026 10:01PM
I've started a private thread with the people who expressed interest in advancing this idea.
Based on previous discussions in this thread, I propose that an unfunded affinity group form to explore the possibilities of ATproto infrastructure, potentially resulting in a well-developed future proposal to Social.coop. I volunteer to organize a first meeting of people who express interest.
If you would like to join, put a thumbs up and your handle below.
For more context on AT Protocol see here: https://en.wikipedia.org/wiki/AT_Protocol
Results
| Results | Option | Votes | % of votes cast | % of eligible voters | |
|---|---|---|---|---|---|
| I'd like to join! | 6 | 19 | 1 |     | |
| Glad it's happening | 21 | 68 | 4 |                 | |
| Objection | 4 | 13 | 1 |    | |
| Not voted | 446 | 94 |  .jpg){kind=small}             |
@sarttiso
@mako
We're interested in seeing where it goes and curious about following the process. We wish you success!
I like a lot of things about AT and Bluesky.
@emsquared
@kalebpace
Having setup a personal PDS recently, would love to help.
My personal con for the protocol: Various ATProto applications do not label clearly which data they store in a globally readable PDS, and which data they store on their own servers outside of the PDS affecting portability. So there's some opaqueness to users that may mislead them to "leak" data into something like https://pds.ls or believe all data on a platform can be migrated via the proto when it cannot.
I'd love to join, thank you for getting this going Nathan! 🙏 I'm @flancian@social.coop in the Mastodon instance, @flancian:matrix.org in Matrix.
There are climate scientists and activists I'd like to connect with who ended up adopting Bluesky rather than a Fediverse client. I'd like to be able to follow them directly one day; only a few have federated using Bridgyfed.
Don't see any reason to block this as a first step.
Generally supportive of this low risk approach to explore if this is a good idea.
Not sure i'd raise it to the level of an objection, but i wish experimenting with ATproto were not happening and that effort went toward other things.
@benjamin melançon Yeah. I wish there was a voting option to capture the sentiment "I see this proposal, kinda think it's a waste of time and I don't want to have anything to do with it, but you do you."
@benjamin melançon
i wish experimenting with ATproto were not happening and that effort went toward other things.
This kind of assumes that effort belongs to the co-op and can be deployed by democratic mandate. But the effort involved is being volunteered, specifically for this purpose, so it's not fungible and repurposable in that way. It would be fair comment when it comes to any co-op money spent on a PDS hosting experiment, but that's not part of this proposal.
@Danyl Strype As you said here:
https://www.loomio.com/d/skQB64Lb/ecosystems-and-instances-beyond-mastodon-/46
"
The most important thing I've come to understand in all my years of testing is that choosing software is not like choosing a tool from the garden shed. A piece of software is nothing like a fixed object in space. It evolves over time, and the direction and pace of its evolution are just as important in choosing software as its current state with any given release.
Choosing software is more like choosing which suppliers to get your electricity and internet connections from. Issues like governance, economic sustainability and value alignment are just as important as the quality of the supply.
"
These are the exact reasons why working with ATProto is not a good idea.
The governance, sustainability, and value alignment of the protocol creators are not aligned with what we are doing here.
It's a Fedi-washing of a VC-funded proprietary protocol, that was originally designed to lock out the smaller independent groups.
@Emsquared yes! I found Fedisky this week after posting the thread, I agree it looks very interesting: https://github.com/msonnb/fedisky