How to keep decentralized networks updates accurate, level by level

Nobody is going to tell you. That is the honest starting point for keeping a catalog of federated networks current. There is no press office, no product blog covering the whole network, and no operator with any obligation to inform anyone outside their own server. Changes happen, and you find out by going and looking.

Which is manageable, once you accept it and build the looking into a routine. This page is about where change actually surfaces in a network made of independent parts, how to subscribe to the parts that can be subscribed to, and how fast each kind of entry goes stale.

What to take away

Where change surfaces, and which parts you can subscribe to

Protocol repositories. Specification work happens in public, in a repository or a working group with an archive. It is slow, and it is fully visible. Subscribe to whatever change notification the repository offers and read the few items that arrive.

Example: the ActivityPub specification lives in the w3c/activitypub repository on GitHub, with the spec text, its open issues, and the pull requests that change it.

Software release feeds. Nearly every project publishes releases with dates and notes. Most also publish a machine-readable feed of them, and web syndication is the cheapest monitoring you will ever set up: one subscription per implementation you list, read in a few minutes a week. The important signal is often absence rather than content, and absence is only visible if you are watching regularly.

Example: Mastodon lists every release with notes at github.com/mastodon/mastodon/releases, and that page also carries a feed.

Instance announcements. An operator posts a rule change to their own members. Sometimes there is a blog. Usually there is not, and the post scrolls away. Where a server publishes its rules or about page as an ordinary web page, you can fetch it on a schedule and diff it, which is the closest thing to a subscription available.

Example: mastodon.social/about is the shape to copy, one page naming the server rules and the operator.

Nothing at all. The largest category. Registration closes, a neighbor gets blocked, an operator moves hosting, and the only way to know is to look. This is what the calendar is for.

Decay rates, and the recheck cadence that follows

The three levels do not age at the same speed, and treating them alike wastes effort at the top and misses changes at the bottom.

The bottom row is the one that justifies itself. An entry pointing at a server that quietly stopped is worse than no entry, because a reader acts on it. Everything above the bottom row is about accuracy; the bottom row is about not sending people to a closed door.

Dead entries also leave dead links behind them, in your own pages and in everyone who cited them. Link rot is not a side issue in this category: instances are small sites with short lives, and a catalog that never rechecks turns into a list of unreachable hostnames faster than any other kind of directory on this site.

What to do with what you find

Sort every finding before touching an entry. Use the same three bins from the general watch-list method: a field moved, the context around a field moved, or noise. The bins work identically here.

What differs is that a single finding often belongs to a stream you must identify first. The same visible symptom can come from the protocol, the software, or the operator.

That attribution step is not optional and not always possible. When you cannot tell, record the observation with the streams you ruled out and those you could not.

The method for attributing an event to the right stream is the longer version. The short version: check the instance first, release notes second, specification last.

Update the entry, keeping the old value and its date beside the new one. Write the consequence in one sentence a member would understand.

"Registration is now by application as of this date; a reader who wanted to join immediately should look elsewhere" is worth more to a reader than accurate detail about which release changed which default.

One worked example, on an illustrative entry:

What a page carrying a year in its title can promise

It can promise the method: what was checked, from where, how, and when. It can promise the recheck cadence and show the per-field dates. It can promise that entries which failed a check are marked rather than quietly removed.

It cannot promise currency. A few thousand independent operators can change anything on their own server at any time, and several will do so this week. No page is current.

Saying so at the top costs a sentence. It is the difference between a reference a reader can calibrate and one that will eventually embarrass them.

The directory notes describe a three-level entry structure. It lets a page be honest at different resolutions.

The protocol section can reasonably be described as current, the software section as checked this quarter, and the instance section as dated observations, some already wrong.

The one alert worth setting up by hand

Watch for changes of operator. Nothing else invalidates so much at once. A server that changes hands keeps its name, its address, its members, and its archive, and every recorded fact about its rules, funding, and continuity is now a fact about the previous owner.

It surfaces in an announcement post, a changed about page, or members talking. Put the about page of every listed instance on the monthly diff. Read the operator line first.

When it changes, mark the whole entry for recheck. Shorten the cycle for a year. An ownership change resets every clock on a centralized service, for the same reason.

The wider point is the one the pillar notes on decentralized networks keep returning to: the architecture moves the decision to a person you can identify. That is the advantage, and it is also the maintenance burden, because the person can change.

Common questions

Can the whole routine be automated?

The fetches and diffs can. Deciding what a difference means cannot, and that is most of the work. Automate collection ruthlessly and read the results yourself; a pipeline that also judges will quietly file the one important change as noise.

A server stopped responding for a week and came back. Was that an event?

Record it as an observation, not an event. Small servers have outages, and a single failed check is weak evidence. Two consecutive failed checks are worth marking; a month of them is a shutdown whether or not anyone announced one.

Should readers be told when an entry changes?

Publish a short dated list of field changes per entry, in plain language, with the consequence for someone using that server. Keep the evidence behind it for anyone who wants to check. Most readers want the sentence, not the diff.

How much of this applies to a network with one dominant server?

All of it, and more urgently. A network where nearly everyone is on one server carries the maintenance burden of federation and the concentration risk of a centralized service at the same time.

The entry for that one server does all the work the whole catalog was supposed to spread out.