Three levels structure a decentralized networks directory: protocol, software, instance

A directory of decentralized networks faces a problem no other directory on this site does: what counts as one entry is unclear. A federated network is a protocol, several pieces of software that speak it, and thousands of servers running it.

Each server has its own operator, rules, and lifespan. Describe it at the wrong level and the entry is too abstract to act on or too specific to keep current.

This page settles the unit question for a decentralized networks directory with a three-level model. It then does what the site does for every category, in the way the four-source walk-through sets out. It lists the fields an entry needs at each level, where each comes from, and how to check that a server is still there.

What to take away

Level one: the protocol

The protocol entry answers the three classification questions (where data lives, what identity is bound to, where removal sits), the same questions the notes on classifying by mechanism applies to every category. It links to the specification. ActivityPub is the best-known example, and its specification is published by the World Wide Web Consortium (W3C), a fact worth recording because other protocols in the same directory have no such home. The others to cover are the AT Protocol that Bluesky runs on, Nostr, the older OStatus, the Diaspora protocol, and Zot, which Hubzilla uses. WebFinger is the lookup layer several of them share to turn an address into a server.

The entry also records who maintains the specification (a standards body, a foundation, a company, or an individual) and where changes to it are discussed. It holds nothing about any particular server. A protocol entry that says "most instances do X" has confused the levels.

Level two: the software

Several programs may implement one protocol, and they differ in what an operator and a member can do. ActivityPub alone has Mastodon, Pleroma and its fork Akkoma, Misskey, GoToSocial, and Friendica for text, PeerTube for video, and Pixelfed for photos. The software entry records which protocol it speaks; whether it is open source and under what license; and who maintains it and where releases are published.

It also records what export and migration it supports: identity, followers, posts, and which of these survive a move. The moderation tools an operator gets are listed too: per-member actions, per-server blocks, whether block lists can be shared or imported. Last comes whether one person can run it on ordinary hosting or it needs more.

Source: the software's own documentation and release history. The release cadence is a field in its own right, because a federated network's instances are only as maintained as the software they run. A decentralized networks timeline keeps the protocol, the software, and the instance as three separate streams of evidence.

Level three: the instance

This is what a reader joins, and it is the entry that matters. An instance is one server, run by one operator, with its own rules and its own neighbors. mastodon.social is one, and so is a two-person server running GoToSocial on a spare machine.

Nothing here needs a member count. Instances often display one; treat it as the instance's own figure, undefined and unverified, and leave it out of the entry.

Two of those fields carry more weight than the rest. Funding is recorded as a channel rather than a number: the operator's own donation page, a recurring platform such as Liberapay, Open Collective, or Patreon, merchandise, a parent organization, or nothing stated. What the field answers is where the money goes, which in practice is hosting and a domain name, with the operator's unpaid time wrapped around them.

Verifying from the instance itself

Federated software conventionally exposes a machine-readable description of the server through NodeInfo, discovered at /.well-known/nodeinfo and served as a schema at /nodeinfo/2.0; Mastodon and its relatives also expose /api/v1/instance. The reply carries the software, the version, whether registrations are open, and sometimes the server's stated rules. Fetching it is the fastest verification available, and it is the instance's own claim about itself, dated by your fetch.

Read the about page for the operator and funding, and read the rules page for the rules. Look for a published block list or a statement of federation policy.

Then open the public timeline logged out and check whether more than one account has posted recently. That last check is the health check, and you should repeat it.

For continuity, search the about page and any announcements for the words "shutdown", "notice", "backup", and "migrate". Most instances say nothing. Record "no continuity statement found" as the value; it tells a reader exactly what they are relying on, which is the operator's goodwill and nothing written.

Public instance monitors, Fediverse Observer and FediDB among them, show a server's last-seen date and will often catch a disappearance before the quarterly check does. Save the about page and the rules page to the Wayback Machine the first time you verify an instance; the archived copy is then the record of what the server promised after the server itself is gone.

The health check, and the dying instance

Instances end quietly. The operator stops paying for hosting, or stops updating, or loses interest, and the server serves stale pages for months before it disappears. A directory that lists it is pointing readers at a place that will not be there when they need it.

An instance can vanish unannounced, so check each instance quarterly, in this order. The cost is a handful of page loads per instance, and it is the part of the directory that has to be scheduled.

Check that the server information endpoint responds and its software version matches a currently maintained release. Confirm the public timeline shows posts from more than one account in the last month, and the about page still loads and names the same operator. Confirm the registration state remains recorded.

Any failure moves the entry to a "verify" state with the date. Two consecutive failures move it to "unreachable" with both dates. The entry stays, marked, because a reader looking for where a community went needs to find the record of where it was.

Record the version too. An instance running software several releases behind is a maintenance signal about the operator and a risk to its members, and it is visible before anything else goes wrong.

Linking the levels

An instance entry links to its software entry, which links to its protocol entry. A reader starting at an instance can follow links up to learn what it can structurally do.

A reader starting at a protocol can follow links down to software that implements it and instances that run that software. The directory's structure mirrors the network's, the only way to keep the three kinds of fact from contaminating each other.

The decentralized networks overview covers the questions a reader should ask an instance before joining; this directory is where the answers get recorded, one operator at a time.

Common questions

How many instances should the directory hold?

As many as it can health-check quarterly, and no more. A directory of a thousand instances checked never is worse than a directory of forty checked on schedule.

An instance's rules page and its actual moderation disagree. Which goes in?

The rules page, quoted, as the instance's stated policy, and a dated note of the observed disagreement with what was observed. The directory records claims and observations separately, at every level.

Should the directory publish which instances block which?

It should record whether an instance publishes its own list and where. Compiling the lists into a map is a different project with different ethics, and it is not this one.

What about an instance run by a company rather than a volunteer?

Same fields. The operator field says who; the funding field says how; the continuity field says whether anything is promised. A company is not more reliable by default, and the entry should not imply it.