3 ms·

So, you're making stuff up that obviously has no basis in reality here. Migration would be impossible because the bsky.app PDS wouldn't allow anyone to access

So, you're making stuff up that obviously has no basis in reality here. Migration would be impossible because the bsky.app PDS wouldn't allow anyone to access the data except for the bsky.app relay. other appviews wouldn't display bsky.app data because both the PDS and relay would block them.

OneDeuxTriSeiGo 1y ago
No. That's just not remotely close to true or feasible. > So, you're making stuff up that obviously has no basis in reality here. I cannot understand why you are claiming this. I'm basing off the actual architecture and the way the parts interact. The design is just not feasible for locking down. Doing so completely breaks the model and it still leaks like a sieve if you try to. ---------- > Migration would be impossible because the bsky.app PDS wouldn't allow anyone to access the data except for the bsky.app relay. Nope. Migration is still fully possible. Migration doesn't happen via the relay or any PDS->PDS mechanism. Migration is done via the client. The client/user runs operations on the source PDS, the destination PDS, and the DID registry. All the data is transported between by the client. Specifically the way it works is you export/backup your information from your current PDS (in the form of a CAR file + blobs). Technically this step is optional. Even if the PDS goes offline or becomes hostile you can actually largely reconstruct this data from the network. Then you "create a new account" on the new PDS and upload your data that you backup up/recovered onto the new PDS. Then you update your DID to point to the new PDS. And finally you deactivate the account on the original PDS (basically saying I no longer store stuff here anymore). This is part of the reason why migration tooling is a bit bumpy. Your JS script or app has to do the entire process by itself rather than letting the backends handle it. However it does make them extraordinarily resistant to data loss and/or takeover. ---------- > other appviews wouldn't display bsky.app data because both the PDS and relay would block them. Relays work via gossip. If you can see the relay at any point, you can gossip 100% of their contents to another relay. In the event bluesky PBLLC locked down their appview and PDS, they'd still have to make the relay open or everything breaks. Feed providers need access to the firehose. Labelers/Moderation Services need access to the firehose. And so on. Everything is built with an assumption of a public firehose and if you lock down the firehose, all you need is one person to listen to the locked down firehose to 100% replicate it and gossip onto any other relay.
hoidofyolen 1y ago
First of all, Bluesky the company would have to implement auth on the communication between relay and AppView, cut off everyone from using their relay, and specifically stop ingesting content from non-Bluesky PDSs. There would be time when we realize that's happening to get another AppView up and running. There are arguably enough resources in either the ATproto dev community or other funding sources that another AppView could pop up within a week or two, and be maintained by the community for months without issue. And Bluesky wouldn't likely stop existing altogether, so people would log into Bluesky, see the news (or hear it elsewhere), and see people talking about how to get access to your account. Secondly, while you're right that most people don't have copies of their repos, some copies of the entire network exist in the community, as well as copies of the PLC Directory. Within a couple weeks we would have community run versions of the AppView, PDSs, Relays, and PLC, and some seriously pissed off community members who would now want to do everything they can to take up the mantle temporarily. Soon Bluesky the app, as well as Instagram and Twitter, would be flooded with tutorials of how to recover your accounts and migrate to another PDS. If your point is that we'd lose at least half of the users of Bluesky, then yea probably. But ATproto would be just fine, and if people want to get their data back they likely can, as long as they can stomach a little work. And that process is getting easier all the time.
- immibis 1y ago
  Who would use the new network? It would just be Mastodon Vs Twitter again. All the people you want to read the tweets of would (still) be on Blue Sky, not Black Sky or Red Sky or President Zelen Sky or whatever. "Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that and just because they use something decentralised-ish today doesn't mean they have to keep using that thing if they don't want to" challenge (difficulty: impossible)
  - OneDeuxTriSeiGo 1y ago
    > "Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that It's not just a technical restriction though. It's also a legal restriction. Bluesky PBLLC is a public benefit corporation and they are at least in moderate part beholden to their charter. More importantly, their initial investment contract requires them to further the decentralisation of social media and exposes them to legal consequences should they deviate from that mission. Those combined make it effectively impossible for them to lock in bluesky. Doing so would require technical changes that would be under no uncertain terms against the charter of the company and against the terms of the investment contracts that initially funded the company. It's a poison pill that would kill the company and destroy any "shareholder value" the moment they try to lock down the service or lock in the users. You aren't going to see them try this type of brazen lock-in because it'd be explicitly harmful to every investor/VC and saddle the company in legal hell until it smoulders into ash.

