- Identity layer: This is where your identity information (public key, current domain handle, current user repo host) is stored, essentially as a piece of JSON. You can think of it as similar to npm registry where each record is self-verifiable (you can verify we haven’t tampered with it). This layer is very thin. It is currently centrally managed by Bluesky but in the longer term we intend to upstream it into neutral governance outside of the company — potentially similar to ICANN.
- User repo hosting: We provide user hosting as a service for people who sign up to Bluesky (and choose the default option) but you can run your own too. The server itself is open source (we publish both TypeScript source code and a Docker container to run it). We also publish a spec so you can implement it from scratch if you'd like it — essentially, it needs to be able to enumerate records and to provide a WebSocket to listen to their updates. I'd say this layer is already decentralized because anyone can participate in it and run their own server.
- Relay: As an optimization (you don't want your app backend to listen to websockets for every single user repo in the system), we run a node that aggregates and caches the entire known network. That node's called a Relay. It's an optimization and not strictly necessary to the protocol. It's open source. We run the only actively used relay at the moment, but there's nothing stopping you from running your own (at the current usage rate, ingesting all content on the network into your own relay would cost you ~$150/mo). If atproto gains adoption, we expect some major stakeholders to run their own relays for different purposes — big tech companies might want to run them to ensure infra independency, governments might want to run them if they have significantly different opinions on what type of content is acceptable on the entire network, and so on.
- Application backends (view services): These are just normal web app backends so they're decentralized in the same way the web is decentralized. Bluesky's backend is managed by Bluesky, but your own app's backend will be managed by you. You can also create a backend that ingests Bluesky's atproto data (which is kind of the point of atproto). That would let you create complementary or competing products using the same identity system and information already on the network.
- Identity layer: This is where your identity information (public key, current domain handle, current user repo host) is stored, essentially as a piece of JSON. You can think of it as similar to npm registry where each record is self-verifiable (you can verify we haven’t tampered with it). This layer is very thin. It is currently centrally managed by Bluesky but in the longer term we intend to upstream it into neutral governance outside of the company — potentially similar to ICANN.
- User repo hosting: We provide user hosting as a service for people who sign up to Bluesky (and choose the default option) but you can run your own too. The server itself is open source (we publish both TypeScript source code and a Docker container to run it). We also publish a spec so you can implement it from scratch if you'd like it — essentially, it needs to be able to enumerate records and to provide a WebSocket to listen to their updates. I'd say this layer is already decentralized because anyone can participate in it and run their own server.
- Relay: As an optimization (you don't want your app backend to listen to websockets for every single user repo in the system), we run a node that aggregates and caches the entire known network. That node's called a Relay. It's an optimization and not strictly necessary to the protocol. It's open source. We run the only actively used relay at the moment, but there's nothing stopping you from running your own (at the current usage rate, ingesting all content on the network into your own relay would cost you ~$150/mo). If atproto gains adoption, we expect some major stakeholders to run their own relays for different purposes — big tech companies might want to run them to ensure infra independency, governments might want to run them if they have significantly different opinions on what type of content is acceptable on the entire network, and so on.
- Application backends (view services): These are just normal web app backends so they're decentralized in the same way the web is decentralized. Bluesky's backend is managed by Bluesky, but your own app's backend will be managed by you. You can also create a backend that ingests Bluesky's atproto data (which is kind of the point of atproto). That would let you create complementary or competing products using the same identity system and information already on the network.
Hope this helps!