←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 #
danabramov ◴[] No.45077986[source]
>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.

This isn't quite right. ATProto has a completely different "shape" so it's hard to make apples-to-apples comparison.

Roughly speaking, you can think of Mastodon as a bunch of little independently hosted copies of Twitter that "email" (loosely speaking) each other to propagate information that isn't on your server. So it's cheap to run a server for a bunch of friends but it's cut off from what's happening in the world. Your identity is tied to your server (that's your webapp), and when you want to follow someone on another server, your server essentially asks that other server to send stuff to yours. This means that by default your view of the network is extremely fragmented — replies, threads, like counts are all desynchronized and partial[1] depending on which server you're looking from and which information is being forwarded to it.

ATProto, on the other hand, is designed with a goal of actually being competitive with centralized services. This means that it's partitioned differently – it's not "many Twitters talking to each other" which is Mastodon's model. Instead, in ATProto, there is a separation of concerns: you have swappable hosting (your hosting is the source of truth for your data like posts, likes, follows, etc) and you have applications (which aggregate data from the former). This might remind you of traditional web: it's like every social media user posts JSON to "their own website" (i.e. hosting) while apps aggregate all that data, similar to how Google Reader might aggregate RSS. As a result, in ATProto, the default behavior is that everyone operates with a shared view of the world — you always see all replies, all comments, all likes are counted, etc. It's not partial by default.

With this difference in mind, "decentralizing" ATProto is sort of multidimensional. In Mastodon, the only primitive is an "instance" — i.e. an entire Twitter-like webapp you can host for your users. But in ATProto, there are multiple decentralized primitives:

- PDS (personal data hosting) is application-agnostic data store. Bluesky's implementation is open source (it uses sqlite database per user). There are also alternative implementations for the same protocol. Bluesky the company does operate the largest ones. However, running a PDS for yourself is extremely cheap (like maybe $1/mo?). It's basically just a structured KV JSON storage organized as a Merkle tree. A bit like Git hosting.

- AppViews are actual "application backends". Bluesky operates the bsky.app appview, i.e. what people know as the Bluesky app. Importantly, in ATProto, there is no reason for everyone to run their own AppView. You can run one (and it costs about $300/mo to run a Bluesky AppView ingesting all data currently on the network in real time if you want to do that). Of course, if you were happy with tradeoffs chosen by Mastodon (partial view of the network, you only see what your servers' users follow), you could run that for a lot cheaper — so that's why I'm saying it's not apples-to-apples. ATProto makes it easy to have an actually cohesive experience on the network but the costs are usually being compared with fragmented experience of Mastodon. ATProto can scale down to Mastodon-like UX (with Mastodon-like costs) but it's just not very appealing when you can have the real thing.

- Relays are things "in between" PDS's and AppViews. Essentially a Relay is just an optimization to avoid many-to-many connections between AppViews and PDS's. A Relay just rebroadcasts updates from all PDS's as a single stream (that AppViews can subscribe to). Running a Relay used to be expensive but it got a lot cheaper since "Sync 1.1" (when a change in protocol allowed Relays to be non-archiving). Now it costs about $30/mo to run a Relay.

So all in all, running PDSs and Relays is cheap. Running full AppViews is more expensive but there's simply no equivalent to that in the Mastodon world because Mastodon is always fragmented[1]. And running a partial AppView (comparable to Mastodon behavior) should be much, much cheaper — but also not very appealing so I don't know anyone who's actually doing that. (It would also require adding a bit of code to filter out the stuff you don't care about.)

[1] Mastodon is adding a workaround for this with on-demand fetching, see https://news.ycombinator.com/item?id=45078133 for my questions about that; in any case, this is limited by what you can do on-demand in a pull-based decentralized system.

replies(4): >>45078344 #>>45081740 #>>45081898 #>>45087265 #
izacus ◴[] No.45078344[source]
That's a big post that doesn't really explain in what way can smaller players federate with ATProto or how the structure allows federation.

Reading through it, it just sounds like sharding/scaling for a centralized service that's meant to be owned and provided by a single entity.

replies(3): >>45078704 #>>45078763 #>>45080492 #
1. EnglishMobster ◴[] No.45080492[source]
I think it can be explained a little better.

When you write a post, you save it to your PDS. Think of it like writing a blog. You're done, you hit submit, it shows up on a server somewhere. You can run your own server with your own data, or use someone else's. That's exactly how a PDS works; it is a storage server for your data.

The AppView is a way to index all the PDSes registered across the whole network. If your server is crawlable by the AppView, all your data shows up in the app. This is like if your blog is crawlable by Google, you show up in search results.

When you like a post, you commit a "like" record to your personal server. When the AppView displays likes, it looks at every indexed PDS and shows every like it can find for that post (simplifying a little for clarity). Each one of those likes might live on different servers, some of which is self-hosted.

Because you can run your own PDS, you can commit any data you want to it. You can even commit things that services may find distasteful. However, the AppView may refuse to serve this content to users; this is how content can be removed from the network and how users can be banned. The federation equivalent would be defederation, except it happens to singular accounts rather than entire instances.

If you disagree with the moderation policies run by Bluesky the company, that's when you can look into running an alternative AppView. This is similar to disagreeing with the admin of a particular Mastodon instance and moving to a different instance. Of course, as mentioned running an AppView is much more expensive, but that hasn't stopped folks from trying (I believe Blacksky is trying to run their own AppView that is fully independent of Bluesky).

To use an alternate AppView, you'd simply go to a different website. This website will index PDSes the same way that Bluesky does, but it may index them in a different way and include/exclude different content. The data is still there (nobody can reach into your PDS on your server and delete your data), but the AppView admins choose which content they wish to serve to people using their community, just as Mastodon admins choose who to federate with.

In this sense, it is indeed truly federated. The primitives are simply different; it's more granular than Mastodon.

You can write your own content to your own server and let it get indexed to any number of AppViews; you completely control your personal data and nobody can reach in and delete that data randomly as they don't own it - you do (at the cost of ~$1/month or a Raspberry Pi).

When you use the Bluesky service, you are seeing their view of the network and what they choose to index. You may disagree with this view, just as you may disagree with the admins of Mastodon.social etc. In that case, you can choose to use another AppView (such as deer.social or Blacksky) that adopts different policies. Since account information isn't stored on the AppView and it simply handles indexing and moderation, moving between AppViews is painless and no data needs to be transferred from one server to another - you simply use a different bookmark.

It could be that you disagree with all the current AppView admins. You can host your own, it's just expensive ($300/month, as mentioned). You can also tailor your AppView to index less content, which will of course limit the amount of data you consume and give you a partial view of the network, effectively defederating you from anything you do not wish to index.

But there's nothing stopping you from doing so!