←back to thread

Are we decentralized yet?

(arewedecentralizedyet.online)
487 points Bogdanp | 1 comments | | HN request time: 0s | source
Show context
d4mi3n ◴[] No.45077410[source]
Neat! I'm not surprised at the findings here. BlueSky (for the average user) is pretty much a drop in replacement for Twitter.

Despite the smaller total numbers in Mastadon, it's great to see that the ecosystem seems to be successfully avoiding centralization like we've seen in the AT-Proto ecosystem.

I suspect that the cost of running AT proto servers/relays is prohibitive for smaller players compared to a Mastadon server selectively syndicating with a few peers, but I say this with only a vague understanding of the internals of both of these ecosystems.

replies(6): >>45077507 #>>45077986 #>>45078151 #>>45078889 #>>45079652 #>>45080382 #
kyle-rb ◴[] No.45078151[source]
Running a PDS server for yourself and a few friends is not very expensive afaik, but there's also not much benefit to doing so, because the point of the PDS is to have a clean separation between your own data and the rest of the network.

The expensive things in ATProto are the Relay (crawls/listens to PDSs to produce the firehose) and the AppView (keeps a DB of all posts/likes/etc to serve users' requests). Expensive at scale anyway; if you want your own small network for hosting non-Bluesky posts (like WhiteWind's longer character limit), the event volume will be manageable.

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.

replies(2): >>45078223 #>>45078586 #
mdasen ◴[] No.45078586[source]
> 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.

replies(3): >>45079331 #>>45081774 #>>45082320 #
kyle-rb ◴[] No.45079331[source]
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.

replies(1): >>45079780 #
immibis ◴[] No.45079780[source]
What do you think would happen if the Bluesky company suddenly blocked everyone but 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.

replies(1): >>45081707 #
OneDeuxTriSeiGo ◴[] No.45081707[source]
> What do you think would happen if the Bluesky company suddenly blocked everyone but 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.

replies(1): >>45083838 #
immibis ◴[] No.45083838[source]
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.

replies(2): >>45084641 #>>45084679 #
hoidofyolen ◴[] No.45084679{3}[source]
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.

replies(2): >>45086342 #>>45121611 #
1. immibis ◴[] No.45121611{4}[source]
> 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

Yes, that's as simple as an IP address check, since they own all of it. Could alternatively be a password (bearer token).

> And Bluesky wouldn't likely stop existing altogether,

In fact, the change would be noticed by almost nobody, because 99.9% of users would still see 99.9% of their following (including 100% of the ones who populate the default feed) and would have to go far out of their way to see any change.

> 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.

All irrelevant since it wouldn't have the content and people go there for the content. Views go where the content is.

> some copies of the entire network exist in the community

All irrelevant since it wouldn't have the new content posted after the block and people go there for the new content. New views go where the new content is.

> and some seriously pissed off community members who would now want to do everything they can to take up the mantle temporarily

Yes, exactly like the people who were pissed off at Twitter so they started Mastodon. Made literally no difference to Twitter. Most of those people even remained on Twitter and posted as much on Twitter as on Mastodon. Because views go where the content is. Thinking anything else is wilful delusion.

> Soon Bluesky the app, as well as Instagram and Twitter, would be flooded with tutorials of how to recover your accounts

Why recover? If you're part of the 99.9%, nothing changed for you.

> and migrate to another PDS.

I have no doubt there would be a flood of tutorials of how to make sure that only 0.1% of former Bluesky users will ever see your tweets, but nobody will follow that tutorial because they don't want to make sure that only 0.1% of former Bluesky users will ever see their tweets.

> If your point is that we'd lose at least half of the users of Bluesky

0.1% would be lost.

> But ATproto would be just fine

but completely useless, since its main use case is getting Bluesky feeds and that would be switched off

> and if people want to get their data back they likely can

This is nobody's goal. People log into Bluesky to see tweets from the people and topics they follow, not to "get their data".