See It Work — How news travels between nodes — with no central server | S2 Vol 4 · Federation & Partner Device Gateway

When a constitutional event happens at one node — say a rule change — the others should know. A sealed, signed update (the book calls it a shard) travels peer-to-peer. Crucially, it carries the fact that something happened, not your underlying data. Every node that receives it runs the same four-step check: verify → diff → classify → decide.

Most 'federated' systems have a hidden central writer — a coordinator that, over time, becomes the boss. Here there is none: each node checks each update itself, so no single point can capture the network or take it down.

What this means for you

A sealed update reaches every peer; each verifies it, sorts it, and decides for itself — no central writer anywhere. What this means for you: your node never takes orders from a central server; it learns what happened elsewhere and makes its own call, so the network can't be captured or knocked over at one point.

Each peer runs the same four-step check and seals a receipt at every step:

Update Received

verifygenuine & untampered

diffdoes it affect me?

classifyroutine / approve / ceremony

decide + receiptmy own call, recorded

The same update produced different decisions at each peer — apparent coordination, zero central control.

For the technical reader — the command, and how to verify it yourself

# one line · you do not need to run this
see walkthrough

./bl-verify --check-anchor
# -> a sealed update each peer verifies independently

Full step-by-step is in Appendix RX: Hands-On Demonstrations in the book.