> Blacksky is literally the only such example of alternative infrastructure that I know of
That doesn't mean other places aren't doing so. As an example - here's a list of all the relays that mirror the ATProto network: https://atproto.at/relays
There's 16 relays by my account, of varying sizes. Of course, you don't have to query a relay - you can look at the Personal Data Servers (PDSes) directly.
* And more, like the TikTok clone I can't remember the name of, some more blogging platforms, a (fairly dead) Hackernews clone, some games, etc.
That isn't even mentioning all the Bluesky clones like Blacksky, Eurosky, Northsky, and W.
Each of these shares the same account - the account on your PDS, which you can self-host on any computer with an internet connection. I run mine alongside my smarthome server. Because they share an account, they interop - I can subscribe to a blog on Leaflet and have it show up in my Bluesky feed.
These services can fetch data from your PDS directly, or they can look at the Relay and get the full view of the network - but frequently, they don't need to.
Bluesky went down a couple months ago and many of these services were all perfectly usable, because they used the protocol but not any infra provided by Bluesky itself. The people who couldn't access the network were the ones who relied on Bluesky to host their accounts - which is a majority of the network, sure, but in the same way that Mastodon.social is a good chunk of Mastodon's network. I was able to use Blacksky to post onto Bluesky while Bluesky was down, because I was self-hosted.
Now both Eurosky and W have launched; Eurosky is aiming to be fully independent this summer and I _think_ that W already is? W's a bit more closed-off than most of the other projects I named, going directly after Twitter-as-it-is-now and not Twitter-as-it-was (hence why they chose W to compete with X).
Blacksky is now fully independent and does not have any reliance on Bluesky whatsoever.
In fact, in cases where Bluesky _did_ go down, Blacksky was still working fine (if a little slow due to the amount of Bluesky people on Blacksky), and people were able to make posts and everything.
You are working for one of the largest companies on the planet. You push code that gets used by millions of people.
How on earth are you not thoroughly testing your changes??? How can something like this slip into a real build? Like, this is egregious.
I work somewhere that makes software for a lot of users (although not as many as Microsoft!). We also need to ship quickly. But we work on a 45-day cycle, with 15 of those days being dedicated to ensuring we didn't add any awful bugs (and fixing them ASAP before it goes to users - or reverting the change until it is ready).
I would expect Microsoft to have AT LEAST that amount of care. We can't trust that you are shipping software that even works anymore!
What other changes are going in that are broken in more subtle ways? It used to be that VS Code was rock solid, and any issues were likely third-party extensions - but now it's a crapshoot, and I can't be sure if crashes etc. are the fault of extensions or Microsoft themselves!
The VS Code team needs to use this mistake as motivation to lead the charge on making a quality editor. Not an editor that gets half-baked, untested changes pushed weekly. An editor that is dogfooded and where a mistake like this going to prod is unacceptable.
Because if you don't, people won't trust your editor anymore. Just like people have stopped trusting your OS, and now users are fleeing it in such numbers that the Windows team has recognized they have a problem and are changing course.
That WILL happen to VS Code and GitHub soon unless you actually start owning mistakes internally and fixing them before users find them.
Dunno necessarily if they are _forced_ to expose that data.
Something like OAuth means that you can give different levels of private data to different actors, based on what perms they request.
Then you just have whoever is holding your data anyway (it's gotta live somewhere) also handle the OAuth keys. That's how the Bluesky PDS system works, basically.
Now, there is an issue with blanket requesting/granting of perms (which an end user isn't necessarily going to know about), but IMO all that's missing from the Bluesky-style system is to have a way to reject individual OAuth grants (for example, making it so Bluesky doesn't have access to reading my likes, but it does have access to writing to my likes).
When you write a post, you save it to your PDS. Think of it like writing a blog. You're done, you hit submit, it shows up on a server somewhere. You can run your own server with your own data, or use someone else's. That's exactly how a PDS works; it is a storage server for your data.
The AppView is a way to index all the PDSes registered across the whole network. If your server is crawlable by the AppView, all your data shows up in the app. This is like if your blog is crawlable by Google, you show up in search results.
When you like a post, you commit a "like" record to your personal server. When the AppView displays likes, it looks at every indexed PDS and shows every like it can find for that post (simplifying a little for clarity). Each one of those likes might live on different servers, some of which is self-hosted.
Because you can run your own PDS, you can commit any data you want to it. You can even commit things that services may find distasteful. However, the AppView may refuse to serve this content to users; this is how content can be removed from the network and how users can be banned. The federation equivalent would be defederation, except it happens to singular accounts rather than entire instances.
If you disagree with the moderation policies run by Bluesky the company, that's when you can look into running an alternative AppView. This is similar to disagreeing with the admin of a particular Mastodon instance and moving to a different instance. Of course, as mentioned running an AppView is much more expensive, but that hasn't stopped folks from trying (I believe Blacksky is trying to run their own AppView that is fully independent of Bluesky).
To use an alternate AppView, you'd simply go to a different website. This website will index PDSes the same way that Bluesky does, but it may index them in a different way and include/exclude different content. The data is still there (nobody can reach into your PDS on your server and delete your data), but the AppView admins choose which content they wish to serve to people using their community, just as Mastodon admins choose who to federate with.
In this sense, it is indeed truly federated. The primitives are simply different; it's more granular than Mastodon.
You can write your own content to your own server and let it get indexed to any number of AppViews; you completely control your personal data and nobody can reach in and delete that data randomly as they don't own it - you do (at the cost of ~$1/month or a Raspberry Pi).
When you use the Bluesky service, you are seeing their view of the network and what they choose to index. You may disagree with this view, just as you may disagree with the admins of Mastodon.social etc. In that case, you can choose to use another AppView (such as deer.social or Blacksky) that adopts different policies. Since account information isn't stored on the AppView and it simply handles indexing and moderation, moving between AppViews is painless and no data needs to be transferred from one server to another - you simply use a different bookmark.
It could be that you disagree with all the current AppView admins. You can host your own, it's just expensive ($300/month, as mentioned). You can also tailor your AppView to index less content, which will of course limit the amount of data you consume and give you a partial view of the network, effectively defederating you from anything you do not wish to index.