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!

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

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 😅)

@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.

@Tim Thanks for the update from the conference.  "Remains to be seen, however, if that comes to pass." Then, it seems that "when it comes to pass" would be the time to consider this. Until then, I would prefer social.coop not pursue this.

@yamantaka thank you

@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.

@sarttiso Thank you, that's all super useful

"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."

I had a BSky invite and didn't bother.

It's just another VC-funded platform where the sell-out has already taken place, but the public and the users do not know about it yet.

Be welcoming to the users that want to jump ship, yes, but bridging to an exploitative platform, no.

The ATProto protocol is only as decentralised as BSky allows, and if the funders decide that it is not profitable, then they will shut the protocol down at the drop of a hat.

Add in that the Department of Homeland Security, and the ICE both have accounts there, and we should not enable them in any way whatsoever.

Hi all, my interest from the beginning is with a plurilingual means for (I'll risk calling them "good") people to communicate within the condition of language difference.

No idea if this suggestion is a place where language type/preference(s) could be stored as part of an opensource automated translation system?

Happy to read/learn that Mastodon is experimenting with Bonfire and I do understand not wanting to endorse Bluesky but/and it also seems that the more integration exists in the open Fediverse then the most robust it becomes.

non-tech perspective from a social science action researcher ;)

best regards,

steph

This conversation is very confusing, and I think the framing is incorrect. I don't think we should create a Bluesky PDS. I think we absolutely should create an ATProto PDS. That will be useful for Bluesky users, for sure. But for other things as well.

ATProto is a protocol, and there is a range of projects and products running on top of it. Bluesky is a company and a product. It's the big use of ATProto, clearly, but it's not the only one. It's also not the one I'm most personally interested in.

@Benjamin Mako Hill I agree, thanks! If I run a poll later I would fix that. I thought of using Atproto in the title before posting but went with Bluesky thinking more people would recognize the term maybe. But I agree it's confusing.

@Flancian I think most of the reactions here are to the idea of us doing something that would support or build a strong relationship with a VC-backed company and its product. I understand and agree with the opposition to doing that. I truly don't believe that hosting a PDS necessarily does that, and I think any more formal proposal needs to make this clear.

@Flancian 

I thought of using Atproto in the title before posting but went with Bluesky thinking more people would recognize the term

Indeed they did, but not in a way that helped them understand your proposal. Taking into account @Benjamin Mako Hill 's points, I would change the title of this discussion to read;

Would Social.coop want to experiment with running a Personal Data Store for ATProto (the protocol developed by Bluesky)?

Benjamin makes a necessary distinction — and we agree with it technically. ATProto is a protocol. Bluesky is a company. These are not the same thing, and conflating them weakens the analysis.

But the distinction, while real, is not as clean as it appears in practice.

The GNU/Linux parallel is instructive precisely because of what made it work: AT&T did not control the kernel. The protocol was genuinely separable from its corporate origin because no single actor held the chokepoints. With ATProto, the situation is structurally different. Bluesky PBC currently operates the primary relay, shapes the default discovery algorithm, and sets moderation policy for the dominant client. The protocol may be open — the infrastructure that makes it functional at scale is not.

This doesn't make the experiment worthless. It makes the conditions of the experiment decisive.

Running a social.coop PDS on ATProto is interesting if — and only if — we enter with explicit criteria: What does success look like? What does capture look like? And critically, what is the exit strategy if Bluesky PBC exercises the leverage it structurally holds?

We're not arguing for reflexive rejection. We're arguing against uncritical adoption dressed up as pragmatism.

The protocol doesn't redeem the infrastructure. The governance does — or doesn't.

— Colectivo Desalienación

@Colectivo Desalienación I think we agree at a high-level here. We might disagree with our overall assessment of the protocol's value at the moment, but that doesn't seem like a deal-breaker.

