It seems that this federated service falls into the same asymmetry that others have—everyone is joining the flagship instance (which negates the decentralization).
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.
Consumers want to not care about the details. Most people don't care much about federation, p2p, full decentralization or centralization, until something crashes. As long as they have no problems, they would even play with the devil.
Centralized solutions, tend to be easier in usage, faster, and with a more stable moderation who maintains the peace. This is something decentralized solutions can't easily replicate, but it's not like it's impossible. It's just that so far not many are trying to climb this mountain, because implementation and maintaining of centralized systems is also easier.
You are partly correct. They do not care about details, but they want things as simple as possible, and decentralization makes that harder. See all people complaining (or don't understanding) about having to choose a mastodon or lemmy instance.
And copy+pasting usernames/post links that you have open, to search for it again on your own instance so you can reply... is not simplicity.
I can only guess as mass readers tried to migrate to bookwyrm, how many people would be complaining that they are trying to add a book a friend is reading, but it's not showing for them - because it's registered on another instance but they didn't realize
Or why they see different ratings, or less number of reviews than their friends
Consumers often also don't want to be dependent on local data. I would propose a feature to link (& sync) user accounts across multiple servers, that way no one needs to depend on a single server. Power users can set up their own server and use that as a local copy of all their data.
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.
I think this itself is the big benefit of federated services for most people. I'm less concerned with proper distribution of users across instances but rather is users always have recourse should any particular instance get elon'd.
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:
