7 ms·

> For a lot of stuff though ATProto is built in a way that you shouldn't have to host your own; you can implement your own algorithmic feed that reads from the

by mdasen 1y ago

> For a lot of stuff though ATProto is built in a way that you shouldn't have to host your own; you can implement your own algorithmic feed that reads from the Bluesky Relay's firehose, or your own frontend that still gets data from the Bluesky AppView. ATProto isn't "built this way". Twitter was also built in a way where you could implement your own stuff - and then Twitter took that away. With Mastodon, there is one large instance (controlled by the non-profit Mastodon gGmbH). If they tried closing themselves off, their users would be losing access to the majority of people in the network. Plus, while non-profits aren't perfect, they don't have VC investors to answer to. Bluesky could decide to stop publishing the firehose or restrict its APIs - just as Twitter did. Given that they control 99.55% of the network, they can close it off without worrying about their users losing access to anything. And Bluesky is a for-profit company that has raised around $30M in VC. What you talk about isn't a feature of ATProto. It's a feature of being centralized and having a company willing to let you use their servers for free (at least for now). This was the case with Twitter for a long time. You could read the Twitter firehose and build your own apps and frontends getting data from the Twitter APIs - just as you can do from Bluesky today. But unless there's a reason why shutting off the firehose/APIs would be bad for Bluesky, they can do that at anytime. It might anger some users (as Reddit and Twitter both did), but they control the network and network effects are powerful. For most Bluesky users, they'd continue using it because they aren't there for some open protocol. They're on Bluesky because Twitter became a nazi bar. Until we see real decentralization with ATProto, it's just a centralized network like Twitter or Reddit which hasn't shut off its firehose and public API yet. Hopefully that won't happen, but it certainly could.

kyle-rb 1y ago
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.
OneDeuxTriSeiGo 1y ago
> ATProto isn't "built this way". ATProto is built this way. "Closing off bluesky" would be an extraordinarily non-trivial process and would break basically everything. This is in large part why private data isn't a thing yet. The architecture is diametrically opposed to it. > Bluesky could decide to stop publishing the firehose or restrict its APIs - just as Twitter did. They could "technically" completely rearchitect their application frontend and backend to do this but any effort to do so would be visible from miles away given the architecture and warning claxons would start ringing immediately. > And Bluesky is a for-profit company that has raised around $30M in VC. Bluesky PBLLC is a for-profit "public benefit corporation" for what it's worth and the way they are structured would open them up to legal consequences if they were to move diametrically opposed to the mission they were founded on. Not just because they are a PBLLC but because their initial investment funding was drawn up under an explicit contract that views moves against "the development of decentralised social media" as a violation of the terms of that contract.
galactus 1y ago
there are already independent relays running. a full relay (which is open source software) costs around 30 USD per month to operate

by mdasen 1y ago

kyle-rb 1y ago

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.

OneDeuxTriSeiGo 1y ago

> ATProto isn't "built this way". ATProto is built this way. "Closing off bluesky" would be an extraordinarily non-trivial process and would break basically everything. This is in large part why private data isn't a thing yet. The architecture is diametrically opposed to it. > Bluesky could decide to stop publishing the firehose or restrict its APIs - just as Twitter did. They could "technically" completely rearchitect their application frontend and backend to do this but any effort to do so would be visible from miles away given the architecture and warning claxons would start ringing immediately. > And Bluesky is a for-profit company that has raised around $30M in VC. Bluesky PBLLC is a for-profit "public benefit corporation" for what it's worth and the way they are structured would open them up to legal consequences if they were to move diametrically opposed to the mission they were founded on. Not just because they are a PBLLC but because their initial investment funding was drawn up under an explicit contract that views moves against "the development of decentralised social media" as a violation of the terms of that contract.

galactus 1y ago

there are already independent relays running. a full relay (which is open source software) costs around 30 USD per month to operate