Social graphs are a well-understood technology. Using infrastructure and standardized protocols that are usually de facto controlled by large, commercial platforms, they provide a way of structuring and querying data about individual nodes (often users) in a network and the relationships (edges) between these nodes. They are theoretically extensible, and social graph data can typically also be represented using open standards like RDF which can be published and consumed by other authorities participating in a network. However, trying to enable participation or federation this way is frequently wishful thinking, and does not really facilitate scaling that social graph beyond a particular API representation of rows in one organization’s database.
The Atmosphere — built on AT — presents a different approach. When you write data using Atmosphere APIs, such as by posting to Bluesky, that data is associated with your personal data repository. These personal data repositories can be hosted or migrated anywhere across the Atmosphere. Each Atmosphere app declares its own schema (Lexicon), and reads and writes its own set of fields. These fields can be read by any other app built on the Atmosphere, allowing users to both a) own and b) span their graphs across the network.
Each of our SDKs are moving towards being more Lexicon-forward. This way, all of our application endpoints, OAuth permissions, and data models all resolve to the same URI. We really like to use the fundamental building blocks of the internet this way as much as possible — that’s why, for example, Bluesky handles look so much like real URLs by default (and anyone with a *.bsky.social username can use it as a URL on its own). We want to remind everyone how lovable these web fundamentals are in the first place, by giving developers the opportunity to build on AT, to reuse data across applications, and develop their own use cases. In this talk, I’ll demo some features for backlinking, backfilling, and looking forward with the AT Protocol.