[kmeisthax]

"Only viable instance" is not really the correct framing - Bluesky doesn't have instances. Anyone using ATProto without Bluesky will still be "on Bluesky".

When you go to bsky.app, you're interacting with the Bluesky AppView; one key feature of ATProto is that any AppView can interact with any (consenting) Personal Data Server (PDS). So you can self-host your PDS but still use bsky.app if you so choose. But critically, anyone can write an AppView; there are reimplementations of Bluesky as well as other social apps that use the same ATProto infrastructure. That would be closest thing to a Mastodon instance, except you don't have to host your data on it in order to use it. Imagine being able to go to a Lemmy instance and just post things with your Mastodon identity, and have everything show up without Mastodon having to know anything about Lemmy magazines or its special upvote / comment formats.

The actual centralization in ATProto lies in a combination of unfortunate design decisions and genuine friction in the self-hosted path. Being totally reliant on Bluesky is the happy path, self-hosting your PDS data is difficult but doable, and being totally independent of Bluesky is only possible if you do everything correctly right at the start.

First off, Bluesky doesn't offer any GUI tools for PDS migration. If you want to get off their PDS, you'll need to bust out command-line tools and possibly do some steps in advance of when you need to migrate in order for everything to work properly.

Second, even if you're on a PDS, you're still reliant on the Public Ledger of Credentials (PLC) to host your Distributed ID (DID) document. The PLC is run by Bluesky, although they've taken steps to make it easy to notice if they were to do something fucky with the PLC. But let's say we don't like that. There is a solution: you can host your DID document on a normal web server. Problem solved?

Well, if you were setting up an account for the first time, then yes, the problem is actually solved, you're 100% independent of Bluesky. But if you made the mistake of registering an account normally, you have a did:plc identity. And one core principle of ATProto is that identity names never ever ever change. So if you go and make a did:web identity, it's like having a second account, there is no way to tie your old did:plc identity into it. In fact, I'm pretty sure you can't even redirect one did:web identity to another (say if you need to switch domain names)

Regarding Bluesky's "independent protocol governance organization", they made the same promise about the PLC; but it hasn't actually been transferred yet. I would be a lot more bullish on ATProto if there was a way to migrate DIDs and retain all your followers and shit. And if there was proper graphical tools for data migration.

[snorremd]

The PLC governance not having been moved yet is my one main gripe against ATProto/Atmosphere now. There is so much being built on top of this protocol, and I truly believe it has the chance to make the social web more decentralized while keeping everything connected. The PLC being controlled by one major commercial entity allows them to pull the plug so to speak. Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.

