It is in a sense by design because the focus was creating a decentralize-able/federate-able protocol and infrastructure that can scale more or less indefinitely first and foremost, community second.
The community is working on actually decentralising the network now that things mostly "just work" (assuming you are using did:plc/generally a happy path user).
- Building out PDS communities that are trusted takes time and nowadays there's a few outside of bluesky PBC (one or two big ones and a bunch of smaller ones). People are eager to move off because a lot of users really really don't like bluesky PBC leadership but it's a matter of waiting for these third party communities to reach critical mass.
- Relay infra is already pretty much decentralised. Lots of people still rely on the main relay but it's trivial to use a third party relay and there's more of them than you can count.
- There are a lot of really high quality third party clients and afaict a lot of users do actually use third party clients but there's basically no metric for tracking these stats.
- Appviews are expensive currently and there's work on making them easier to host but there's already one "full" alternative appview for bluesky.
- There are a lot non-bluesky apps/services that are genuinely high quality experiences and they are gaining their own communities.
The main technical barrier to true decentralisation outside of improving UX is introducing other did:methods and/or spreading trust of did:plc across the community (ex: clustered via raft or paxos across major operators) but there's just not a reason to pursue this over the other fires that need fighting in the ecosystem right now (and keeping did diversity low reduces another source of complexity the space just doesn't need to tackle yet).
--------------
TLDR: it is intentional because the goal is to in order of priorities:
1. get the architecture for eventual decentralisation right.
2. make it exist.
3. make it good.
4. make it easy to use for normal people.
5. build community.
6. focus on decentralisation.
Decentralisation in theory is the first priority but in practice it's the last priority. Being able to decentralise is always the utmost importance but forcing it to happen is not ever the top priority because that's on the community, not on the developers.
The way I see it, Mastodon started with a core decentralisation system and then tacked on bits to make it more Twitter-like, while Blue Sky started with a core Twitter-like system and then tacked on bits to make it more decentralised.
Mastodon started as an alternative software stack for GNU/Social (and Laconica before it) years before ActivityPub even existed. It was created in an already almost decade old community/ecosystem and was competing against a PHP tech stack that was showing its age (which is why Mastodon was created).
Comparatively Bluesky/ATproto was a greenfield project with no pre-existing protocol or community to integrate with. And architecture-wise atproto within like 6 months of their 1.0 release federated/decentralised really really well. Bluesky less so (as it's mainly the appview that is limiting).
Even then though bluesky still works pretty well in a decentralised/federated context if you compare the scale it's operating at relative to mastodon and co back when they were of similar project age. Like the appview architecture at a high level works well but it breaks down once you are at a scale of tens of millions of users. And it'll only take relatively minor tweaks to the internal architecture of the bluesky appview to remove this scaling limitation.
Sorry for the rant but point being the ATproto is doing pretty well decentralisation wise for being ~3 years old and accommodating the sudden explosion of non-technical users on the platform so early in its life.
It is in a sense by design because the focus was creating a decentralize-able/federate-able protocol and infrastructure that can scale more or less indefinitely first and foremost, community second.
The community is working on actually decentralising the network now that things mostly "just work" (assuming you are using did:plc/generally a happy path user).
- Building out PDS communities that are trusted takes time and nowadays there's a few outside of bluesky PBC (one or two big ones and a bunch of smaller ones). People are eager to move off because a lot of users really really don't like bluesky PBC leadership but it's a matter of waiting for these third party communities to reach critical mass.
- Relay infra is already pretty much decentralised. Lots of people still rely on the main relay but it's trivial to use a third party relay and there's more of them than you can count.
- There are a lot of really high quality third party clients and afaict a lot of users do actually use third party clients but there's basically no metric for tracking these stats.
- Appviews are expensive currently and there's work on making them easier to host but there's already one "full" alternative appview for bluesky.
- There are a lot non-bluesky apps/services that are genuinely high quality experiences and they are gaining their own communities.
The main technical barrier to true decentralisation outside of improving UX is introducing other did:methods and/or spreading trust of did:plc across the community (ex: clustered via raft or paxos across major operators) but there's just not a reason to pursue this over the other fires that need fighting in the ecosystem right now (and keeping did diversity low reduces another source of complexity the space just doesn't need to tackle yet).
--------------
TLDR: it is intentional because the goal is to in order of priorities:
1. get the architecture for eventual decentralisation right.
2. make it exist.
3. make it good.
4. make it easy to use for normal people.
5. build community.
6. focus on decentralisation.
Decentralisation in theory is the first priority but in practice it's the last priority. Being able to decentralise is always the utmost importance but forcing it to happen is not ever the top priority because that's on the community, not on the developers.
The way I see it, Mastodon started with a core decentralisation system and then tacked on bits to make it more Twitter-like, while Blue Sky started with a core Twitter-like system and then tacked on bits to make it more decentralised.
I don't really think that's fair.
Mastodon started as an alternative software stack for GNU/Social (and Laconica before it) years before ActivityPub even existed. It was created in an already almost decade old community/ecosystem and was competing against a PHP tech stack that was showing its age (which is why Mastodon was created).
Comparatively Bluesky/ATproto was a greenfield project with no pre-existing protocol or community to integrate with. And architecture-wise atproto within like 6 months of their 1.0 release federated/decentralised really really well. Bluesky less so (as it's mainly the appview that is limiting).
Even then though bluesky still works pretty well in a decentralised/federated context if you compare the scale it's operating at relative to mastodon and co back when they were of similar project age. Like the appview architecture at a high level works well but it breaks down once you are at a scale of tens of millions of users. And it'll only take relatively minor tweaks to the internal architecture of the bluesky appview to remove this scaling limitation.
Sorry for the rant but point being the ATproto is doing pretty well decentralisation wise for being ~3 years old and accommodating the sudden explosion of non-technical users on the platform so early in its life.