Bluesky has started honoring takedown requests from Turkish government

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.

You're viewing part of a thread.

Show Context

409 comments

Your "example of self hosting" is not an example of self hosting the relay, just an appview which is still being fully dependent of other Bluesky services like the relay. It's pretty unlikely that the relay would be at all practical to host on a RPi5. But even if it was the problem still remains that the network is set up in a way where self-hosting it only results in you creating your own separate bubble, not meaningfully participating in the official one.
I also doubt anyone has selfhosted relays long-term since right now there's very little purpose to that and the resource requirements are massive as well as keep growing at a fast pace in terms of the disk space required.
- The whole architecture is built around content addressing and allowing every account hosting server (PDS) talk to multiple relays and to allowing mirroring.
  The whole point is to NOT create bubbles.
  People already run their own PDS servers and participate with the official bluesky network, and can talk to users there, because their self hosted PDS syncs to the bluesky relay.
  If you run your own relay and appview it STILL works, and you can talk without bubbles, if you still link your PDS to the bluesky relay to make yourself visible to their users, and if you set your appview / relay to retrieve content from the bluesky relay then you see content from bluesky users too.
  Self hosted relays do exist, they're just not open to the public (mostly used for archival / development currently)
  
  PDS is not very significant, it's just a tiny piece of the puzzle and doesn't really prove anything about the architecture. See this for more on what I'm getting at: https://neuromatch.social/@jonny/113365406995624763
  
  That post is very misguided.
  First of all, he's saying "you SHOULD make your PDS invisible to the bluesky servers because otherwise what's the point", but that's exactly equivalent to saying "our community want it's own Mastodon server - that means we MUST defederate Mastodon.social or what's the point?"
  That's nonsense. Don't enforce silos on people.
  Also, which relays to support are not chosen by users, it's chosen by the services the users choose. The PDS choose which relays to sync to, the appview does too, just like feed generators and moderation labelers does. They can trivially sync to multiple.
  What people will choose is what app to use. This app will choose default appviews, and that appview chooses a relay, etc. Then they register an account, and the app suggests a default PDS server, or they host their own.
  Also moderation labelers can be shared. Communities can run their own, and different communities who trust each other can import labels generated by the others.
  Hosting a PDS is very cheap, it's just storage and bandwidth for the posts multiplied by the number of relays you directly sync to. With a few users on each that's nothing. It's in the range of free tier VPS hosting, RPi grade.
  Deduplicating is probably the most trivial part. There's already code for handling duplicate events in streams. But more practically speaking, there's algorithms like set reconciliation which can make it significantly more bandwidth efficient to subscribe to multiple relays even when they have overlapping content.
  Tldr no there won't be bubbles, unless that's what the users want. They surely CAN choose services which filter out the bluesky servers and which don't make them visible to bluesky, but why?
  As for the DID part, the alternative is DID:Web, which requires permanent control over your domain name. With DID:PLC you can control your data by registering your own keys, although there's possibility for censorship. Their goal is to separate out running the DID:PLC service to an independent foundation.
  As for the followup comments, just a few months ago bluesky made it significantly cheaper to authenticate jetstream events via Merkle tree diffs (jetstream is the lower bandwidth version of the relay firehose service). This means you can verify correctness quickly just by having a copy of the Merkle root hash & pubkey for the accounts you're interested in, you don't need to store the whole user repositories (excellent for feed generators and moderation labelers and anybody else doing partial sync)
  
  I don't think you got the point tbh. It isn't about wanting to separate but about how dependent you are on Bluesky Corp. in every other scenario (and how hard it would be to deal with the situation if they decide to go rogue).
  
  But that IS the point. The possibility of running independently PLUS the ability of bluesky users to migrate their account wholesale away from bluesky servers to 3rd party servers means you're not dependent on them.
  They're literally designing for the principle of "the company is a future adversary" (see: Twitter, et al).
  
  Yes and the thread I linked to explained why it is not looking like it's particularly well thought out for that case. Even beyond those issues they've always seemed very naive about what the company turning adversarial would actually be able to do but then again they obviously also have to worry about making money.
  
  Self hosted relays do exist, they're just not open to the public (mostly used for archival / development currently)
  Blorgbob exists, and people use their own blorgbobs, but also people are not allowed to use blorgbobs, and they are only in archives or experimental development.
  ... Please tell me you understand you have just said completely self contradictory nonsense.
  Leaving the actual truth or falsity of your claim aside... what you have just stated is a logically impossible paradox.
  
  Choosing to not understand the architecture is your failure, not mine
  
  Ok, noted, you are a fanatic who does not understand that the statement of yours I replied to literally is a logically impossible paradox.
  Take a few deep breaths and ... maybe try to reformulate your words.
  
  Not knowing what a relay does and going on the attack over it makes you the fanatic.
  It's an archive node, which can (but doesn't have to) forward ingested data
  
  It is very, very clear, reading your other comments that you are incapable of grasping the concept of a decentralized or distributed network paradigm.
  Maybe go look at how torrents work, how I2P works, how a MeshNet works.
  Other metaphors would be a guerilla warfare network of cells vs a top down conventional hierarchy where individual units are allowed a degree of autonomy within certain bounds.
  The AT Protocol system is not capable of operating in a non centralized manner.
  Your only option is to point your PDS at either the official network of Relays... or set up your own system of Relays, and point your PDS at that.
  Likewise for an AppView, you can either point yours to sync with the official network of Relays... or another network of Relays.
  There is no meshing, where nodes on the mesh control what other nodes they interface with.... there is only branching or forking, setting up an entirely parellel structure, that is not capable of synchronizing with the original.
  Beyond that, you still have not addressed that you said a blatantly self contradicting statement; that people self host relays, but also they don't self host relays because that is costly and the self hosted relay code available to the public is experimental and mainly used for reasons tangential to the core function of a production ready relay.
  And for the I think third time I have asked this, not of you personally, but in this thread:
  Who is hosting a Relay other than BlueSky?
  Can you provide evidence any independent person has figured out how to do this and is actually doing it?
  I would gladly accept new information and adjust my own understanding accordingly, but all I have seen in this thread so far is multiple people claiming that there are self hosted Relays, and then either providing no evidencd, or showing that they don't understand the subject and post a link to a guide to, or example of, somehow setting up an AppView or PDS.
  
  Go away.
  Even I2P uses supernodes, that doesn't make it centralized because you don't depend on them.
  You don't need ultra purist single-type-node mesh like scuttlebutt to be decentralized.
  Bluesky is federated, where the federation has multiple layers and EVERY layer can be run independently and interconnected to other nodes.
  You can even connect to MULTIPLE! An appview can talk to many relays, a PDS account host can talk to many relays, anybody can subscribe to multiple separate feeds generators and moderation labelers hosted wherever, using any app, etc.
  Beyond that, you still have not addressed that you said a blatantly self contradicting statement; that people self host relays, but also they don't self host relays because that is costly and the self hosted relay code available to the public is experimental and mainly used for reasons tangential to the core function of a production ready relay.
  Your inability to read remains YOUR problem, not mine.
  My point is exactly this - it's feasible to maintain your own private relay by mirroring the content you want, imitating both Mastodon and scuttlebutt.
  You can choose to share a community relay - or not.
  Running it for an audience of yourself is reasonably cheap. Running it for a worldwide audience is where bandwidth gets expensive. That's why people run private ones.
  Not capable of synchronizing with the original? Lmao. It's literally content addressed, you can synchronize with every relay separately, swap arbitrarily between public appviews, regardless of who runs what and where it gets data from. It's maximally capable of synchronization. It even beats nostr and scuttlebutt because you can VERIFY you have fresh and complete data (Merkle trees yay).
  Pretty sure Whitewind pulls in data themselves directly when users use self hosted atproto accounts, maintaining its own relay index. Don't think they make it publicly accessible though
  Not having gatekeepers is what matters the most. You can run all infrastructure yourself and still interact with bluesky users (need to use DID:Web, but that's a minor point)
- Can you explain what do you think "backfill" means in the context of the linked post?
  Sorry if that sounds disrespectful but we kinda need to have shared definitions for stuff
  
  Backfill means that the AppView has to request and download and then be able to present... the entire history of all posts from everyone on BlueSky.
  If you are familiar with crypto, its like how you have to download either the entire blockchain, or nowadays, a trimmed down/compressed version of it... before you can interact with it.
  If you are familiar with any kind of database like a forum or something... when migrating, you have to actually import a copy of all the preexisting users, posts, forum structure, posts, etc... if you want the new forum to actually contain what the old forum did, before you allow people to start making new posts.
  When this rando is setting up his own AppView... he is asking the BlueSky Relays to give his AppView all the older posts, before the AppView is caught up, and can then begin to function in realtime with the rest of the network.
  I don't mean to be rude, but if you genuienly don't know what 'backfill' means in this context, it is very likely you have essentially zero experience with or knowledge of systems that involve large databases ... it is a very common and well known term to anyone with basically over a year of doing most kinds of db admin/server admin work.
  
  yeah that was my bad I might be a little stupid.
  I got confused between the relay crawling pdses to store their records for retransmission vs an appview storing records for serving them to clients. Both involve processing similar (v large) amounts of data, but the latter is actually more expensive because you're also transforming the data to make it useful to clients, so it's still neat they got it working on a raspberry pi
  They have said that in production, their appview takes up about 30 servers while the relay takes only one. Apologies for the rude tone of the post https://bsky.app/profile/why.bsky.team/post/3lku2o3n6es22
  
  I have zero need to play games with you. Make your case if you have one.

409 comments