Bluesky Architecture compared to other social media services
Éibhear Ó hAnluain
eibhear.geo@gmail.com
2024-05-24 Fri 00:00
Introduction
Éibhear Ó hAnluain
- IT professional since 1994
- IT Architect since 2009
- Interested in and promoting federated social services since 2013-ish
- Implementations
- Blog posts
- Representations to government organisations
- This presentation uses diagrams created using Strucutizr
autolayoutthroughout
What is Bluesky
- A new social media service
- Initiated by Jack Dorsey when he was CEO of Twitter
- Vision of a decentralised service
- Inspired by Mike Masnick's 2019 "Protocols, Not Platforms: A Technological Approach to Free Speech" paper
- Plan was for Twitter to move all its users to the new platform when ready
- Company formed in 2021
- Seed funding from Twitter
- Dorsey on the board
- Set up as a public benefit company
- Privatisation of Twitter in October 2022; Bluesky defunded
- 2023, Dorsey deleteds Bluesky account – not meeting his vision
- April 2024, Dorsey resigns from Bluesky board.
General social media architectures
Simplistic view 1/2 – overview
Simplistic view 2/2 – services
- Social media user access the app
- The app interacts with the API
- The API is the gateway for the database of posts, responses, likes, etc.
More realistic view 1/4 – overview
More realistic view 2/4 – basic services
- Social media user access the app
- The app interacts with the API
- The API is the gateway for the database of posts, responses, likes, etc.
- The API also captures data for building profiles of users for targeting purposes
- The algorithmic feed generator guides the API on what posts to place into the app's feed
More realistic view 3/4 – the algorithm
- Social media user access the app
- The app interacts with the API
- The API is the gateway for the database of posts, responses, likes, etc.
- The API also captures data for building profiles of users for targeting purposes
- The algorithmic feed generator guides the API on what posts to place into the app's feed
- Algorithmic feeds are created by the service administrator, using an app only they have access to
More realistic view 4/4 – content moderation
- Social media user access the app
- The app interacts with the API
- The API is the gateway for the database of posts, responses, likes, etc.
- The API also captures data for building profiles of users for targeting purposes
- The algorithmic feed generator guides the API on what posts to place into the app's feed
- Algorithmic feeds are created by the service administrator, using an app only they have access to
- Moderation is also performed by a member of the service's staff, using a dedicate app and services the the user doesn't have access to
Federated social media services
Federated services 1/8 – overview
Federated services 2/8 – internal, administration and content moderation services
- Same as before, the user access the service through an App that uses an API
- As federated services are small, the administrator and the moderator are the one person
- No algorithmic feeds, though
- not popular in the fediverse community
- difficult to implement in a federated environment.
Federated services 3/8 – federation 1
- Same as before, the user access the service through an App that uses an API
- As federated services are small, the administrator and the moderator are the one person
- No algorithmic feeds, though
- not popular in the fediverse community
- difficult to implement in a federated environment.
- Federation service to push activity out to the federated network
- Federation API to take in activity from other nodes
- A logical database of inbound federated posts
- Federation using ActivityPub standard
Federated services 4/8 – federation 2
Federated services 5/8 – federation 3
Federated services 6/8 – federation 4
Federated services 7/8 – federation 5
Federated services 8/8 – federation 6
Bluesky
Basic Bluesky 1/2
Basic Bluesky 2/2
- User interfaces with a client hosted by the AppView
- The AppView includes an API (allowing for 3rd-party and bot-like clients)
- The AppView stores and reads data from the Personal Data Server (PDS)
- Bluesky resolved user identities using "DIDs" (Distributed IDs)
- The Bluesky admin uses a separate service for preparing algorithmic feeds
- The Bluesky moderator applies labels and actions to posts for trust and safety through a dedicated service
- All implemented using a new social protocol call "The AT Protocol", or @proto.
Bluesky – Identities
Bluesky Identities 1/4
- User's typical Bluesky ID is
@<user-handle>.bsky.social- e.g.
@theauldsthretch.bsky.social
- e.g.
- Users can set up their own handle,
@<user-handle>.<domain>. E.g. (and these are all real IDs) …@astrokatie.com– a cosmologist@eibhear.gibiris.org– the author@wyden.senate.gov– a U.S. Senator
- User must control the domain or be a legitimate member of the domain's community
Domain-based handle resolves to a DID, either by DNS or
.well-known:$ dig _atproto.eibhear.gibiris.org TXT ... ;; ANSWER SECTION: _atproto.eibhear.gibiris.org. 3600 IN TXT "did=did:plc:23mysztmt7dh3l5lzhinzafi" $ curl https://theauldsthretch.bsky.social/.well-known/atproto-did did:plc:avzdf5esd7xpbgsgh7lx4kzq
Bluesky Identities 2/4
Bluesky Identities 3/4
Bluesky Identities 4/4
Bluesky – Composable Feeds
Bluesky Composable Feeds 1/3
- Algorithmic feeds use an API
- Allows for independent feeds to be created by 3rd parties
- Users' default feed is Following:
- A chronological feed of posts from those you follow
- Users subscribe to other feeds. Examples:
- Discover – posts that you may be interested in
- Astronomy – Posts relating to astronomy
- Quiet Posters – those you follow but who don't post very often
- The AppView will read data from the independent feeds
- The feeds get relevant posts from the PDS
Bluesky Composable Feeds 2/3 – feeds as a separate application type
Bluesky Composable Feeds 3/3 – Generic feeds
Bluesky – The AppView
Bluesky AppView 1/3
- The main application users interact with the AppView.
- The AppView consists of the application (web, mobile, etc.) and the API
- 3rd-party clients (web, mobile, bots) can be created
- The client is only a part of the AppView
- The AppView implements the lexicon of the service
- Converts the data in the PDS into the social media information
- Now implemented by Bluesky as a separate service
- AppView reads from the feeds services, the moderation services and the PDS itelf
- AppView writes new posts, reposts, likes, replies, etc. to the PDS
Bluesky AppView 2/3 – A 3rd-party independent AppView
- The main application users interact with the AppView.
- The AppView consists of the application (web, mobile, etc.) and the API
- 3rd-party clients (web, mobile, bots) can be created
- The client is only a part of the AppView
- The AppView implements the lexicon of the service
- Converts the data in the PDS into the social media information
- Now implemented by Bluesky as a separate service
- AppView reads from the feeds services, the moderation services and the PDS itelf
- AppView writes new posts, reposts, likes, replies, etc. to the PDS
- Third parties can also develop separate AppViews (the client and APIs) …
- Alternatives to Bluesky's own AppView
- Implement a new lexicon for, say, video sharing, long-form posts, etc.
Bluesky AppView 3/3 – Generic AppView
Bluesky – The Relay and the PDS
Bluesky Relay 1/2 – 1 PDS into many
- Initially, Bluesky had just 1 PDS
- Separated out into multiple PDSs for performance reasons
Bluesky Relay 2/2 – Relay, as a proxy to the PDSes
- Initially, Bluesky had just 1 PDS
- Separated out into multiple PDSs for performance reasons
- Interfaces for reading PDSs now proxied through the Relay
- The Relay stores metadata and indexes/indices of posts
- All information about posts are read from the Relay
- the AppView
- algorithmic feeds services
- moderation
- AppView still writes to the PDS (new posts, etc.)
- With the Relay, we can now have independent, self-hosted, PDSs.
Bluesky PDS 1/3 – An independent PDS: "federation" of a sort
Bluesky PDS 2/3 – An independent PDS: "federation" of a sort
Bluesky PDS 3/3 – PDS: "federation" of a sort
Bluesky – Moderation
Bluesky Moderation 1/2
- Moderation separated out as a distinct service
- Moderation tooling reads from the Relay
- Bluesky maintains and operates the top-level moderation
- Suppresses the really bad stuff, like illegal and abusive material
- and really, really, really bad stuff like copyright infringement1
- But separate moderation services can be implemented by 3rd parties
Bluesky Moderation 2/2 – A 3rd-party independent Moderation service
- Moderation separated out as a distinct service
- Moderation tooling reads from the Relay
- Bluesky maintains and operates the top-level moderation
- Suppresses the really bad stuff, like illegal and abusive material
- and really, really, really bad stuff like copyright infringement
- But separate moderation services can be implemented by 3rd parties
- User subscribes to moderation service
- Users' feeds have material removed or elided by the moderation service
- User can't unsubscribe from Bluesky's moderation
Bluesky
Bluesky – Current architecture
Bluesky – Roadmap
Planned for 2024
- Private/Direct messages (DMs)
- E2E Encrypted
- 1:1 initially, but group DMs planned
- Video sharing
- short clips, 90s or so.
- Improved custom feeds
- Improved anti-harassment
- OAuth – for allowing 3rd-party clients to authenticate without an application password
Resources and further reading
- Original Protocols, Not Platforms: A Technological Approach to Free Speech paper
- Bluesky main page
- The ATProtocol specification
- Bluesky documentation and blogs
- Bluesky's github:
- Community (i.e. not governed by the Bluesky company) projects (tools, apps, bots, etc.)
- Original source for this presentation
- Structurizr DSL file