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.
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.
Bluesky is not decentralized. The AT protocol is - albeit with few large integrators besides Bluesky, but it isn't susceptible to like 51% attacks or anything so that's mostly okay.
Does it actually? (Genuine question.) The article doesn't get into specifics about how the block is implemented, but I wouldn't be surprised if there is some non-trivial way around it.
Or, conversely, I'm unsure if other decentralized platforms would be unable to implement a similar block.
TLDR it's a single geoloc RPC call clientside. you can just tag it with an adblock filter to kill it. Or use any third party client (my comment to OP has a bunch of them listed).
Interesting though: I wonder how long til site host lists and ad filters start shipping anti-censorship lists and features. We know some DNS provider is already doing it. (I forgot which one)
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:
- https://anisota.net/
- https://pinksky.app/
- https://graysky.app/
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.
7 replies →
Bluesky is not decentralized. The AT protocol is - albeit with few large integrators besides Bluesky, but it isn't susceptible to like 51% attacks or anything so that's mostly okay.
Does it actually? (Genuine question.) The article doesn't get into specifics about how the block is implemented, but I wouldn't be surprised if there is some non-trivial way around it.
Or, conversely, I'm unsure if other decentralized platforms would be unable to implement a similar block.
TLDR it's a single geoloc RPC call clientside. you can just tag it with an adblock filter to kill it. Or use any third party client (my comment to OP has a bunch of them listed).
Interesting though: I wonder how long til site host lists and ad filters start shipping anti-censorship lists and features. We know some DNS provider is already doing it. (I forgot which one)