Half the point of ATProto is that identities are used across a host of apps, and therein lies a big vulnerability. If identities are not truly independent of centralized infrastructure, then you are vulnerable to losing access to a number of apps at once similar to Google services black hole if your Google account is banned (not to mentioned anywhere you've logged in with SSO).

It would be much better if the PLC was somehow decentralized itself. Barring that it should at least be finally spun out as the independent Swiss organization they've talked about for some time now. The organization could form a board with interested parties to set the future of PLC development if needed.

As for PDS migration, there are good options if you are migrating away from Bluesky. There are lots of GUI tools that work well now like https://pdsmoover.com/moover, Eurosky has https://move.eurosky.tech/, etc. It would be cool though if Bluesky actually linked to the other big PDS-providers on the Bluesky sign-up page to actually promote decentralization. But I guess it is hard to vouch for other services.

I still think the future of ATProto is bright, but there are definitely some obstacles before I'm comfortable with the whole setup. The network needs more decentralization in the PDS-layer, and the PLC needs to spin out in the separate governance organization pronto.

[OneDeuxTriSeiGo]

Technically it has moved (last year actually) but it just doesn't really look all that different in the day to day.

https://atproto.com/blog/plc-directory-org

[snorremd]

Did they actually create the org yet? I saw the news you are linking that they were going to start the process. But I've seen no follow up news about the organization actually being here and the ownership of the PLC directory having been transferred.

[throawayonthe]

> Say someone is sanctioned by the US, what stops Bluesky from pulling the plug on their DID thereby blocking and censoring this person from the network all together.

How does IANA handle this with domain names? genuine question, i'm not sure. is it enough to have distinct registrars and distinct jurisdictions for some TLDs and so on?

[inigyou]

They don't. All domains have US jurisdiction except the ones that are underneath country TLDs.

IANA could stop publishing country TLDs in their root zone file but it would probably split the internet in two, and everyone involved knows that. Several root server operators would refuse the update, and many recursive resolver operators would put them back in.

[danabramov]

>First off, Bluesky doesn't offer any GUI tools for PDS migration. If you want to get off their PDS, you'll need to bust out command-line tools and possibly do some steps in advance of when you need to migrate in order for everything to work properly.

This is getting much better recently. I migrated to https://eurosky.tech/accounts/ with no command line — just needed to wait for a wizard in my browser to move my records. It could've been much faster and seamless (the app was confused after this and I had to re-login), but it's definitely accessible to non-technical people, and the share of independent hosting is growing.

[chowells]

Bluesky has a data store, handles account authorization, and runs a web app that provides a UI to access the backend services. That's an instance, whether they call it one or not. Refusal to admit this is obfuscation for reasons I cannot understand.

[danabramov]

The reason is that "why aren't many people running Bluesky instances" is a loaded question — it presupposes that's something you should expect. But it's like asking "why aren't many people running Google". It's expensive to store billions of posts!

This is usually compared to Mastodon, but it's not apples to apples since "running a Mastodon instance" always mean a tiny partial view of the network. You can do a partial view of atproto too for the same cost, it's just not very interesting because what's the point? Every app can "see" the entire network (unlike in ActivityPub) so there's a lot less motivation to create these fragmented views into it.

I've already linked elsewhere, but I've written an article on precisely this topic, curious to see if this can clarify it for you: https://overreacted.io/there-are-no-instances-in-atproto/#so...

[hack1312]

> I would be a lot more bullish on ATProto if there was a way to migrate DIDs and retain all your followers and shit. And if there was proper graphical tools for data migration.

This is exactly where I’ve landed re: ATProto. If you actually want to self-host everything you lose one of the biggest draws of it, the migratable IDs.

I was looking into it to build an alternative to Threads/IG/TikTok for one of my hobby communities that’s become almost entirely reliant on Meta/Tencent. Being able to plug into the wider AT Proto world was a big draw, but not being able to self host a true alternative to did:plc has put a halt to that for now while I figure out what I want to do.

[anon7000]

I didn’t fully understand the part of the stack you’re talking about, but it always seemed like one of ATProto’s design goals was to really keep everything on the same distributed system (so to speak) while allowing people to host the bits individually that all contribute to the same connected system. Eg not having fully separate networks that don’t talk to each other

[hack1312]

If you want a nice overview of the DID stuff, Steve Klabnik just recently made a post going into detail about did:plc and did:web

https://steveklabnik.com/writing/too-many-words-about-dids/

[danabramov]

I don't know what you mean by this. You absolutely can self-host all your data on your own. And if you also don't want to rely on PLC for identity, you make a `did:web` identity, and then you're completely decoupled from Bluesky-operated infra.

[hack1312]

Dan my concern is explicitly that did:web is not the same experience for users as a did:plc.

If I host AT Proto infra for my community and want to give people <usename>.<domain> accounts, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID. did:web does not provide the same UX as did:plc

From the post I was responding to:

> Second, even if you're on a PDS, you're still reliant on the Public Ledger of Credentials (PLC) to host your Distributed ID (DID) document. The PLC is run by Bluesky, although they've taken steps to make it easy to notice if they were to do something fucky with the PLC. But let's say we don't like that. There is a solution: you can host your DID document on a normal web server. Problem solved?

>

> Well, if you were setting up an account for the first time, then yes, the problem is actually solved, you're 100% independent of Bluesky. But if you made the mistake of registering an account normally, you have a did:plc identity. And one core principle of ATProto is that identity names never ever ever change. So if you go and make a did:web identity, it's like having a second account, there is no way to tie your old did:plc identity into it. In fact, I'm pretty sure you can't even redirect one did:web identity to another (say if you need to switch domain names)

[danabramov]

I did read your post :) Yes, you can't migrate between PLC and WEB methods. It's not possible. I get that it's frustrating if you learn about it after making an account. Is that the whole concern?

I was replying to this:

>not being able to self host a true alternative to did:plc has put a halt to that for now while I figure out what I want to do.

I'm saying I don't know what this means. You can fully self-host with `did:web`. Yes, it's unfortunate that you've already made an account by the time you've realized that. I think that's still different from "not being able to self host".

Unless I'm just parsing what you wrote incorrectly, which is quite possible!

[hack1312]

