@zuiderzeemeermin first, i did not imply both are necessarily "equally bad". i very clearly stated that they both have pros and cons, and both struggle for various reasons; many of which were too nuanced and detailed to include in my original post. i think both are particularly good takes on a decentralised social media protocol, but both succeed more in certain areas than the other.
it's important to note that atproto is a much newer, far less mature protocol. third-party PDS (personal data server) software is still very much in its infancy (arguably, so is the first-party one; we still lack TOTP beyond email codes, and self-hosted PDSes don't even get that), self-hostable appviews (the service that provides the curated app feed for users) are still a big problem with only a theoretical solution. the ecosystem is quite flawed right now, but that's primarily down to a lack of maturity. this is something that will inevitably improve with time, much like activitypub.
as for how we can specifically improve atproto's decentralisation, this is something that has been discussed at length in the sphere. here are some proposals (some of which are already underway):
- extensive work building bespoke PDS software, without any involvement from the bluesky team. because of how atproto is designed, a compliant PDS should be compatible with core bluesky functionality without any bluesky-specific code; it mostly just responds to record retrieval/creation requests (bluesky has unfortunately built a lot of proprietary endpoints since launch, but this functionality can still be reimplemented by third parties)
- encouraging people to migrate to, and host third-party community PDSes. like the activitypub ecosystem, a community host can house many users' data, but unlike activitypub, this data is fully-portable, and can bounce between PDSes at any time. there are even resiliency considerations built into atproto which enable users to migrate from a rogue instance.
- expediting work on a self-hostable, scoped appview. currently, bluesky's appview requires an incredible amount of resources to run: appviews act as a constellation mirror of all PDSes that it scrapes; this requires potentially terabytes of storage, and an immense amount of processing, memory, and network capacity. a scoped appview would (ideally) only collect and save the social graph (plus some extras) of users utilising the appview, greatly reducing resource requirements. such implementations do already exist, but they're rough around the edges, and system requirements are still quite high.
if these three criteria were met (particularly the self-hosted appview), then atproto as a network would quickly become resilient to enshittification and censorship on the same level as the fediverse.