Webinar: Implementing Clean Architecture in Next.js (Sponsored)
In this free on-demand workshop, Lazar Nikolov will teach you all about implementing Clean Architecture in Next.js. It will dive deep into what clean architecture *actually* is, what problems it solves, and how to implement it in a Next.js application with Sentry.
Disclaimer: The details in this post have been derived from the Bluesky Official Documentation and Research Papers. All credit for the technical details goes to the Bluesky engineering team and the developers involved in creating the AT Protocol. The links to the original articles and papers are present in the references section at the end of the post. We’ve attempted to analyze the details and provide our input about them. If you find any inaccuracies or omissions, please leave a comment, and we will do our best to fix them.
Bluesky is the relatively new social media platform in town. It is a decentralized social media platform designed to offer users greater control, interoperability, and transparency compared to traditional, centralized social networks.
Built on the AT Protocol (Authenticated Transfer Protocol), Bluesky enables a new way of managing online identity, content, and interactions while preserving the user experience of conventional social media platforms.
For reference, the AT Protocol is a federated protocol for large-scale distributed social applications. Being federated is essentially the main selling point of Bluesky. Here, the term “federated” signifies that the various components of the system can have multiple groups running them and that they communicate with each other. For example, think of a system like an email. Gmail, Yahoo, and Outlook are separate email providers, but they can still send and receive emails from each other. No single company owns “email”.
The primary goal of Bluesky is to break the control of a single corporation over user data, moderation policies, and content discovery algorithms. Unlike traditional social networks, where users are locked into a platform, Bluesky allows users to retain their identity, migrate accounts, and customize their experience through modular services.
In other words, Bluesky’s unique design philosophy allows the users to engage without platform control. The platform now has almost 30 million users and is growing steadily.
In this article, we will look at Bluesky’s architecture and its use of the AT protocol to make things possible.
Why Decentralization is Important?
For years, social media platforms have been controlled by large corporations. These companies create rules, control algorithms, and decide what content gets seen. Much of this happens without transparency.
If they change policies or ban users, there’s little a user can do. This lack of control over personal data and content moderation has led to a push for decentralized social networks, where users can potentially have more freedom and ownership.
However, many existing decentralized platforms come with their own set of challenges:
Users may join independent servers, making it difficult to move to another server without losing identity or followers.
Lack of a global search index, making it hard to discover and interact with new people beyond direct connections.
Lack of structured moderation tools, which means harmful content can spread unchecked.
Bluesky aims to solve these problems through a combination of decentralization and usability by:
Allowing user migration without losing followers, thanks to Decentralized Identifiers (DIDs).
Using Relays to index the entire network, ensuring content is discoverable.
Separating speech from reach, so users can filter content without restricting free expression.
How Does Bluesky Work?
As mentioned, Bluesky is built on the AT Protocol.
The AT Protocol consists of several key components that work together to store, distribute, and curate content without relying on a single centralized entity.
The diagram below shows a high-level architecture of Bluesky’s Federated Architecture.
1 - Personal Data Servers (PDS)
Each user has a repository or a collection of records containing their posts, likes, follows, and other interactions. Also, every action a user takes (for example, posting a message or liking a post) creates a new record in their repository. The repository structure is cryptographically signed to ensure data integrity. Think of the repository as a version-controlled record store (similar to a Git repository).
These repositories are managed by Personal Data Servers (PDS).
A PDS is responsible for storing user data and managing authentication. It is like the user’s agent within the network. You can think of the PDS as a service that runs user repositories, exposing HTTP endpoints and WebSockets for communication.
PDSes can be hosted by companies, independent providers, or even by users themselves, resulting in flexible data ownership.
This does not mean that every user needs to run and manage a PDS on their machine. Similar to how email services work, users can sign up for a PDS hosted by a provider. For example, a user can opt for Bluesky’s default hosting. Bluesky runs many PDSes, where each PDS runs as a completely separate service in the network. More advanced users can self-host their PDS on a private server or VPS.
2 - Relays
Relays act as network-wide content aggregators that collect and distribute user-generated data.
Instead of each user or server handling network-wide indexing, relays create a global index of posts, likes, and social connections to ensure content is discoverable.
They crawl all known PDSes and subscribe to their real-time updates. They also filter out malformed, illegal, or high-volume spam before passing updates to other components.
Bluesky currently operates the default relay, which indexes posts, likes, and follows across the network. However, in the future, third-party organizations, developers, or individuals can run their Relay nodes, allowing for diverse indexing strategies such as community-specific relays, interest-based relays, or censorship-resistant relays.
See the diagram below:
3 - App Views
App Views process data from relays and generate structured feeds that users see in their clients. They store aggregated statistics (like counts of likes and replies) and enforce moderation policies by blocking certain interactions based on user preferences.
Bluesky provides an official App View, which powers the default feed that users see. This App View curates content, applies moderation policies, and displays posts in a user-friendly manner. However, developers and communities can create custom App Views that provide alternative ranking algorithms, filter out certain types of content, and offer specialized feed experiences.
Unlike traditional social networks, where a central company controls recommendation algorithms, Bluesky allows multiple competing App Views that users can choose from. Users can also choose multiple App Views based on their preferences.
How Do These Components Work Together?
Here’s a simple process flow that demonstrates how the various components come together to support the Bluesky experience:
A user writes a post using the Bluesky app. Each post requires two fields: text and createdAt (timestamp). The post is stored as a record in their PDS and added to their cryptographically signed repository. This repository acts like a public ledger, making it easy to verify that the content has not been altered.
The user’s PDS pushes updates to a relay that verifies the signature and stores a copy of the record. The relay notifies all App Views and feed generators that a new post is available.
App Views query the relay for new content, fetch relevant posts, and apply moderation rules if necessary. They generate custom feeds based on user preferences and display them in client apps.
When another user likes or replies to the post, their PDS creates a new record reflecting this action. This action is sent to the relay, which updates the global index. The original poster’s App View retrieves the latest interaction and updates the post’s engagement statistics.
The diagram below tries to show this flow:
User Identity and Account Portability in Bluesky
Bluesky is designed to give users full control over their identity, making it different from traditional social media platforms, where accounts are locked to a single service provider.
The AT Protocol uses Decentralized Identifiers (DIDs) as persistent, long-term account identifiers to create permanent user identities independent of any single server or provider.
A DID is a cryptographic identifier that uniquely represents a user across the network.
Unlike traditional usernames tied to a specific server, a DID remains the same even if the user switches providers.
The DID is recorded in a distributed registry so that it cannot be altered or deleted by a hosting provider.
Each DID has two key pairs:
Signing Key: Used to verify user actions like posting or liking content.
Recovery Key: Helps the user restore access to their identity if their primary key is lost or compromised.
DIDs provide a self-sovereign identity, meaning that users own and control their identity without reliance on a central authority. While users have a DID, they also have a readable username for easier recognition. For example: “@username.bsky.social”.
Migration Between Servers
One of the biggest challenges in federated social networks is account migration. Here’s how it works in Bluesky.
A user signs up with a hosting provider (Personal Data Server) and their data is linked to their DID.
If the user wants to migrate to another provider, they export their repository and update their DID to point to the new PDS.
Since followers, posts, and interactions are stored in signed, portable repositories, migration is seamless. Followers do not need to re-follow the user.
This system allows users to change providers without losing their identity or network. Users can also retain their social graph even if a provider shuts down. Users can also host their PDS if they prefer self-sovereignty over third-party hosting.
Security and Privacy Considerations
Since each DID is cryptographically linked to the user’s identity, it cannot be forged or stolen.
Even if a hacker takes over a username (“@someone.bsky.social”), they cannot impersonate the original DID, preventing identity theft. Users can verify each other’s identity using DID resolution tools, similar to how SSL certificates validate websites.
Users have a recovery key that allows them to regain control over their account in case of a security breach.
Content Discovery and Custom Feeds in Bluesky
Content discovery and feeds are one of Bluesky’s key innovations.
In Bluesky, content is not stored on a single server or database. Instead, relays act as global content indexers that aggregate and distribute posts across the network.
Here’s what the relays do:
They continuously crawl Personal Data Servers (PDSes) to collect and update posts, likes, and follows.
They store indexed metadata (such as post timestamps, authorship, and interactions) to enable fast content discovery.
When a user searches for a post or follows someone, their client app queries the relay, which returns relevant results based on the indexed data.
In a traditional social media platform, the company that owns the service also decides how content is ranked and displayed in user feeds. This often leads to non-transparent algorithmic filtering, where users are shown posts based on engagement metrics.
Bluesky removes this centralized control by introducing App Views, which play the role of independent feed curators. Developers can create publicly available feed generators anyone can subscribe to. These feeds may focus on specific topics such as technology news, verified accounts, or trending discussions.
Moderation and Content Control in Bluesky
In Bluesky, users can post anything they want. Their PDS stores these records, ensuring that their content remains available. No single authority can delete a post from the entire network. Even if a provider refuses to display it, the data remains intact in the user’s repository.
However, just because a post exists does not mean it will be indexed, promoted, or widely visible. Moderation services and App Views determine how content appears in feeds and searches. This means harmful or offensive content can be downranked, filtered, or hidden, but not erased from a user’s storage.
This concept is called “separation of speech and reach”, which allows for free expression while maintaining content control at different levels.
Labelers and Moderation Services
Bluesky does not enforce a single, centralized moderation system. Instead, it allows multiple independent moderation services, which work together to flag, filter, and categorize content. This includes:
Network takedowns which filter the content from the APIs.
Labels placed on content by moderation services.
User controls such as mutes and blocks.
Labelers are third-party moderation services that tag content with appropriate labels. Imagine a label as a metadata to categorize the content. These labels do not remove content but allow App Views and users to apply filters based on their preferences. Users can choose which Labelers they trust, meaning moderation is customizable rather than forced. All of this information is stored on the user’s data server.
Bluesky provides both individual-level and community-level blocking tools to ensure user safety and content control. Some features are as follows:
Users can block individuals, preventing them from seeing or interacting with their posts.
Users can subscribe to blocklists maintained by third-party moderation groups.
Blocking is publicly visible, meaning other users can see when someone is blocked. This helps prevent users from repeatedly engaging with people who have blocked them.
Conclusion
Bluesky represents a major step forward in decentralized social networking, offering a platform where users have true control over their identity, data, and content experience.
Through the AT Protocol, Bluesky ensures that social interactions remain scalable, transparent, and resistant to corporate control.
Looking ahead, Bluesky’s future will be shaped by user adoption, third-party innovation, and continued improvements to the AT Protocol. Some key expected developments include:
Expansion of App Views and Feed Generators: Encouraging greater diversity in content discovery.
Increased Relay and Moderation Services: Creating more robust, user-driven content curation.
Integration with Other Decentralized Systems: Expanding interoperability across web3 and federated platforms.
References:
SPONSOR US
Get your product in front of more than 1,000,000 tech professionals.
Our newsletter puts your products and services directly in front of an audience that matters - hundreds of thousands of engineering leaders and senior engineers - who have influence over significant tech decisions and big purchases.
Space Fills Up Fast - Reserve Today
Ad spots typically sell out about 4 weeks in advance. To ensure your ad reaches this influential audience, reserve your space now by emailing sponsorship@bytebytego.com.
