How to assemble a decentralized networks timeline

A decentralized networks timeline has no single history, because no single authority can announce one. Protocol changes on one schedule, the software that speaks it on another, and the several thousand servers running that software on thousands more.

An event on any of those three clocks can look, from a member's seat, exactly like an event on either of the others.

That is the whole difficulty of a timeline here, and it is a solvable one. Keep three streams, decide which stream each event belongs to before you write it down, and record what kind of evidence you have for it. The result is longer than a single list of dates and it is the only version that stays true.

What to take away

Three clocks, not one

The three levels that structure a directory of these networks also structure their history, and they move at very different speeds.

The protocol changes rarely and slowly, because a change has to be agreed by people who do not work together and implemented by software they do not control. Protocol events are few, well documented, and consequential for everything above them. ActivityPub is the clearest example: the World Wide Web Consortium published it as a Recommendation in January 2018, and it has since displaced the older OStatus suite that GNU social and early Mastodon used. WebFinger handles discovery of remote accounts, and HTTP Signatures is how servers sign the requests they send each other.

The implementation changes often. Mastodon, Pleroma, Misskey, Lemmy and GNU social are separate projects that speak the same protocol and release on their own schedules, so one federated network can hold several of them at once. A release can add a moderation control, change what an export contains, or alter what federates and what does not. These events are dated, public, and almost never announced outside the project.

The instance changes constantly and quietly. An operator adds a rule, blocks a neighbor, closes registration, moves hosting, or stops. A large server like mastodon.social and a two-member hobby instance leave the same thin record. Almost none of it is announced anywhere a directory would see, and almost all of it is what a member actually experiences.

The classification questions in the notes on telling these networks apart by mechanism map onto the same three levels, which is convenient. An event that changes the answer to one of those questions is worth recording, and the level it changed at tells you which stream it belongs in.

What counts as an event in each stream

The noise column matters as much as the other. A timeline that records every release is a changelog, and nobody reads a changelog to understand what happened to a network.

Attributing an event to the right stream

A member on a Mastodon server reports that they can no longer see posts from people on another server. That single observation is consistent with at least four events at three levels. Their instance blocked the other one, the other one blocked theirs, an implementation release changed a default, or a protocol capability was deprecated and one side has not caught up.

Work down from the cheapest check.

Write the stream you concluded and the evidence that got you there. A later reader who disagrees can then disagree with the evidence rather than with you.

An entry written this way looks like this. January 2018 — ActivityPub published as a World Wide Web Consortium Recommendation. Stream: protocol. Evidence: the published specification. Or 2017 — Mastodon adds ActivityPub support alongside OStatus. Stream: implementation. Evidence: the project's release notes. The instance-level version usually carries a vaguer date: the server closed registration, bracketed between two archived copies of its rules page.

The evidence each stream leaves

Specifications leave text. A published protocol revision is a document with a date on it, and older revisions usually stay published. This is the best evidence in the whole exercise and it covers the fewest events.

Implementations leave commits and releases. Source repositories are under version control, which means every change carries a timestamp and an author whether or not anyone wrote release notes. A repository with no release for a long stretch is itself an event, and it is dated by the last one.

Instances leave almost nothing. An operator announces a rule change to their own members, in a post that is visible to members, and then it scrolls away. Archived copies of an about page or a rules page are frequently the only external record, and they exist only if a crawler such as the Internet Archive's Wayback Machine happened to visit. When an instance closes, the announcement goes with it, which is why an entry for a closed instance is worth keeping: a directory may end up holding the only surviving trace. That is digital preservation as a side effect of ordinary record keeping, and it is worth doing deliberately.

Writing it up without inventing a date

Use the same precision discipline as any other platform history: a date, a stated precision, and a source for each. The general method for dating events you cannot pin to a day applies without modification, and the interval form does most of the work here, because instance events are usually bracketed by two archived copies rather than announced.

Two habits are specific to this category.

Record the software version alongside the date for anything at the instance level — which Mastodon release a server was running, for example. Version plus date is a much stronger fact than date alone, and it lets a later reader place the event relative to the implementation stream without any further research.

Record whether an event was reversible and whether it was reversed. Federation decisions get made and unmade. A timeline that shows only the block, and not the unblock four months later, describes a permanent split that did not happen.

What the three streams show together

Read side by side, the streams answer a question no single one can: whether something that happened to a member was a decision about them, a decision about their server, or a consequence of software neither party chose. Most complaints about federated networks turn out to be the third.

They also show where the real power sits over time. A protocol stream with few events and an instance stream with many is a network where governance happens locally, whatever the specification says.

The pillar notes on what decentralisation genuinely changes argue this is the point of the architecture, not a defect. A timeline is the cheapest way to see whether that is true of any particular network.

For the equivalent exercise on a single centralized operator, all three streams collapse into one company's decisions, and the record of them is only as complete as that company chooses to make it.

Common questions

Can I merge the three streams into one page for readers?

Present them together, keyed by date, with the stream shown in a column. Merge the display, never the record. Readers benefit from seeing that a release and an instance decision landed in the same month; the record has to keep them separable so that a later correction touches only one.

An instance says a change came from the software, and the software project says it came from the instance's configuration.

Record both statements, dated and attributed, and mark the event as disputed. Configuration is exactly where these two streams meet, and disagreements about it are common and usually honest. The disputed marker is more useful to a reader than a resolution you cannot support.

How far back can an instance timeline go?

To the earliest archived copy of its about page, and no further. State that limit in the first entry. Operators sometimes remember more than the record holds; that is a prompt to look for evidence, not a substitute for it.

Is it worth timelining an instance that has closed?

Yes, and it may be the most useful entry you keep. People go looking for closed communities years later, wanting to know when it ended and where members went. Nothing else on the web is likely to hold that.