5 ms·

No I think ATProto is "built this way". The firehose is just the output of the Relay. If Bluesky wanted to shut off the firehose, they would have to make change

No I think ATProto is "built this way". The firehose is just the output of the Relay. If Bluesky wanted to shut off the firehose, they would have to make changes to ATProto or stop conforming to ATProto. I understand that Bluesky's conformance to ATProto is just a promise, but it's a better promise than you get from most websites. Also in the meantime, if you migrate to a self-hosted PDS, you can ensure that even if Bluesky restricts access to their Relay's firehose, 3rd party Relay servers can still pick up your posts and publish their own unrestricted firehose.

immibis 1y ago
What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ https://bsky.app/ servers from using their relays? And what if, before they did that, they updated the PDS code so it blocked all relays except for their one? I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app, and 99.9% of users would never notice a difference. Users who had other PDSes would either quit (nobody noticing their departure) or sign up to bsky.app like everyone else. The events of Twitter show it's probably the latter - people bent over backwards to comply with Musk to keep their accounts.
- OneDeuxTriSeiGo 1y ago
  > What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ https://bsky.app/ servers from using their relays? That's not how it works. Appviews pick the relay they use, not the client/user. The relay is used for gossip into the appview (and other things). More importantly, appviews never see the client/user directly. Appviews only talk to the PDS. Really most things other than the client ever only talk to the PDS or listen to the relay. The only thing that ever directly talks to the client is the PDS. The way atproto services generally work is the client configures a series of XRPC requests with HTTP headers to determine what appview, labelers, etc to use and it issues that request to the PDS. The PDS then proxies that request to the appview or wherever and they respond back to the PDS which routes the response back to you. So in a real sense your PDS is not just a data host, but also operates akin to an IRC bouncer. ----- > And what if, before they did that, they updated the PDS code so it blocked all relays except for their one? PDS relay routing, etc is mostly all handled manually via config files,etc so this isn't really a concern. And PDS code is probably the "easiest" part of the ecosystem to hack on which is why there are like 6 different implementations with the majority (like 4) that maintain near feature parity with the "bluesky PDS" software. And importantly, the bluesky PDS is literally a sqlite DB, an OAUTH implementation, some go IPLD data structure manipulation code, and a go XRPC router. It's fairly trivial to hack on as needed. ------ > I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app [...] Migration currently isn't perfect but within ~6 months it should be ironed out by the community at which point migrating off a PDS to another is just a matter of: 1. click button on new PDS to transfer/"create new account". 2. set your new email, password, and list your old/current handle. 3. get auth code via email (one from the new PDS and one from your DID provider) 4. input codes into migrator interface (for whichever migrator you are using) 5. log into your apps again. There are multiple large PDS operators working really really hard to spin up operations (proper backups, failover, HA, etc) so they can run reliably and avoid the "my mastodon instance imploded guess everything is gone" issue. Open federation is only about ~ a year old (plus change) so the community is only just now really reaching the "mature third parties" stage.
  - immibis 1y ago
    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.

immibis 1y ago

What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ https://bsky.app/ servers from using their relays? And what if, before they did that, they updated the PDS code so it blocked all relays except for their one? I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app, and 99.9% of users would never notice a difference. Users who had other PDSes would either quit (nobody noticing their departure) or sign up to bsky.app like everyone else. The events of Twitter show it's probably the latter - people bent over backwards to comply with Musk to keep their accounts.

OneDeuxTriSeiGo 1y ago
> What do you think would happen if the Bluesky company suddenly blocked everyone but https://bsky.app/ https://bsky.app/ servers from using their relays? That's not how it works. Appviews pick the relay they use, not the client/user. The relay is used for gossip into the appview (and other things). More importantly, appviews never see the client/user directly. Appviews only talk to the PDS. Really most things other than the client ever only talk to the PDS or listen to the relay. The only thing that ever directly talks to the client is the PDS. The way atproto services generally work is the client configures a series of XRPC requests with HTTP headers to determine what appview, labelers, etc to use and it issues that request to the PDS. The PDS then proxies that request to the appview or wherever and they respond back to the PDS which routes the response back to you. So in a real sense your PDS is not just a data host, but also operates akin to an IRC bouncer. ----- > And what if, before they did that, they updated the PDS code so it blocked all relays except for their one? PDS relay routing, etc is mostly all handled manually via config files,etc so this isn't really a concern. And PDS code is probably the "easiest" part of the ecosystem to hack on which is why there are like 6 different implementations with the majority (like 4) that maintain near feature parity with the "bluesky PDS" software. And importantly, the bluesky PDS is literally a sqlite DB, an OAUTH implementation, some go IPLD data structure manipulation code, and a go XRPC router. It's fairly trivial to hack on as needed. ------ > I'm not asking what you would do. I'm asking what would happen because of what everyone does. I think the name "Bluesky" would refer to the fully centralized bsky.app [...] Migration currently isn't perfect but within ~6 months it should be ironed out by the community at which point migrating off a PDS to another is just a matter of: 1. click button on new PDS to transfer/"create new account". 2. set your new email, password, and list your old/current handle. 3. get auth code via email (one from the new PDS and one from your DID provider) 4. input codes into migrator interface (for whichever migrator you are using) 5. log into your apps again. There are multiple large PDS operators working really really hard to spin up operations (proper backups, failover, HA, etc) so they can run reliably and avoid the "my mastodon instance imploded guess everything is gone" issue. Open federation is only about ~ a year old (plus change) so the community is only just now really reaching the "mature third parties" stage.
- immibis 1y ago
  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.