|
Top-level
Here's #Bluesky's diagram of the federated network. Labelers are independent services where posts coming from the BGS are tagged to make them easier to filter. Accounts (and maybe admins) can then hook into a labeler to outsource some of the moderation load. Feed generators sort and filter posts. This is where the custom algorithms live. App Views also do some sorting, but they're mostly (I believe) for sorting out post types for app types, e.g. photoblogging, microblogging, etc. 8 comments
So let's say I'm the CCP, and I want to control what Chinese citizens can do on #Bluesky. I could start by configuring the national network to only allow traffic to and from PDS that connect to approved Feed Generators. I could run the BGS that crawls those PDS to exclude servers from other countries. I could run the Labelers that feed into those Generators and flag posts as "seditious" so that they get filtered. And, of course, I could investigate anyone who gets flagged by the ML software. But how about a non-state actor example? Let's say I'm just a ML enthusiast and decide to run my own #Bluesky Labeler. Maybe I run a pretty good service, and lots of people on the network start relying on it for moderation. And maybe I'm also a big 'ol TERF, and adjust the Labeler so that accounts by people whose profiles identify them as trans get mislabeled into frequently moderated categories. AFAICT, the only safeguard against this is… marketplace dynamics. #Bluesky is pretty clear about the market-oriented direction of how they're structuring the network: https://blueskyweb.xyz/blog/3-30-2023-algorithmic-choice In effect, they're offloading a lot of responsibility onto "consumer choice." But these are consumer choices about services that are, to a large extent, black boxes. Unless the BGS, Labelers, App Views and Feed Gens are radically transparent about how they handle data, you have to choose based on little more than how you feel about your timeline. This, from "Federation Architecture Overview," is also pretty wild: "For example, the BGS might crawl to grab data such as a certain post’s likes and reposts, and the app view will output the count of those metrics." #Bluesky's solution to the out-of-sync metrics people sometimes complain about on #Mastodon is to separately crawl for likes and reposts, and pass that info through the App View. Which seems like an opportunity to inject false metrics, particularly if anyone can run an App View. The post says that #Bluesky is experimenting with breaking Labeling and Feed Gen out from App View, so this more complicated infrastructure isn't necessarily the form the network will ultimately take. Hopefully, they'll walk back that plan, because it seems to me that the flexibility it adds mostly opens up new vectors for bad actors who want to reshape traffic on the network to their own ends.  @lrhodes Thank you for the deep technical overview about the current status of the system. @autiomaa You're welcome, but it's really not all that deep. I'm really just going off of the spec as written, along with a few blog posts. The only thing that makes my analysis stand out is the fact that so few of the people covering Bluesky are offering any sort of structural analysis at all. |
Gregory's Server
This is much more complicated than I initially understood, both technically and socially. Since Labeler, App View and Feed Gen are all separate services that can be run independently of both the BGS and PDS, taking full advantage of the network means implicitly trusting four different entities on top of your local host. And even if you don't trust them, they get a say in how (or if) your posts are received by others on the network. I guess that's what #Bluesky means by the "reach layer."