OneDeuxTriSeiGo 1y ago

No. That's just not remotely close to true or feasible. > So, you're making stuff up that obviously has no basis in reality here. I cannot understand why you are claiming this. I'm basing off the actual architecture and the way the parts interact. The design is just not feasible for locking down. Doing so completely breaks the model and it still leaks like a sieve if you try to. ---------- > Migration would be impossible because the bsky.app PDS wouldn't allow anyone to access the data except for the bsky.app relay. Nope. Migration is still fully possible. Migration doesn't happen via the relay or any PDS->PDS mechanism. Migration is done via the client. The client/user runs operations on the source PDS, the destination PDS, and the DID registry. All the data is transported between by the client. Specifically the way it works is you export/backup your information from your current PDS (in the form of a CAR file + blobs). Technically this step is optional. Even if the PDS goes offline or becomes hostile you can actually largely reconstruct this data from the network. Then you "create a new account" on the new PDS and upload your data that you backup up/recovered onto the new PDS. Then you update your DID to point to the new PDS. And finally you deactivate the account on the original PDS (basically saying I no longer store stuff here anymore). This is part of the reason why migration tooling is a bit bumpy. Your JS script or app has to do the entire process by itself rather than letting the backends handle it. However it does make them extraordinarily resistant to data loss and/or takeover. ---------- > other appviews wouldn't display bsky.app data because both the PDS and relay would block them. Relays work via gossip. If you can see the relay at any point, you can gossip 100% of their contents to another relay. In the event bluesky PBLLC locked down their appview and PDS, they'd still have to make the relay open or everything breaks. Feed providers need access to the firehose. Labelers/Moderation Services need access to the firehose. And so on. Everything is built with an assumption of a public firehose and if you lock down the firehose, all you need is one person to listen to the locked down firehose to 100% replicate it and gossip onto any other relay.

hoidofyolen 1y ago

First of all, Bluesky the company would have to implement auth on the communication between relay and AppView, cut off everyone from using their relay, and specifically stop ingesting content from non-Bluesky PDSs. There would be time when we realize that's happening to get another AppView up and running. There are arguably enough resources in either the ATproto dev community or other funding sources that another AppView could pop up within a week or two, and be maintained by the community for months without issue. And Bluesky wouldn't likely stop existing altogether, so people would log into Bluesky, see the news (or hear it elsewhere), and see people talking about how to get access to your account. Secondly, while you're right that most people don't have copies of their repos, some copies of the entire network exist in the community, as well as copies of the PLC Directory. Within a couple weeks we would have community run versions of the AppView, PDSs, Relays, and PLC, and some seriously pissed off community members who would now want to do everything they can to take up the mantle temporarily. Soon Bluesky the app, as well as Instagram and Twitter, would be flooded with tutorials of how to recover your accounts and migrate to another PDS. If your point is that we'd lose at least half of the users of Bluesky, then yea probably. But ATproto would be just fine, and if people want to get their data back they likely can, as long as they can stomach a little work. And that process is getting easier all the time.

immibis 1y ago
Who would use the new network? It would just be Mastodon Vs Twitter again. All the people you want to read the tweets of would (still) be on Blue Sky, not Black Sky or Red Sky or President Zelen Sky or whatever. "Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that and just because they use something decentralised-ish today doesn't mean they have to keep using that thing if they don't want to" challenge (difficulty: impossible)
- OneDeuxTriSeiGo 1y ago
  > "Convince a HN user that a corporation with the ability to cut you off from your feed sources for more profit won't do exactly that It's not just a technical restriction though. It's also a legal restriction. Bluesky PBLLC is a public benefit corporation and they are at least in moderate part beholden to their charter. More importantly, their initial investment contract requires them to further the decentralisation of social media and exposes them to legal consequences should they deviate from that mission. Those combined make it effectively impossible for them to lock in bluesky. Doing so would require technical changes that would be under no uncertain terms against the charter of the company and against the terms of the investment contracts that initially funded the company. It's a poison pill that would kill the company and destroy any "shareholder value" the moment they try to lock down the service or lock in the users. You aren't going to see them try this type of brazen lock-in because it'd be explicitly harmful to every investor/VC and saddle the company in legal hell until it smoulders into ash.