Comment by OneDeuxTriSeiGo
12 hours ago
No it does not. That is the trick.
The client/frontend calls out to a set of XRPC endpoints on the user's PDS. The user can use any PDS they want but yes most users are on the bluesky "mushroom" PDSes. There are plenty of open enrollment PDS nowadays if you care to look around and want to switch away.
The appview have no ability to interact with the user directly so if you use any non bluesky PDS and non-bluesky client/frontend (both relatively trivial to do), then the appview is basically a (near) stateless view of the network which you can substitute with any appview you want (the client can choose the appview to proxy to with an http header) without ever touching bluesky the company.
And of course there are multiple appview hosts. As well as relay hosts (which the appviews depend on but not the user/client).
There are plenty of ways to go about using bluesky without yourself or the services you use ever touching bluesky the company's infrastructure.
Where does the firehose stream originate? From individual PDSes, or from the Bluesky relay that aggregates their repo events?
How do I do this then?
Everything but the relay (but you'd realistically only need the PDS): https://alice.bsky.sh/post/3laega7icmi2q
The relay: https://whtwnd.com/bnewbold.net/3lo7a2a4qxg2l
Edit: I mistook the bsky.sh domain, my bad. Can't get strike through to work for the life of me. I give up.
~~Bluesky blocked in Mississippi, try to work around it, only for the resource that tells you how to do this to be hosted on Bluesky, which is blocked. That's... suboptimal~~.
I can't help but feel like Bluesky is just three corporations in a trenchcoat pretending to be an open federated ecosystem.
so basically you can run a cache for them and they have the final say on all accounts/ids because nobody will see any federated content anyway.
you progress the grand parent comment point, with a lot more words.