My understanding is that if I want to host AT Proto infra for my community and want to give people <usename>.<domain> account, I can either host a did:web for them which ties their account permanently to that domain, or they have to register with the centralized PLC to actually have all the benefits of a migratable DID, while tying themselves to a central authority. Ergo, did:web does not provide the same UX as did:plc and there’s currently no way (that I know of) to provide such UX to users without requiring them to register did:plc accounts

[danabramov]

>want to give people <usename>.<domain> account

To clarify, do you mean you want their domain handles to look like this, or do you want to make them all have `did:web` identities? These are two different questions. Domain handles would work either way (with `did:plc` or `did:web`).

Indeed, the choice between `did:plc` and `did:web` is precisely "would I rather host tie identity JSON document to an entry in a centralized open source publicly verifiable registry that is moving to be maintained as neutrally as possible, or would I rather choose to tie my identity JSON document to a domain". And that choice has to be done at the account creation because every DID, by design, is immutable.

What options are lacking in that choice? It feels like it has an option for a pragmatist and an option for a purist.

>Ergo, did:web does not provide the same UX as did:plc

I mean, that is the difference between them. `did:web` means "I don't want to depend on anyone except domain authorities; I'm fine with losing identity if I lose the domain". Choosing `did:plc` means "I'm okay with depending on a central registry and find the threat model around it acceptable; I never worry about losing a domain". Both options are available.

[wolvoleo]

Thanks for your clear and concise explanation!

[paride5745]

The nightmare of the Wsocial rollout is a testament of the massive control Bluesky has on the ATProto network.

If Wsocial was on ActivityPub or Nostr nothing similar would have happened.

ATProto has serious centralisation problems, baked into the design. And it makes sense, considering it came out of a Twitter R&D experiment to "decentralise" Twitter itself. Pure federation was never part of the initial design.

ActivityPub and Nostr solve the issue already.

[anon7000]

I think decentralization is just not something users care about generally.

- many people wish they could control what they see and who they talk to. (Eg control the algorithm, avoid censorship from big tech)

- some people care about owning their data so it doesn’t go away when a company fails

- technical people are interested in building more types of social apps that aren’t just twitter posts etc

- nearly everyone just wants a fairly seamless experience without a lot of gotchas or technical problems to solve like self hosting an instance for your friends that falls over if too many people use it and is tricky to network with others.

Bluesky is trying to solve all those kinds of problems, which I think is pretty interesting, and I don’t think the others are quite doing the same thing technically. At the end of the day they are all pretty niche.

[paride5745]

But Bluesky does not solve these points:

- content not in line with the political left is censored

- sure, you have your data in your PDS, but it is de-facto useless if the central identity server of Bluesky goes down

- ActivityPub and Nostr solve this already without being owned by a company

- you cannot easily and cheaply have an ATProto instance. AP and Nostr solve this already

[d1sxeyes]

> - content not in line with the political left is censored

What do you mean? Individual apps can choose to censor I guess, but you can fairly trivially run an AppView with no filtering whatsoever if that's what you fancy.

> - sure, you have your data in your PDS, but it is de-facto useless if the central identity server of Bluesky goes down

That's not correct. You can use plc, which Bluesky operates the largest directory for, but you can also use web, which completely bypasses Bluesky all together.

> - ActivityPub and Nostr solve this already without being owned by a company

What's 'this' here?

> - you cannot easily and cheaply have an ATProto instance. AP and Nostr solve this already

The terminology here of 'ATProto instance' doesn't really make sense. If you're talking about a PDS, you can use one of thousands of free PDS hosts, or host your own for free on Cloudflare (https://cirrus.earth/) or on your own hardware (there are PDS implementations which fit comfortably onto a Raspberry Pi, or an old phone, etc.)

[paride5745]

Sure you can host your PDS, but if you want to deploy your own instance like you would do with Mastodon, you need to deploy a Relay and an AppView as well. And the way the network works, you need beefy servers for that.

On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).

And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own.

[d1sxeyes]

The idea of an 'instance' is not really clear. If you want to run a social network on ATProto, you do need the relay and app view, and those are indeed heavy requirements, but the architecture is not the same, and it depends what you're actually trying to achieve.

If you just want to use ATProto for your own small app, there are ways to do it on more constrained hardware. The more usage it gets, the more it scales up.

