Decentralized networks have no useful rankings: six questions to ask instead

There is no useful ranking of decentralized networks, and there is an even less useful one of the individual servers inside them. The reason is structural rather than editorial: what a member gets is decided by an operator, a set of rules, and a set of neighbors, and none of those three is a quantity.

What a reader arriving with the question "which one is best" actually needs is a selection procedure. Not a list with a winner, but an ordered set of questions that eliminates most of the options and leaves them with two or three they can choose between on taste. That is what this page is.

What to take away

Why a ranked list is the wrong output here

Ranking needs a total order over comparable things. Servers are not comparable in that sense.

Two servers can run the same software under the same rules yet behave completely differently. One may have four people and a funding page; the other, one person busy this month.

A second problem is specific to this category. A ranked list of servers concentrates people onto the top entries, and that concentration is the failure mode the architecture exists to avoid.

A popular list can push a network toward the shape it was built to escape, simply by being read. That effect is real, and it is why a catalog should refuse the format, not just caveat it.

The shape a network settles into is the thing at stake. A list that sends most arrivals to the same few entries is not describing the network; it is editing it toward the star on the top row.

The general argument against ranked lists in a catalog, and the sort-key contract that replaces them, is set out in the notes on ordering a list without judging it. Everything there applies here. What follows is the part that is particular to networks made of independent servers.

The elimination sequence

Apply in order, and stop at the first failure. Each question is answerable from pages the server publishes about itself.

What survives is a short list. Choose among them on the things nobody can rank: whether you recognize anyone there, whether the tone of the rules sounds like someone you would want moderating you, and whether the place is the size you want.

The two questions people skip

How many people keep it running? A server operated by one person is one illness, one house move, or one bad week away from ending, which is the bus factor applied to a place you keep your identity. Plenty of excellent servers have a bus factor of one. The point is to know it rather than to discover it.

What does leaving cost? Ask specifically what moves: the identity, the followers, the posts, and which of those do not. The answers vary by software and sometimes by version. A network can be entirely free of vendor lock-in at the protocol level and still leave you unable to take your posts off one particular server, and the second fact is the one you will live with. The three questions in the mechanism-based classification tell you what is structurally possible; the server's own documentation tells you what is actually implemented.

What a catalog can offer instead of a rank

The fourth row is the one people argue about. An editor who marks a server as safe has made a promise about the future conduct of strangers. Quoting the rules and letting a reader decide is not a dodge; it is the only claim the evidence supports.

Size, and why it is the wrong tiebreaker

A large server gives you easier discovery, a longer local timeline, and a moderation team with more capacity. It also gives you more exposure to a single operator's decisions and makes you part of the concentration problem.

A small server gives you a moderator who knows your name and a much shorter path to being heard. It also gives you the failure modes described in the notes on small networks: one person carrying it, no succession plan, and an ending that arrives without notice.

Neither is better. What matters is that you know which trade you took, and that you are not relying on a server to be permanent regardless of which one you picked. Keep an export current and keep a route to the people you care about that does not run through the server, and the choice stops being high stakes.

When a reader insists on a recommendation

Give them a worked example instead. One reader with stated requirements, walked through the six questions, with each elimination named and explained. A reader with similar requirements can follow it; a reader with different ones can see exactly where their path diverges from it.

A catalog should never publish a numbered list of servers with no stated requirements. Readers treat it as endorsement, copy it without caveats, and it still circulates after half the entries close.

The pillar notes on decentralized networks explain why the operator choice, not the network choice, is the decision that actually affects a member.

Common questions

Is there really no difference in quality between servers?

There are enormous differences, and they are mostly differences in operator attention, which no catalog can measure and which changes without notice. What can be recorded is whether the operator has written things down, which correlates with attention and is not the same as it.

What about servers run by a company rather than a volunteer?

Same six questions, same order. A company is more likely to answer the funding and continuity questions and no more likely to still be running the service in five years. Record what is stated, and do not read incorporation as commitment.

Should a catalog exclude servers with rules it disagrees with?

State an inclusion rule, apply it to everyone, and publish the rejections with the test each failed. An editor who quietly omits servers has published a ranking without saying so, which is the thing this whole page is trying to avoid.

Can the elimination sequence be automated?

Partly. Registration state and the presence of a rules page can be checked by a machine. Whether the rules describe a place you want to be cannot, and it is the question that decides the outcome. Automate the first pass, read the survivors yourself.