For those who are less familiar with how Bluesky is implemented: This proposal is similar to a proposal to run a website in a world where there is only one large corporate search engine that nearly everybody uses to discover things. Doing so yields immediate benefits (e.g., resistance to the strongest forms of censorship). And indeed, I do think there is value to the cooperative hosting websites in such a world, even if it means we are, in very meaningful ways, affected by the decision of the big, powerful compan(ies) in our ecosystems. I think this is similar to hosting websites in the world we actually live in—i.e., where most people find content on websites via Google. Self-hosting is the first step on a long journey toward building more autonomous systems.

Running a Fediverse instance is more akin to running an email server. You can build more autonomy with fewer resources, for sure, but there is a range of important trade-offs, and certain things (like search across the whole network) are basically impossible without enormous resources.

I think both experiments are important, and I think taking steps to build self-hosting in either ecosystem is important for that reason.

I think this sounds interesting but, like a lot of proposals on here, I worry that I don't know enough to judge whether it is a good idea or not. This should probably be a separate discussion, but I wonder if we might do more member education about the fediverse, decentralized social media, different protocols, etc. (And if so, that is an effort I'd be interested in helping out with.)

I agree with all the concerns about BlueSky, which has clearly been captured by Venture Capitalists. Jay Graeber - a notable decentralisation advocate before BS existed - has already been sidelined. Clearly there were compromises they was not willing to make as CEO (press releases claim they "stepped down" but I suspect that was jumping to avoid being pushed). The company is clearly moving into the 'be evil after all' phase that Goggle did, when they centralised all services under One Ring (Goggle+ accounts), stopped allowing engineers 20% time and killed all the decentralisation projects it produced (Reader, GChat, Wave, etc).

I also agree with the concerns about ATProto as a protocol. This not an architecture that lends itself to community autonomy. The technical and political-economic analyses by Christine Webber (ActivityPub editor and Spritely founder), while lengthy, are worth reading in full.

Having given those caveats, I think @Flancian 's experiment is worth running, at least for a trial period. A few things to consider;

• As @Adrian points out, it will be very cheap

• While the total audience using BlueSky and other ATProto infrastructure remains many orders of magnitude larger than the fediverse, I think it's worth being able to communicate with them, using native but community-hosted infrastructure. Even if our only reason for wanting to do that is to convince them to come back to the fediverse 😁

• I'd like to see the fediverse move towards an approach where our data (including our posts) is stored independently of the fediverse service where we have our accounts (see ActivityPods), and we can BYOD (Bring Your Own Domain) to those services (Takahē proved this is possible). In that scenario, a Solid pod as used by ActivityPods could also be an ATProto PDS, could also be an identity and set of posts on Nostr, etc.

@Danyl Strype The analysis by Christine is truly excellent; I'd seen it before but hadn't read through the whole thing, so it was great to encounter it again and actually finish it.

I also agree with the goal brought up by many of the comments here for having a decentralized federated platform that allows for transferability of personal data. As Christine's analysis points out, however, this transferability is only meaningful if the platform is actually decentralized, which means that all aspects of the service are easily self-hostable.

Hosting a personal data store (even if it is cheap) does not achieve meaningful decentralization. If we're going to seriously engage with atproto, I think we have to be thinking about hosting the whole stack. Otherwise, we simply contribute to the centralization of atproto.

But as I've tried to argue in my comments, and as Christine does wonderfully in that post, atproto simply doesn't scale well. I fear that trying to host everything will become prohibitively expensive if the usership of atproto actually grows. Is it responsible to plant the seeds of something that is doomed to fail? Just because something is easy and cheap now doesn't mean we should do it.

Moreover, there's an ideological dimension: when engaging with atproto, whose development is effectively monopolized by VC-funded, profit-seeking Bluesky, we have to be clear-eyed about our justifications and goals. The main justification I've seen is "data portability," which is certainly worthwhile. However, for all the reasons above, I don't think atproto actually ends up offering a viable, scalable solution for this goal: even if personal data stores provide modular, transferable data containers, the rest of the stack is anemic to decentralization, rendering the data portability useless.

