sigh
No. There are better alternatives. Even if it becomes federated, Bluesky will always remain controlled by one company. They'll always by the biggest server and the defacto authority. Their decisions about the API will be executed by fiat. This is the way with standards that don't start open, and it's a constant threat even to the ones that do.
Cases in point:
- ActivityPub and Mastodon. While highly federated with hundreds (thousands?) of open servers, Mastodon is still the 800lb gorilla and has huge influence on the protocol. AP wraps itself around and accommodates Mastodon.
- Subsonic. There's OpenSubsonic, a project to better document and inform a server-independent process around the API; and yet, there are a lot of problems and ill-defined behaviors in the API, and when these come up the knee-jerk reaction is "well, this is how Subsonic does it, so even if it's wrong or broken, that's how it has to be."
- Matrix. The reference platform is synapse, and where the API or server behaviors are not clearly defined, it always comes down to how synapse implements things. Matrix will often be extended first by implementation in synapse and then firm establishment in the API definition. This is why you see a lot of attempts to build Matrix servers, and why most lag or founder: because implementation details are worked out in synapse and third parties can't rely on the API details being reliable, which is always long after it's already been implemented and deployed in synapse.
BlueSky will be similar to Matrix: the people with the most influence over the spec will be BlueSky; and they'll have new features first, be the biggest instance, and if they don't want a party to play in the game, they'll have the ability to lock them out merely by the sheer power of defederating and shunting the offender into a small corner of the FediVerse.