Copy/pasting a comment I made on a different thread:

That’s the same argument people made about Twitter. “If it goes bad, we’ll just leave.” We know how that played out.

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.

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.

except those explicit examples showing that people do exactly those things?

I don’t follow. What are you saying?