Applications on atproto run moderation as a kind of filtering layer on top of the user data. A ban in that scenario is fully filtering their account out of the application.
While anybody can host their own PDS, the public bsky.app instance can and will “block” users by preventing their login and not pulling data from the PDS of the banned user or showing it in feeds.
Since, to date, the BlueSky “AppView” (the service backend itself that handles aggregating data, generating feeds, etc.) continues to be closed, being banned from the public instance is effectively being banned from the network. The data model (lexicon) is well documented and somebody else is free to write their own, but, for now, BlueSky is just as centralized as other platforms even if you can store your data elsewhere.
Without the backend that handles all of the XRPC endpoints [1] being available, BlueSky still effectively maintains centralized control over their part of the 'atmosphere'. Somebody could, of course, make an open source implementation of the app.bsky lexicon and users would only need to update their DID to point at their preferred instance, but AFAIK none exists right now.
What is missing?
Would projects like this one, which pulls only a subset of Bluesky data straight from the firehose, and can be processed as the end user pleases, help mitigate this limitation?
Theoretically they could maintain that filtering only occurs on the client level but they've made the choice to exclude banned users from the firehouse so their moderation choices effect everyone