This conclusion is based on a misunderstanding of both what Frazee meant, and how the protocol works. He wasn't saying to switch to a different platform altogether, but to switch to a different appview, akin to switching instances on mastodon.

If I were to make the same argument for mastodon: Mastodon.social has gone evil, there's a new alternative called mstdn.social that people are rushing to. I'm switching to mstdn.social.

In the case of bluesky, the bluesky appview has made some bad moderation decisions, so users annoyed at this can (and do) use blacksky's appview.

Switching appviews doesn't have the hassle of switching mastodon instances though, you just have to go to a different site, and login again. You can continue using your old PDS.

You may recall that there were some articles about how one user on blacksky's servers got banned, but he was still gone from blacksky's app?

That's not even true, the user is available on blacksky's appview: https://staging.blacksky.community/profile/spacelawshitpost.me .

What had happened here was:

Link had an account on a blacksky pds (https://blacksky.app/)
Blacksky runs a bluesky client (not appview, just the frontend--that makes requests to another appview), pointed towards bluesky) at https://blacksky.community/.
Link gets (unfairly) banned from bluesky, but his account is still safe on his PDS, but viewing it on blacksky.community shows that it was banned, because blacksky.community was pointed at bluesky's appview.
Some people assume bluesky is the same as fedi (without the split between data storage and applications), and this means bluesky banning him banned him on his home instance, since the client said he was banned.
Blacksky didn't run an appview at the time (iirc, they are writing their own implementation from scratch), but they do now.

In reality, his account was still viewable on alternate appviews, like wafrn instances. You could (and still can) also view and intereact his account on https://reddwarf.app/ , a client that works through direct PDS queries, that doesn't rely on a relay or appview.

When you use any ATProto app, it writes data to your Personal Data Server, or PDS. Your Bluesky posts, your Tangled issues, your Leaflet publications, your Grain photos. All of it goes to the same place.

This is done intentionally, and it has a lot of advantages over how the fediverse does things.
Instead of having to make a new account for every different "style" of platform, you can use your existing PDS account. PDSes are also very flexible in what they can hold, you can create a record that contains basically anything.

Also, data isn't just stored on your PDS, it's also stored on relays and appviews. Data is content addressed, meaning that it is portable, you can easily move all your data to another PDS. This isn't possible on the fediverse as all data is "centralised" to it's instance. While you can move your followers, your posts immovable.

You can self-host a PDS. Almost nobody does. Why would they? Bluesky's PDS works out of the box with every app, zero setup, zero maintenance. Self-hosting means running a server, keeping it online, and gaining nothing in return.
To be fair, migration tools exist. You can move your account to a self-hosted PDS for as little as $5 a month

This sounds like the author is implying your only option is to self host, when there's many different PDSes with open signups already.

I was able to migrate to https://altq.net/ (semi-open PDS, you have to ask an admin for an invite code to stop spam), with no self hosting involved.

Bluesky has made this easier over time and even supports moving back. But this only works if you do it before the door closes. If an acquirer disables exports, it doesn't matter that the tools existed yesterday. And we know from every platform transition in history that almost nobody takes proactive steps to protect their data.

This isn't exclusive to atproto. A fediverse instance could decide to block incoming migrations, or to block outgoing migrations (pixelfed.social has had outgoing migrations disabled for a while recently).
It's also possible to move permissionlessly, if you get your rotation key, you can migrate PDSes, even if your old pds is gone, or your admin tries to block exports.

It's not just the PDS. Bluesky controls almost every critical layer:

The Relay. All data flows through it. Bluesky runs the dominant one. Whoever controls the relay controls what gets seen, hidden, or deprioritized.

Relays are less relevant than everyone thinks they are. Appviews don't have to use relays, they just help solve the missing data problem of the fediverse. AppViewLite is a project that lets you crawl PDSes directly--no relay involved!

Relays are also a part of the fediverse, for the same reasons they exist on atproto.

Third parties can run their own, but without the users, it doesn't matter.

This again feels like the article is implying that there isn't third party relays running already. Blacksky runs a relay at https://atproto.africa/ . There's also:

https://relay.fire.hose.cam/
and three relays ran by https://firehose.network/
off the top of my head. As stated previously, relays aren't an integral part of the network. With direct PDS crawling and stuff like https://constellation.microcosm.blue/, there's no inherent need for a relay.

It's worth mentioning that relays aren't that expensive to run. It's possible to run one for $34 a month.

