Original post: https://bsky.app/profile/ssg.dev/post/3lmuz3nr62k26
Email from Bluesky in the screenshot:
Hi there,
We are writing to inform you that we have received a formal request from a legal authority in Turkey regarding the removal of your account associated with the following handle (@carekavga.bsky.social) on Bluesky.
The legal authority has claimed that this content violates local laws in Turkey. As a result, we are required to review the request in accordance with local regulations and Bluesky's policies.
Following a thorough review, we have determined that the content in question violates local laws in Turkey, as outlined in the legal request. In compliance with these legal provisions, we have restricted access to your account for users.
Calling it not federated is silly. It's not like-for-like federated like Mastodon where you have a single server doing all roles, federating to other servers of the same role.
Instead it's cross-layer federation. You can use any app, talk to any appview, use feeds hosted by anybody, use moderation services hosted by anybody, host your account on any PDS service including self hosting, and any appview can talk to any relay. It's fully mix-and-match.
Two people on entirely disparate sets of servers & services using atproto can talk to each other as long as their appviews/relays mutually retrieve content from the other.
That's federation.
Are you saying that some functionality is not federated but some functionality is?
I suppose my main problem is lack of meaningful decentralization. I prefer to use networks that allow me to contact people using a local public Wi-Fi service or someone's home internet connection, and I believe it would be expensive or impossible to do that using ATProto without depending on infrastructure maintained by Bluesky.
Bluesky is federated in terms of that you can swap out arbitrary components and let anything talk to anything. Any app can talk to any appview, that appview can talk to any feed generator and moderation labeler for you, all three of these can talk to any (and multiple!) relays, etc.
This isn't 1:1 federation, there's no reason for one feed generator to talk to another, no reason for an appview to talk to another, no reason for two PDS account hosts to talk. Users on different appviews rely on their respective appviews having at least one shared relay to be able to see each other, and that relay can be swapped out. Every other component look at trusted moderation labelers for flagging content and takedowns - and they all choose independently who they trust. Every PDS just wants to talk to one or more relays to make their users' posts visible.
So you can have a pair of users on the exact same set of infrastructure (most regular bluesky users), but you could also have 2 users sharing nothing but the bluesky relay (or another relay) and still talking to each other.
Since it very heavily relies on domains for readable addresses (using a DID directly is possible but annoying) it's kinda hard to use in isolated physical networks. Technically you could make an app host its user's repository and hold a copy of the signing key and publish it locally, but you'd lose a lot of thread visibility unless the app archives everything to republish. Or else you can have a separate offline only lexicon for posting locally, I guess, imitating scuttlebutt.