This is true. In the simple implementation, your blog would probably lose most comments if BlueSky went down and most users don't migrate to a new PDS.
However, atproto data is append-only and cache-friendly. It wouldn't be hard to record historical comments and join them to the ones returned by the live query. (I'm probably just going to script periodic backups for mine and worry about displaying them when/if BlueSky does dissappear.)
But then the only reason to use BlueSky is that your network is using it.
It’s a completely valid reason, but All the talk about platform lock in, independent nodes and relay and whatnot is just to make you feel better (I listened to some talks and podcasts but realized that it’s all just window dressing, you can be practically deplatformed at any time, so I’m hazy on the details).
At a minimum, the atproto provides an easy auth solution and public API for your app's data. Running a relay for your lexicon is basically the same as running a normal app server with those built in.
Credible exit matters too. The idea that all of this data is signed, public, and verifiable by anyone helps ensure that the provider is accountable to the community. A provider might decide against enshittifying a product if they're worried about a competitor doing better and taking their place.
Yes, an atproto lexicon will tend to be dominated by a small number of nodes. It's not the perfect distributed system some would prefer, but it is a real improvement on the completely centralized models seen everywhere today.
However, atproto data is append-only and cache-friendly. It wouldn't be hard to record historical comments and join them to the ones returned by the live query. (I'm probably just going to script periodic backups for mine and worry about displaying them when/if BlueSky does dissappear.)