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

@Sam Whited 

I feel very strongly that investing our time and money into VC backed platforms is not a good use of co-op resources.

100% agree. But that's explicitly not what's being proposed here. As @Benjamin Mako Hill points out elsewhere in the thread ATProto is being standardised by the IETF, and co-ops hosting ATProto infrastructure are creating an alternative to using the infrastructure provided by Venture Capital backed companies. Just as running the social.coop Mastodon instance provides an alternative to Threads, FlipBoard and other corporate platforms implementing AP.

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

+1 to 500 being too much/not needed; we could run a PDS in one of the VPS the TWG already has. There is one which we have paid until the end of 2026 that gets little use day to day as it only hosts alpha.social.coop currently (our staging environment for the Mastodon instance).

@Dan Phiffer @Ammar @Calix ^ from the TWG.

@Nathan Schneider the value could be corrected if it helps with adoption :)

@Flancian I need to read more about ATProto to form an opinion still, but if the question relates to using the iocoop vps for testing purposes I don't mind (and happy to help too)

@Emsquared yes! I found Fedisky this week after posting the thread, I agree it looks very interesting: https://github.com/msonnb/fedisky

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

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

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

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?

https://bonfire.social.coop/

@Nathan Schneider

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.

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.

The claim that the protocol is proprietary is false. In terms of
governance and trajectory, the protocol is being standardized in the
IETF (https://datatracker.ietf.org/wg/atp/about/).

And although I strongly share the skepticism about VC-funding, have
little interest in Bluesky the product, and am ambivalent (at best)
about the long-term prospects of the Bluesky company as a force for
good in the world, I disagree with most of the rest of this assessment
as well.

I know that there are strong technical disagreements between the
ATProto folks and the ActivityPub creators. There are also some
meaningful, but reasonable, differences of opinion about what
constitutes (enough) decentralization or essential features in a
social media system. And while I don't know and can't speak for
Bluesky Corp's funders, I have met some of the people building ATProto
and the apps running on the protocol (including someone I live in a
housing cooperative with), and I am convinced that your assessment of
people's values is wrong for at least some of what is going on in the
protocol.

@Nathan Schneider

I've started a private thread with the people who expressed interest in advancing this idea.

Can I please get an invite to this?

@strypey what is your social.coop handle?