Thanks for pointing that out! I read again and see the blog post has a summary with 4 very high level points, which I admit I didn't read initially. I saw a wall of text about an expansion and I was still asking myself 'What exactly is Bluesky and how is it different?', so I skipped right to the main site.

Having read the post more deeply, particularly the bullet points you mentioned, it looks like there are four really high level differentiators listed:

* A focus on the global conversation

* Composable moderation

* Composable feeds

* Account portability

The term 'composable' seems almost misused when reading the extended descriptions, and is used differently between points. For example, 'composable moderation' indicates that moderation isn't done on a per-server level.

The fundamental censorship and algorithmic prioritization models for distributed social networks seems to have three layers: global (centralized), server, user.

In 'old social' the model is basically just 'global', as there are no servers and the only 'user-level' options are those determined by the global operator.

It doesn't seem like moderation would truly be 'composable' if it's only set on the global and user (and therefore global via centralized determination of client-level specs) level. It sounds like Facebook except with other people paying the data costs.

The next bullet indicates 'composable feeds', which sound like a very nice feature but really don't seem to follow a decentralized model either. The 'composition' does not combine from each global/server/user layer. They sound more like 'custom feeds' which users can define based on global content, using predefined criteria determined by a client (web app) which don't really a way to control the behavior of. Which makes this feature only truly operate on the global layer, and 'custom' rather than 'composable'.

It would be on the same level of 'old social' adding a new feature to their web app, more than a fundamental transfer of control to the network. As a result, when the dollars dry up and the feature isn't financially plausible, or a PM somewhere makes a bad decision because he read a blog post about how great it is to destroy user choice, there's risk the feature could go away.

Anyway, the question I'm still left with in the end is this. If moderation is done globally, and I can't exercise any control over the prioritization of content beyond what is granted to me by the global provider (even though there are more and better choices than 'old social'), what's the benefit of running a federated node?

I don't mean to make it sound like this is some kind of Twitter clone with an SSO login that outsources operational costs to volunteers while still keeping a fundamentally iron grip on control. I'm just honestly confused at the value proposition for volunteers. Exactly how much control is transferred to the network beyond simply hosting data which is displayed according to how the centralized portion of the system determines?

It'd be good if the trade-off in terms of time, data, and performance for running your own node was simply to remove the capability of the centralized network to collect user behavioral metrics and such. That's a great and valid reason to host your own service or use a trusted party's service. But there's no mention of this if it is the case. If you provide that already without promoting the fact, maybe bring that up with your marketing team.

Anyway that's getting a bit off topic. But to the original point:

Ideally, a better comparison would be a dedicated page which coallates every feature of each platform in a grid. A row for each feature. Row cells would fill with 'has' or 'does not have' checkboxes or possibly text where there's something similar but differs sufficiently to require an explanation. Maybe with links to documentation or direct to UI on the line items where appropriate.