eibhearPublic/blueskyArchitecture
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
blueskyArchitecture/BlueskyArchitecture.org

18 KiB
Raw Blame History

Bluesky Architecture compared to other social media services

Introduction

Boo!

General social media architectures

Simplistic view 1/2 – overview

file:structurizr-1-001-GenericSocial-01.png

Simplistic view 2/2 – services

file:structurizr-1-002-GenericSocial-02.png

  • 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

file:structurizr-1-003-RealisticSocial-01.png

More realistic view 2/4 – basic services

file:structurizr-1-004-RealisticSocial-02.png

  • 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

file:structurizr-1-005-RealisticSocial-03.png

  • 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

file:structurizr-1-006-RealisticSocial-04.png

  • 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

file:structurizr-1-007-FederatedSocial-01.png

Federated services 2/8 – internal, administration and content moderation services

file:structurizr-1-008-FederatedSocial-02.png

  • 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

file:structurizr-1-009-FederatedSocial-03.png

  • 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

file:structurizr-1-010-FederatedSocial-04.png

Federated services 5/8 – federation 3

file:structurizr-1-011-FederatedSocial-05.png

Federated services 6/8 – federation 4

file:structurizr-1-012-FederatedSocial-06.png

Federated services 7/8 – federation 5

file:structurizr-1-013-FederatedSocial-07.png

Federated services 8/8 – federation 6

file:structurizr-1-014-FederatedSocial-08.png

Bluesky

Basic Bluesky 1/2

file:structurizr-1-015-BlueskyBasic-01.png

Basic Bluesky 2/2

file:structurizr-1-016-BlueskyBasic-02.png

  • 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

Bluesky – Identities

Bluesky Identities 1/4

file:structurizr-1-017-BlueskyIdentity-01.png

  • User's typical Bluesky ID is @<user-handle>.bsky.social

    • e.g. @theauldsthretch.bsky.social

  • 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

file:structurizr-1-018-BlueskyIdentity-02.png

Bluesky Identities 3/4

file:structurizr-1-019-BlueskyIdentity-03.png

Bluesky Identities 4/4

file:structurizr-1-020-BlueskyIdentity-04.png

Bluesky – Composable Feeds

Bluesky Composable Feeds 1/3

file:structurizr-1-021-BlueskyFeeds-01.png

  • 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

file:structurizr-1-023-BlueskyFeeds-03.png

Bluesky Composable Feeds 3/3 – Generic feeds

file:structurizr-1-024-BlueskyFeeds-04.png

Bluesky – The AppView

Bluesky AppView 1/3

file:structurizr-1-025-BlueskyAppView-01.png

  • 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

file:structurizr-1-027-BlueskyAppView-03.png

  • 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

file:structurizr-1-028-BlueskyAppView-04.png

Bluesky – The Relay and the PDS

Bluesky Relay 1/2 – 1 PDS into many

file:structurizr-1-029-BlueskyRelay-01.png

  • 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

file:structurizr-1-030-BlueskyRelay-02.png

  • 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

file:structurizr-1-032-BlueskyPDS-01.png

Bluesky PDS 2/3 – An independent PDS: "federation" of a sort

file:structurizr-1-034-BlueskyPDS-03.png

Bluesky PDS 3/3 – PDS: "federation" of a sort

file:structurizr-1-035-BlueskyPDS-04.png

Bluesky – Moderation

Bluesky Moderation 1/2

file:structurizr-1-036-BlueskyModeration-01.png

  • 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

file:structurizr-1-038-BlueskyModeration-03.png

  • 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

file:structurizr-1-038-BlueskyModeration-03.png

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

1

Sarcasm