It's incredibly clear at this point - and it was clear a priori also, but with some uncertainty - that this is how federated networks will work, if they do at all. This just needs to be incorporated into any assumptions about these systems. Instead of thinking through the costs and benefits of decentralization with fairly evenly distributed node sizes, it's necessary to think through the costs and benefits of a decentralized system with a power law distribution of node size, because that's going to be reality.

Consumers want centralisation. All of this stuff is too complicated right now for end-users.

In an ideal world, my data would live on the instance but as soon as its mutated a local copy is sync'd through the browser/app. That way it's my data, and if the instance goes down, I can choose to sync it somewhere else.

Ideally this would be packaged up in one application, so for different kinds of "sites" the mechanism for syncin'g and migrating would be the same.

If I were going to join this, I would seek out the flagship instance. It’s the least likely to shut down a year from now.

I think it’s also important to make signing up as frictionless as possible. I would guess most people don’t care if it’s a federated service or even what that means. If you ask those people to choose an instance, you are instantly going to lose some of them.

They need a brain-dead way to hop between instances without losing data, if it doesn't already exist. Of course this only works well if the instance that is shutting down gives notice in time for people who login in only occasionally to see it.

I disagree that having a popular flagship federated service negates decentralization.

The point of decentralization is not to destroy the ability to centralize (see e.g. git versus SVN and then look at github).

The advantage is that federation and decentralization empower an entirely new set of use cases, archival strategies, development, and accessibility affordances that may have not been possible before. While enabling the town square & metcalfe's law that are advantageous to many people / use cases.

Nah, it doesn't negate anything. The flagship instance is a fine default but it's important to be able to move at any time for any reason and even to run one's own. This is itself a quality feedback mechanism and freedom.

Federation has many flaws, but this is not one of them. It makes sense when the service is new to focus mostly on one big instance instead of many instances with 10 people each. Case in point:

- The Mastodon flagship instance has 25% monthly active users of the total network https://fedidb.org/software/mastodon

- Lemmy flaghsip* (which is newer than Mastodon) has 38% https://fedidb.org/software/lemmy

As time goes by people will distribute over the other instance. And even now it's not so bad as you make it seem.

* Not even the actual flagship maintained by the developers, but one created by the community

Does it? The possibility of doing otherwise seems just as important as the reality of doing it.

This is the inherent flaw of decentralized networks.

You either appeal to people who really care about decentralization (an extremely small group) or you're not really decentralized.

I already run software that federates with this, and I didn't even realize this existed (Pleroma). Seems quite decentralized to me.

I don't think it negates the decentralization.

It still allows you to pack your shit and move somewhere else should a narcissistic billionaire buy the flagship instance.