The DID Directory. Your identity on ATProto resolves through a centralized directory run by Bluesky. They've called it a "placeholder" since 2023 and said they plan to decentralize it. There's still no timeline.

Plc.directory is currently in the process of being moved to an independent swiss company. It's just taking time because legal stuff takes time.
If plc.directory disappears, the network doesn't fall apart, there's many different mirrors. I have a mirror on a PC in my attic.

There's also a second supported did: did:web. This runs entirely independently of bluesky.

At every layer, the answer is "anyone can run their own." At every layer, almost nobody does.

This ignores the fact that people do run stuff.

The protocol says you can leave. But the company that just paid billions for the network has no incentive to let you.

The protocol is designed so you can leave, even if your PDS/host has been taken over. This is why they did stuff like portable objects/identity, which the fediverse doesn't do.
If bluesky gets taken over, they don't have a way of stopping exports, whereas a malicious mastodon instance can.

[–] 73ms@sopuli.xyz 2 points 23 hours ago (1 children)

This is exactly the dynamic the article was describing: concerns about power concentration get answered with lists of theoretical protocol features instead of engaging with how the network actually operates. Listing technical escape hatches doesn’t address who controls the dominant infrastructure in practice.

The overwhelming majority of users rely on hosted PDSes, the main relay, and the default appview. Whoever controls those layers controls visibility, discovery, moderation signals, and reach. That’s where practical power sits. Doesn't matter whether migration is technically possible under ideal conditions because if you'll need it they won't be ideal.

Acquisitions and policy changes can happen quickly. Tools that exist “yesterday” are irrelevant if users don’t act before control consolidates, and history shows that most don’t. Claiming decentralization can wait until the last possible moment ignores how network effects and defaults entrench power long before any formal lock-in occurs.

It’s also worth noting that the original article isn’t even arguing “the fediverse is better,” yet the response immediately reframes the debate as a comparison. Even if we entertain that framing, the situations aren’t symmetrical. Yes, a fediverse instance can block migrations or misbehave but no single party in the fediverse comes close to the infrastructural dominance Bluesky Corp currently holds across relays, appviews, and user gravity. An individual Mastodon instance misbehaving affects its users. Bluesky Corp fully controls the experience of over 99% of the users on the protocol and so holds the power to shape the experience of the entire network.

The issue isn’t whether both systems have theoretical weaknesses. It’s where systemic leverage concentrates in practice. And ATProto’s architecture, particularly the cost and complexity of running the more demanding components that need to have a global view of the network, structurally favors concentration at those layers.

[–] irelephant@lemmy.dbzer0.com 1 points 4 hours ago (1 children)

answered with lists of theoretical protocol features instead of engaging with how the network actually operates

I'm not just listing theoretical features, these are things that happen in the network right now. Is there anything I mentioned in my comment that I forgot to give an example for?

Doesn’t matter whether migration is technically possible under ideal conditions because if you’ll need it they won’t be ideal.

I don't see why so many people say migration is only "technically" possible, migration can be done today. If there is more demand for third party servers, say, if Bluesky starts fucking up with moderation more, more third party servers will pop up, because right now the user concentration isn't a technical problem or fault of the protocol. I don't disagree that it's a problem.

And ATProto’s architecture, particularly the cost and complexity of running the more demanding components that need to have a global view of the network, structurally favors concentration at those layers.

It's not necessary to have a global view of the network to participate in the network.
It is possible to have a global view of the network without a relay using constellation, constellation instances are very cheap to run, and work by indexing backlinks. It's what powers reddwarf and recently wafrn (wafrn optionally supports relays as well).

Atproto isn't significantly more complicated than AP, it's just different.

[–] 73ms@sopuli.xyz 1 points 3 hours ago* (last edited 3 hours ago) (1 children)

The features are theoretical in the sense that there is no real guarantee they'd be possible after BSky corp changes their behavior and that they are in use only in the least significant way possible, for tiny and irrelevant numbers of users. But of course this is just restating the obvious again. For a network truly to be shielded against this sort of thing it should be decentralized already before.

See this for how constellation makes no difference.

[–] ricci@discuss.systems 1 points 3 hours ago (1 children)

@73ms @irelephant

I also wrote a more complete thing about constellation here: https://discuss.systems/@ricci/116132447206279469

[–] ricci@discuss.systems 1 points 3 hours ago (1 children)

@73ms @irelephant

