Welcome to a new short series on Bluesky and how the network works. Bluesky recently releasedmore information on their plans for third party moderation services. While writing about their plans, I realised that to properly explain how it works, I first needed to explain how the network is designed to function.
Most people understand the fediverse in terms of separate instances. Every instance can be a social network in itself, and by connecting with other instances form a larger network, the fediverse. This makes it easier to understand where content moderation happens: every instances has their own content moderation, own moderators and their own rules.
The Bluesky network and the AT Protocol function differently. There are different types of servers; servers for data storage, servers for data aggregation, etc. As such, content moderation happens in different places on the network. To properly explain how it works, the benefits and tradeoffs, as well as the unknowns, I am publishing a short series on Bluesky, how the network functions, and how and where content moderation happens.
In this first episode: the parts that make up the network and allow it to work.
The basic components
The Bluesky network consists of the following parts:
A Personal Data Server (PDS) that hosts all account data. It contains information about your accounts, and is where all your personal data is stored.
A Relay looks for all the PDS’s in the network, takes in all their data, and merges it together to outputs one big stream that is used by other parts of the network. The Relay puts out the data in a machine-readable format, which is often called a firehose.
AppView takes the data from the Relay, and processes it so that it is more meaningful for apps. Examples of the processing that AppView does: counting the amount of likes that a post gets, collecting all replies to a post and organising them into a thread. It also generates your “following” feed, by creating a reverse-chronologically ordered feed of posts made by the accounts that you follow.
An app, whether that is the official Bluesky mobile app or a third party website like deck.blue. The app takes the data from AppView and presents it in a nice format for people read on their preferred device.
With these four components we can imagine a basic social network:
If you open the official Bluesky app on your phone and look at the “following feed”, the data flows as follows:
All PDS’s => Relay => AppView => App.
If you then create a post and hit send, data goes from your app directly back to the PDS where your account is hosted.
Custom feeds and moderation
There are four more components to the Bluesky network: feed generators, labellers, the moderation service, and the Identity Directory.
A feed generator creates the custom feeds, using some form of algorithm. These custom feeds can be anything from a feed with the posts with the most likes in the last 24 hours, a feed of posts that contain specific terms, or anything else.
A feed generator takes data from a Relay, performs the calculations to take the raw data into a custom feed, and sends it to the AppView. The AppView then performs some final steps and sends it to your app so you can see the custom feed.
Labellers. Labelling services perform moderation activities by applying labels to a post. People can determine how they want to handle labelled content. An example of a label can be ‘Sexually Suggestive’, and people can determine if they want their app to either show, hide or warn about posts that contain the label.
A Labelling service takes data from the AppView, processes it, and then sends it back to the AppView
The moderation system, called Ozone, that allows moderators to take moderation action, such as taking down posts or accounts. This tool has the least amount of information on it, and it is not visible Federation Architecture documentation. The update this week by the Bluesky organisation shows that the system is called Ozone, and that they are in the process of making it open-source and available for others to use.
The tool at least allows moderators to alter data in the PDS, as that is where account data lives.
Every account on the Bluesky network has a unique identifier, called a DID. A DID is a unique string of random numbers and letters, and cannot change. Every account also has a handle, which is your username. New accounts start with youraccountname.bsky.social as a handle. The network also allows you to change your handle to a domain name that you own, which allows for easy verification. The information about which DID corresponds to which handle is stored in the DID PLC Directory.
Now we have all the components that together make up the Bluesky network. In the next part, I’ll take a look at decentralisation and federation, explaining for every part how it will play a role in decentralisation and federation.
Thanks to Kuba Suder for feedback on a first draft.
Add comment