Comment by OneDeuxTriSeiGo
10 hours ago
FWIW the only "site that goes dark" is the https://bsky.app website frontend/mobile app.
And the "block" is a single clientside geo-location call that can be intercepted/blocked by adblock, etc.
And the "block" doesn't apply to any third party clients. So that includes:
- https://deer.social (forked client)
- https://zeppelin.social (forked client + independent appview)
- https://blacksky.community (forked client + independent appview + custom rust impl of PDS + custom rust impl of relay)
And a bunch of others like:
And I could keep going. But point being there are a thousand alternative frontends and every other bit or piece to interface with the same bluesky without censorship.
And the only user facing components are the frontend and the PDS. The appview can't even see the user's IP, only the PDS it proxies through. So if you move to an independent PDS and use any third party frontend, even if you use the bluesky PBC appview, there is no direct contact/exposure to the company that could be exploited.
but Bluesky runs the API that all of these tools rely on
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?
2 replies →
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.