In terms of how prepared atproto users are to use adversarial migration, I did a point-in-time survey a couple months ago: https://rob.leaflet.pub/3m7isflo7ls23

I suspect the situation has slightly improved since then, as some or all of the migration tools offer to set up rotation keys for you, but I haven't had time time to do a followup.

[–] 73ms@sopuli.xyz 1 points 1 hour ago* (last edited 1 hour ago)

@ricci@discuss.systems Thanks for the link to the explanation, that thread in general and the survey! All were quite insightful.

[–] rako@tarte.nuage-libre.fr 1 points 1 day ago (1 children)

I'm sorry, but it's like you haven't read the post:

But every counter-argument to the concerns above rests on the same foundation: technically, users can leave. Technically, you can self-host. Technically, you can run your own relay. The capability exists at every layer. But people don't do these things. They never have with any protocol. Not email, not RSS, not XMPP. The default wins. Always.

It is always technically possible to do differently. It's computers after all: anything can be coded. And most people won't because they have their life to live. What matters is the default, and all the incentives point to the default being shittier as time goes on.

The most crucial point is the relay. Yes, appviews can work without, but then you miss everything that is happening which is probably the number one reason people go to bluesky rather than the fedi. Relays are a fundamental part of what makes bluesky attractive and they require large capital to run and maintain, so it all points to bluesky still running the main one that most will connect to

[–] irelephant@lemmy.dbzer0.com 1 points 1 day ago (1 children)

It feels like you haven't read my comment thoroughly.

To start, relays do not require large capital to run. This has been a misconception from the very beginning. I linked to this blog post, where a bluesky engineer runs a relay for ~$34 a month. If relays really had astronomical costs to run, I doubt Bluesky would run a whole separate one.
AppViews aren't limited to one relay, most I know point to blacksky's one as well.

technically, users can leave. Technically, you can self-host. Technically, you can run your own relay. The capability exists at every layer.

There's no need to self host as there's already public third party instances you can switch to. The alternatives already exist at each layer.

I do agree that too many users are on bluesky's servers, but that's not a fault of the protocol, and it's not something the fediverse is immune to either.

They never have with any protocol. Not email, not RSS, not XMPP. The default wins. Always.

This is just incorrect. RSS is probably one of the least centralised protocols right now, it's not even federated, which makes me question why the author even included it as an example. If anything, this reads as an argument against federation, rather than an argument for the fediverse.

[–] rako@tarte.nuage-libre.fr 1 points 1 day ago (1 children)

It costs $34 a month for an experiment. It doesn't cost anywhere near that for a node that is running, used by thousands/millions of people, ingesting millions of pdses. Don't be misled by a nice experiment. You need servers, backups, people to run that. See what real world deployment looks like: a little bit under 100k a year for the only independent full stack.

There's no need to self host as there's already public third party instances you can switch to.

Yes it's possible. It's just not the default. That's the issue

it's not something the fediverse is immune to either.

true, although no one said the contrary

This is just incorrect. RSS is probably one of the least centralised protocols right now, it's not even federated, which makes me question why the author even included it as an example

The argument isn't whether something exists, it's what people use: rss is amazing but it's far from being mainstream. The default path to following isn't rss, which is the point (and the problem).

It's not an argument against federation. It's an argument to look beyond the niceness of a tech.

[–] irelephant@lemmy.dbzer0.com 1 points 1 day ago

Blacksky doesn't just run a relay, they run an appview (way more expensive than a relay) and pds (admittedly pretty cheap).

The point of atproto isn't to have many different groups running the entire stack, you can use an appview by one group, powered by a relay by another, while using a pds by a third.

A relay I listed in the comment is a real-world one that is currently only costing the creator $30/month, which is ingesting all PDSes, and being used by a lot of apps.

true, although no one said the contrary

While the article itself didn't say it, the overall attitude of most people on the fediverse is that.

I do agree with you that users aren't exposed enough to third party infrastructure, and that most users using bluesky's servers is a problem, but the alternative is the jankiness of the fediverse, which completely puts new users off.

[–] CMLVI@lemmy.world 2 points 1 day ago

Insanely well said. It seems like the goal with much of the discourse is just "my choice is right and everything else is wrong, and I'll work backwards from there". Not everyone uses social media the same way, not everyone has the same goals, not everyone wants the same features, not everyone values the same levels of privacy. And the running narrative with differing opinions on this seems to just be base-level tribalism. Just look at the insults here, lobbed solely because someone made an account with a social media platform that doesn't align with your preferences.