Maintenance
Part of What actually changes about leaving a decentralized network?
What the decentralized networks data covers
Decentralized networks data: why server figures never add up to a network, what is worth observing instead, and how to store it so it stays usable.
Every number you can get about a federated network is a number about one server. That is the basic unit of decentralized networks data: add the figures up and you have not measured the network, because the parts overlap, disagree about what they are counting, and were counted at different moments by software that defines the terms differently.
That is not a reason to keep no data. It is a reason to be exact about what each figure describes. This page is about which quantities in a federated network are real, which are local, which are double counted, and how to store the difference so a later reader is not misled by your own file.
What to take away
- A server reports about itself. Nothing reports about the network, and summing server figures produces a number with no referent.
- The same account appears in many servers' records, so any total is inflated by an unknown amount that cannot be removed from outside.
- Store every figure with the server, the software, the version, and the moment. A figure without those four is not recoverable later.
What a server can honestly tell you about itself
Federated platforms include Mastodon, Pleroma, Misskey, Lemmy, PeerTube, GoToSocial, and Friendica. Many expose server metadata through NodeInfo, a machine-readable standard discovered at /.well-known/nodeinfo; its discovery document points to a schema endpoint, often /nodeinfo/2.0. Support and fields vary by software and version.
NodeInfo 2.0 uses software.name and software.version for implementation identity, openRegistrations for registration status, and usage.users.total, usage.users.activeMonth, and usage.localPosts for reported counts. The schema defines activeMonth as users active in the last 30 days; localPosts means posts made by users of that server, not a universal count of all copies stored there.
Mastodon's /api/v1/instance response includes stats.user_count, stats.status_count, and stats.domain_count; /api/v2/instance exposes usage.users.active_month. The monthly field is not a weekly count, and should not be treated as an identical activity window across software.
A directory record can use mastodon.social as the server identity: store its hostname alongside software name and version, each reported field and source endpoint, and the observation date. This illustrates a record structure, not a live count or a claim that the domain's current settings were checked.
Server Figures and Their Traps
Figure
- Local accounts
- Registrations ever
- Active accounts
- Meet activity test
- Posts stored
- Local and received
- Known servers
- Heard from
- Blocked/limited
- Policy decisions
What it is about
- Local accounts
- Includes abandoned, never-used
- Active accounts
- Test changes between versions
- Posts stored
- Mostly other servers' posts
- Known servers
- Includes long-dead ones
- Blocked/limited
- Only if operator publishes
The trap
- Local accounts
- Active accounts
- Posts stored
- Known servers
- Blocked/limited
Read count fields by their exact names and implementation. NodeInfo's usage.users.total, usage.users.activeMonth, and usage.localPosts do not all measure the same thing; Mastodon's stats.user_count and stats.status_count are separate API fields. A value is not audited, and definitions can vary by implementation and change between releases.
NodeInfo defines activeMonth as activity during the last 30 days; Mastodon's API uses the field name active_month for monthly activity. Keep the field name, software, version, and observation date rather than converting either into a generic MAU or WAU label.
| Figure | What it is about | The trap |
|---|---|---|
| Local accounts | Registrations on this server, ever | Includes abandoned and never-used accounts, and only grows |
| Active accounts | Local accounts meeting an activity test | The test is the software's, and it changes between versions |
| Posts stored | Everything held, local and received | Mostly other servers' posts; not a measure of this server's activity |
| Known servers | Other servers this one has heard from | Includes long-dead ones; grows and never shrinks in most software |
| Blocked or limited servers | This server's own policy decisions | Only where the operator publishes it, which many do not |
The last row is the only one on that table with a stable meaning, and it is a policy fact rather than a measurement.
Why the totals do not add up
Three separate problems make the sum of server figures meaningless, and they push in different directions.
Why Totals Do Not Add Up
- Copies counted repeatedly across servers
- One person may hold several accounts
- Sampled servers are not random
- Sum of server figures is meaningless
When a metric counts posts stored on each server, a public post delivered to servers with followers can appear in more than one local store. Summing that kind of storage count therefore counts copies, with the multiplier depending on how widely the author is followed; do not assume a field such as NodeInfo's usage.localPosts measures these remote copies.
For example, if a post from an account on mastodon.social is delivered to mastodon.online because a local account follows it, a metric that counts locally stored copies can include the same post on both servers. Adding those observations counts two copies of one post; this is an illustration, not a measured multiplier.
One person may hold several accounts on several servers. Deduplicating them would require deciding that two accounts on two servers are the same person, which is a record linkage problem with no available key. From outside there is no way to do it, and from inside no single party can see both records. Any account total is therefore an upper bound of unknown looseness.
The set of servers you sampled is not random. You can only collect from servers you know about, and you know about them through some path that favors the large, the long-lived, and the ones that publish. That is sampling bias built into the collection method itself, and it cannot be corrected by collecting harder.
Together these mean the honest answer to "how big is this network" is that nobody knows, including everybody inside it. Say that rather than producing a figure with a footnote nobody will read.
What is worth collecting instead
Structural and policy facts, per server, dated. They are stable enough to be worth the effort and they answer questions readers actually have.
- Software and version.Two fields, one fetch, and the single most informative pair available. Version tells you what the server can do and whether the operator is keeping up.
- Registration state.Open, application, invitation, closed. Changes often; decides whether a reader can act on the entry at all.
- Federation policy publication.Whether the operator publishes what they block or limit, and where. A yes or no plus a link.
- Continuity statement.Whether anything is stated about notice, backups, or shutdown. Almost always absent, and the absence is the finding.
- Reachability.Whether the server responded, on a date. A simple observation that becomes a health series the moment you have three of them.
- Anonymous visibility.Whether a logged-out visitor can read a public post. Decides whether the server's material is on the open web at all.
None of these is a count. All of them can be re-observed identically next quarter, which is what makes a series out of them.
Storing it so it stays usable
One row per observation, never one row per server. A server is a sequence of observations. Collapsing that sequence into a current-state row throws away the only thing that makes the file better than a screenshot.
When correcting a directory entry, preserve the earlier value, observation date, and source method. Add the correction as a new observation rather than overwriting the history.
Each row carries the server, field, and value. It also carries the software and version at the time, the date, and the source method. The last item matters more here than elsewhere.
A value read from a server's own description is the operator's claim, and a value observed by loading a page is a measurement. Mixing them in one column destroys that distinction, and the three-tier separation between observed, published, and unknowable transfers directly.
Add one field the other categories do not need: the vantage point. Some behavior depends on where you fetched from and whether you were logged in. Two observations that disagree may both be right and differ only in vantage.
Reporting without implying a total
When you publish anything derived from this file, the wording carries the whole burden.
Write "of the servers in this catalog" rather than "of the network." Give the count of servers observed and the date range of the observations. Where a proportion is quoted, quote the denominator in the same sentence, and refuse the aggregate a reader will ask for.
There is no honest network-wide account total, and an estimate with error bars would suggest a method that does not exist.
What you can say is comparative and internal to your own set, if every entry was observed the same way in the same window. That small, true claim is more than most published figures about these networks can support.
For the broader architecture, decentralized networks explains how decisions and measurement are distributed until no single server has a whole view.
Common questions
Third-party sites publish network-wide totals. Are they wrong?
Examples of third-party directories or instance catalogs include FediDB, Fediverse Observer, instances.social, The Federation, and joinmastodon.org's server list. Their coverage and methods differ, so treat their totals as snapshots of known servers and self-reported fields, not a complete census or an audited network-wide measurement.
Can I at least count servers?
You can count servers you have observed responding, on a date, which is a real number about your own collection. A total number of servers in existence is not obtainable, because a server nobody has heard from is indistinguishable from one that does not exist.
How often should the observations run?
Quarterly for the structural fields and monthly for reachability, because reachability is the one that changes without warning and the one a reader is most harmed by getting wrong. Anything faster produces rows that differ only in their timestamps.
A server stopped responding. Do I delete the entry?
No: mark it unreachable with the date, keep observation history, and leave the entry visible.
Keep the entry's network and mechanism classification visible; classification by mechanism can help readers identify what the server was for, even after it stops responding.