I'd like to see the fediverse move towards an approach where our data (including our posts) is stored independently of the fediverse service where we have our accounts

I strongly agree with this desire, but hosting a personal data store does not move us closer to this goal. I personally need stronger justification for dedicating coop money and energy towards engagement with atproto, and I just don't think that vision is clear at this point.

@Adrian Christine Lemmer-Weber's essays are excellent in the way they describe the differences between ATProto and ActivityPub. I've taught it in university classes. That said, I think it's taking an extremely strong position in favor of a particular technology (that Christine helped design!) in ways that I think discount the benefits of other approaches. I 100% think CLW is arguing in good faith, but I also think she simply doesn't value the thing that the competing system does well.

ActivityPub makes things like a global view of the network difficult, maybe even impossible within the system. CLW seems not to think this is a problem. This is, in part, why they designed the system the way that they did. ATProto's designers think a global view is valuable and have designed their system to support it. It's hard to do without consolidating power.

I think the analogy to the web is truly a good one here. ActivityPub is like email. ATProto is like the web.

I don't love that access to the web is so strongly controlled by a small number of search giants. I also don't love that building a search engine is enormously capital-intensive and the exclusive domain of giant tech companies. But I absolutely think that the open web is valuable, that self-hosting websites on the web is a real marginal improvement over letting Google do it on the web in its current form, and that the ability to search the web easily is extremely valuable. I do it hundreds of times a day. I wish there were more resources (technical, computational, and human) put into building alternative, noncorporate, autonomy-respecting search engines.

I use Bluesky, but not very actively. There are a range of new non-social media systems being built on ATProto that can be hosted in a PDS and that don't rely on the Bluesky relay at all. Some don't rely on centralized relays at all. Perhaps because it works like the web, ATProto seems to me to be a more exciting space for innovation than ActivityPub. That's what I would love social.coop to support.

Benjamin, Danyl — this exchange is exactly the kind of conversation worth having carefully.

Benjamin's Google analogy is honest and we don't dismiss it. Yes, running a website in a Google-dominated world still has value. Self-hosting is a real step. But notice what the analogy also reveals: after decades of "first steps," Google still controls discovery at scale. The first step becomes permanent infrastructure when there's no second step defined. That's the governance question we keep returning to — not whether to experiment, but whether the experiment has an architecture for its own success or failure.

Danyl names what we think is the actual horizon: ActivityPods, Solid pods, BYOD identity across protocols. A world where your data exists independently of any single service — whether that's a Mastodon instance, a Bluesky PDS, or anything else. That's not a compromise between the fediverse and ATProto. That's transcending the binary entirely.

Si ese es el destino — and we think it should be — then the question for social.coop is whether running an ATProto PDS moves us toward that architecture or normalizes a detour.

We don't have a definitive answer. But we think that question needs to be on the table before the experiment begins, not after it becomes load-bearing infrastructure.

The Christine Webber analyses are essential reading for anyone making this decision. We'd add: so is asking what social.coop's exit looks like if Bluesky PBC decides the relay isn't free anymore.

— Colectivo Desalienación

Like CLW, I have a lot to say on ActivityPub vs. ATProto, and a strong bias, so I'll do my best to restrain myself from over-contributing here. But I really appreciate the thoughtful replies from @Adrian , @Benjamin Mako Hill and @Colectivo Desalienación , and I'd like to offer a couple of clarifications and responses before I shut up and listen for a while;

@Adrian

Hosting a personal data store (even if it is cheap) does not achieve meaningful decentralization.

Agreed, but I don't think that's the goal of this experiment. What I think it would achieve is providing social.coop members with;

1) a way to move the data storage of their existing ATProto usage inside the co-op infrastructure

2) a way to communicate with people who use BS (and other ATProto infra) without having bsky.social in their username. Thus reducing any perceived endorsement of BS-the-company, not increasing it.

