joeruelle on Nostr: "AtProto allows users to theoretically move between different services. However, user ...
"AtProto allows users to theoretically move between different services. However, user keys are controlled by the server admin, and users' ability to move servers is dependent on the server's willingness to cooperate."
Some nuance here. If you start by having your PDS hosted by bsky and then pull it away to self-host, from the point you've taken charge none of your rotation keys will remain controlled by Bluesky. (You control the server, server controls the keys, thus you control the keys, no permission needed from anyone.) What's also relevant for your self-hosted PDS is that everything is content-addressed.
The question of pulling away from bsky (as host) in adversarial sense versus an allowed sense is a different question, but point is once you're out you're out, you've got the keys
You can also start off self-hosted and thus half self-hosted control from day one, though pretty much everyone starts off in bsky.
"Bluesky uses DIDs (Decentralized Identifiers) for accounts, but accounts are still managed centrally."
They use DID:WEB and DID:PLC. You can setup your own DID:WEB, which you control, and that DID:WEB plus a download of your repo can potentially be enough for a future adversarial migration. What's centrally managed is the directory (i.e. they are their own ICANN), but that's another tangent.
"Self-hosting is highly restricted: servers are limited to 100 users, and Bluesky can refuse to federate with them."
The idea there is you self host your own PDS (one by one). There is no real federation per say, no real sense of being in charge of others. If there existed two relays then one relay could refuse to index your individually self-hosted PDS (or hosted via some cloud service) while the other relay could agree. (A second independently-run ATProto relay is going up later this year in Europe, or so they say.) Or a relay could index your PDS but a given appview(client) could refuse it. For example bsky-dot-app could refuse while pinksky-dot-app could accept. Importantly though any AppView can pull directly from any PDS (or group of) without a relay in the middle, so at the moment bsky has zero power to stop anyone from from creating an app view that pulls directly from self hosted PDSs.
"Although AtProto is a decentralized protocol, in practice, Bluesky is highly centralized because the vast majority of users rely on bsky.social, which can block entire self-hosted servers."
This is defo the key point, i.e. the flagship demo has eaten the future. That said the term "Bluesky" can mean different things to different people:
- Bluesky the AppView (as in Primal or Damus)
- Bluesky PBLLC the company and team (which is driving ATproto)
- ATproto the protocol itself driven by Bluesky
- The current (and only) ATproto relay (graph service)
The issue is that Bluesky the AppView has all the client usage and the current relay under the PBLLC is doing all the indexing. And that won't change anytime soon, even though there are some neat ATProto versions of Olas, and Comingle and a lot of other clients on Nostr.
Some nuance here. If you start by having your PDS hosted by bsky and then pull it away to self-host, from the point you've taken charge none of your rotation keys will remain controlled by Bluesky. (You control the server, server controls the keys, thus you control the keys, no permission needed from anyone.) What's also relevant for your self-hosted PDS is that everything is content-addressed.
The question of pulling away from bsky (as host) in adversarial sense versus an allowed sense is a different question, but point is once you're out you're out, you've got the keys
You can also start off self-hosted and thus half self-hosted control from day one, though pretty much everyone starts off in bsky.
"Bluesky uses DIDs (Decentralized Identifiers) for accounts, but accounts are still managed centrally."
They use DID:WEB and DID:PLC. You can setup your own DID:WEB, which you control, and that DID:WEB plus a download of your repo can potentially be enough for a future adversarial migration. What's centrally managed is the directory (i.e. they are their own ICANN), but that's another tangent.
"Self-hosting is highly restricted: servers are limited to 100 users, and Bluesky can refuse to federate with them."
The idea there is you self host your own PDS (one by one). There is no real federation per say, no real sense of being in charge of others. If there existed two relays then one relay could refuse to index your individually self-hosted PDS (or hosted via some cloud service) while the other relay could agree. (A second independently-run ATProto relay is going up later this year in Europe, or so they say.) Or a relay could index your PDS but a given appview(client) could refuse it. For example bsky-dot-app could refuse while pinksky-dot-app could accept. Importantly though any AppView can pull directly from any PDS (or group of) without a relay in the middle, so at the moment bsky has zero power to stop anyone from from creating an app view that pulls directly from self hosted PDSs.
"Although AtProto is a decentralized protocol, in practice, Bluesky is highly centralized because the vast majority of users rely on bsky.social, which can block entire self-hosted servers."
This is defo the key point, i.e. the flagship demo has eaten the future. That said the term "Bluesky" can mean different things to different people:
- Bluesky the AppView (as in Primal or Damus)
- Bluesky PBLLC the company and team (which is driving ATproto)
- ATproto the protocol itself driven by Bluesky
- The current (and only) ATproto relay (graph service)
The issue is that Bluesky the AppView has all the client usage and the current relay under the PBLLC is doing all the indexing. And that won't change anytime soon, even though there are some neat ATProto versions of Olas, and Comingle and a lot of other clients on Nostr.