ATProto a.k.a. The Atmosphere, is the decentralized storage layer that powers BlueSky, but should not be confused with BlueSky, which is essentially a Twitter clone.
ATProto is extremely cool. Identities store their data in a federated storage engine (in the common case BlueSky runs one, but also Europe has one https://eurosky.tech/). All data is public. Atmosphere applications can read any other apps data. So what is happening with Lopefeed is that a users store a copy of their notebook on their chosen storage server using their identity.
What is extremely cool is that an application can add application cross links, so you can associate a notebook with a bluesky post, or a standard.site publication, and say, this this notebook is associated with this specific BlusSky post. Or this person on BlueSky is the same author of this notebook.
So then you can start leveraging other apps data, e.g.,show me all the notebooks from people I follow on BlueSky, or sort notebooks by the number of likes on BlueSky, or publish a notebook on as a long form article on standard.site.
So several things are cool.
- the user nominates and controls their own data, its decoupled from the application that defines the service data schema (a.k.a. lexicon in AT:// jargon)
- the user owns their identity, again decoupled from the storage provider layer (a.k.a. PDS)
- Service providers (a.k.a. apps) publish public schema definitions describing the shape of their data and any other service provider is free to read and deep-link them. The application data interoperability problem on Cloud is solved.
So now you don’t need to build a social graph to make a social app. You can just reuse BlueSky’s, if you can convince your users to OAUTH with BlueSky posting permissions, you can offer them the ability to “like” things from your app and stuff.
I have been hard into local software for a little while, but ATProto is the data layer that actually works the way I like for networked services (provided you are ok with the everything is public angle).
Every datum has a DID, which is like a URL, which reflects the collection + key structure .
at://did:plc:r5lx5cznmnj6fftfy4hudgmm/com.lopecode.bundle/khinsen-the-answer
So because of data interoperability there are generic tools to look them up, so now we can see the underlying record that represents an Observable Notebook 1.0 record I made up.
https://atproto-browser.vercel.app/at/did:plc:r5lx5cznmnj6fftfy4hudgmm/com.lopecode.bundle/khinsen-the-answer
So a Lopecode notebook record is a list of blobs with Mime types, which is the low level representation of atproto storage. Which is very mappable to the Notebook datamodel too.