3) a way to test how useful a PDS can be without using any infra controlled by BS. By using social.coop PDS to experimenting with Relays, AppViews, etc, run by other entities (BlackSky, etc), and especially any that can use PDS data without using a Relay at all, as @Benjamin Mako Hill mentions.

Me:

I'd like to see the fediverse move towards an approach where our data (including our posts) is stored independently

@Adrian

hosting a personal data store does not move us closer to this goal.

Not by itself, no. Fair point. But what I'd propose is an experiment with hosting both ATProto PDS and ActivityPods. One that includes engaging with ActivityPods devs and the Solid community, to see if the former can be merged into the latter. Then further down the line, engaging with the Bonfire devs to see whether the ActivityPods infra could be used as the data store for a social.coop Bonfire instance. Ideally with Takahē-style BYOD support, so social.coop could become an infrastructure provider, hosting accounts for co-ops under their own domain names, without the massive overhead of running multiple Mastodon instances. This kind of experimentation might well move us towards our shared goal.

IMHO @Colectivo Desalienación absolutely hits it out of the park here;

That's not a compromise between the AP and ATProto. That's transcending the binary entirely.

But please note the small tweak I made to this quote; replacing "fediverse" with "AP". As I understand it, the fediverse is not a network of atomised individuals, defined by the protocol used. It's a network of communities, defined by an agreement to federate using a common protocol. It existed before AP, and it's fate is not tied to that of AP (certainly not AP in its current, larval form).

@Benjamin Mako Hill

I think the analogy to the web is truly a good one here.

Indeed, and in this analogy, BS is Goggle. But, as CLW's points out in their first piece on ATProto;

"Bluesky's developers have described Bluesky as being a bunch of blogs aggregated by Bluesky as a search engine ... this isn't really true ..." (emphasis mine)

The reason it's not true, is that although Goggle has inserted itself as an intermediary in the web in various ways, using Goggle Search and its control over Android/Linux, a blog piece on an independent website can still be browsed without touching any part of Goggle or any search engine infra. Eg by clicking a link to it somewhere else online, or typing the URL into a browser. A blog piece in a PDS cannot be browsed without a Relay - at least as ATProto is designed to work - which makes it analogous to a website that cannot be browsed except via a search engine.

This is key to understanding the limitations of ATProto as an attempt at a decentralisation protocol.

ActivityPub makes things like a global view of the network difficult, maybe even impossible within the system. CLW seems not to think this is a problem ...ATProto's designers think a global view is valuable and have designed their system to support it. It's hard to do without consolidating power.

As I read it, CLW's posits that a global view is impossible without consolidation of power, and I agree. From a social analysis POV, I'd posit that the attempt to force a global social view on the decentralised transport medium of the net is the original sin of social media. The root cause of most of its socially negative outcomes, including (but not limited to) the global political-economic centralisation of control over online social life.

So a local-first view is not only the right design for a decentralised social network protocol from a technical POV, it's also the right design for a social network infrastructure that serves the social needs of humans, rather than actively harming us (by nudging us towards greater polarisation, mis/disinformation, violence, genocide, etc).

By trying to provide a global view of a decentralised social network, BS's design is attempting to make dry water. This contradiction must be resolved. Either by drifting towards dryness - further centralisation around the Relay design - or towards wateriness - moving away from the Relay design to become something more like Nostr. Given the political-economic structure, incentives and financial dependencies of the BS company, and the way it's already sidelining its pro-decentralisation staff, like Graeber, it seems pretty obvious to me which direction BS-the-company will drift in.

But that won't stop Graeber, the ex-SSB devs, and others who are working at BS for the decentralisation not the money, from forking the protocol and iterating in a more decentralised (and therefore less global-view) direction. Carefully considered engagement with ATProto by communities like social.coop could encourage them in that direction, perhaps even being lifeboats for them to jump into when life at BS becomes untenable (and it will).

@Danyl Strype @Benjamin Mako Hill I'm learning a lot from this exchange! Thanks for your thoughtful responses. I am intrigued by the potential use cases for a PDS outside of those mediated by externally hosted relays, but I have to learn more about them.