> On ActivityPub and Nostr you develop all kind of applications already, it is not only Twitter clones, but also Instagram clones, Reddit clones, on Nostr there is even the resurrected Vine (https://about.divine.video/).

Same! You can explore the (unfortunately named, given the point I'm trying to make :)) 'Bluesky directory' to see apps which use ATProto: https://blueskydirectory.com

Note that most of these have nothing to do with Bluesky.

> And it is not trivial to switch from the Bluesky did:plc (which you cannot run in write-mode on your own and need to use the official Bluesky owned) to did:web, which you can run on your own

That's true, but it's not trivial to run your own Mastodon instance either...

[MikeBeas]

Relays are trivial to run now with changes to how syncing works a while back. AppViews are entirely up to the designer of the view. You can make it as complex and expensive or cheap and fast as you want, it’s entirely up to you. You do not have to provide the exact same functionality as Bluesky’s AppView and can basically do whatever you want.

[blackqueeriroh]

> - content not in line with the political left is censored

Can you provide examples to me of this being true?

[blackqueeriroh]

Wait, how do you think these two things relate, exactly, and how does it point in the direction of “Bluesky has so much control”?

Thats a claim with zero evidence put forward, and one that if evidence were put forward, would swing the opposite way.

[pjc50]

What went wrong with Wsocial?

I don't mind the quasi-central nature of bsky, it's more of a problem that it's so heavily dominated by US politics.

[lou1306]

> it's more of a problem that it's so heavily dominated by US politics.

I agree the default Discovery feed is not great, but you can just switch to a different feed like For You or the recent Eurosky version of it, called 'fu'. It vastly improves the experience.

[paride5745]

Or join a European Mastodon server and solve the problem at the root.

[tynanpurdy]

and only have one feed? forgive me if I understand incorrectly but I'll take an open market of thousands of feeds and easy tooling to make my own that can pull from the whole network over just one local feed controlled by a server admin

[paride5745]

https://blog.elenarossini.com/w-social-a-broken-ghost-town/

Basically, because they didn't warn Bluesky that they were going live, they had their traffic heavily trottled and they were unable to function.

So long for decentralisation if you need to talk to the owner of the protocol you are trying to use...

[OneDeuxTriSeiGo]

It's not that they didn't warn bluesky specifically. It's that they didn't warn relay operators in general. And IIRC they just needed to coordinate with a single relay operator who is reasonably trusted (ex blacksky or eurosky) but they didn't do that either.

The default rate limits are quite reasonable but big launches will blow past them so you gotta coordinate with someone.

And note that the relay federation/gossip agreements are largely manual configuration at the moment. Until someone pushes a proposal for an automated/dynamic topology management algorithm that doesn't get plagued with spam issues it'll stay this way.

[paride5745]

No such problem on Mastodon/ActivityPub.

[OneDeuxTriSeiGo]

It absolutely is. Mastodon has rate limits and administrators have to manage and adjust them as necessary for their instances.

You probably just don't notice it as a user or as the operator of a small instance which to be fair is exactly the same with atproto. Users rarely notice rate limits and small operators rarely do either. It's the operators of large services that see these limits and have to coordinate with other operators.

The issue with W social is that they have a chronic inability to coordinate or play nice with anyone else in the atproto space. Rate limits aren't a problem if you are a good neighbor and you know your neighbors but frankly they just don't.

[MikeBeas]

My Mastodon instance blocked Threads preemptively because they were afraid of the traffic driving up their hosting costs so you’re basically just very wrong or lying about this. A huge flood of incoming traffic can be hugely expensive for ActivityPub node operators. The problem of giant onboarding events is real, there’s just no default protection against them in Mastodon like there is in Bluesky, so operators either have to take matters into their own hands with defederation or risk driving their bill through the roof.

[inigyou]

Wsocial turned out to be a WEF honeypot or something.

[paride5745]

That is not the point.

The point is that without talking with Bluesky, you cannot start your own ATProto product or you'll get throttled from the network.

[MikeBeas]

Tons of people have started products without issue. But if you flood a popular relay with data that exceeds its rate limit then getting throttled is to be expected. This doesn’t prevent your participation in the protocol or network.

There are other relays and indexes out there that may have different rate limits. That’s just how these things work. The data from W is still there on their PDS, still public, still crawlable, and able to be backfilled within rate limits.

This is a non-issue.

[inigyou]

That literally prevents your participation in the network, because you need the relay to be forwarding your messages to participate in the network. There is only one relay in BlueSky that matters. If the BlueSky relay is not relaying your messages, then you aren't on BlueSky.

[inigyou]

Almost like the network is centralised.