It's been interesting to recognize some of the assumptions I've held without realizing with respect to communication technologies: for instance, I am also fine with platforms that are incapable of efficiently assembling a global view of a network.

If atproto governance can meaningfully distance itself from Bluesky, and if the technology improves in a way that mitigates some of the scaling issues (which it has with the updated relay code), then I'd be more open to it. I remain skeptical, but I appreciate the nuance that this conversation has contributed. Time will tell I suppose!

What a magethread! I'm grateful to @flancian for raising this. I've also raised the question a bit in the community over the years. To me this is an easy yes, and it doesn't depend on whether Bluesky or ATProto are perfect or ideal. The calculation to me is:

• More cooperative infrastructure is good
• Many people here can't rely only on the fediverse for social because our friends aren't here (in my case many came and left)
• ATProto makes it possible to have meaningful cooperative control (cf Blacksky if you need evidence)

Taken together, I think Social.coop can deepen its mission by creating more cooperative infrastructure on ATProto. We are Social.coop, not Mastodon.coop. I think with that branding we have a bit of a responsibility to support cooperation in social media wherever possible. I also can't help but think this would attract a larger member base and more than pay for itself.

Keep in mind that this proposal is not "do you want to use Social.coop for ATProto?" but "would you be open to anyone in the co-op experimenting with this and reporting back?"

I will start a proposal.

@Sam Whited As discussed above, this has intentionally been reframed to avoid focusing on Bluesky. Among other uses, I am interested in using a cooperatively maintained PDS to engage with ATProto services including Leaflet, WhiteWind, and Smoke Signal—all of which, AFAIK, have zero VC involvement.

I'm also a little confused about which of our values you think this compromises. I can not find anything in our stated values that is compromised or threatened by any part of this proposal. And indeed, this seems very much in the spirit of things we say we're here to do (e.g., "members can be part of experiments with new social media platforms and tools").

@Adrian My guess is that running a PDS should cost less than £500. Blacksky's costs are almost certainly much higher, but as I understand it, this is because they are doing much, much, more than running a PDS and much, much, more than any experiments we ran would involve.

@Benjamin Mako Hill a PDS is definitely cheaper than £500 / 6 months; sorry I was unclear. I was responding to the language of the proposal

experiment with building ATProto infrastructure

which I interpreted to mean more components than just the PDS (relay, app view, feed generators, etc), whose operation likely exceeds £500 / 6 months. I think deploying the full stack is an important aspect of social.coop's decision to participate in ATproto because true decentralization matters to me. I'd be interested in doing some of this research.

Alternatively, I'm also open to a proposal focused on just a PDS, but I'd like more clarity and specificity about what sorts of atproto platforms other than Bluesky a social.coop PDS would contribute to/participate in, and why there wouldn't be a need to host more of the stack for those platforms.

@Adrian Decentralization certainly matters to me too! It's just that I'm personally most interested in non-microblogging/Bluesky. There are cool things to explore the cooperative management of in the much less resource-intensive parts of the ATmosphere. To be clear, I'd love to follow through on your more ambitious proposal! That said, what I like about Nathan's proposal is that it let's us try to walk before we commit to running.

@Adrian A few points.

1) As I understand it, a social.coop PDS could be used with AppViews other than BS, using Relays operated by non-BS entities (maybe BlackSky?).

2) Apps like Miscord-replacement Roomy are making various creative uses of ATProto infrastructure, in ways totally independent of BS.

3) Since we know that hosting a full ATProto stack is much more expensive and complicated, a PDS hosting trial seems like a good scope for an initial experiment. Both @Flancian's proposal and @Nathan Schneider's sense check suggest an experiment that's time-limited. I'd add to that a need for clear guidelines on reporting results, before the the trial ends, to guide decision-making on its future. Together, I think these conditions address the valid concerns you have about social.coop resources being used indefinitely to host infrastructure that mainly benefits BS.