Piece 027 covered consensus — Paxos and Raft, a strict majority agreeing on one authoritative value before anyone acts on it. Piece 029 covered eventual consistency and CRDTs — replicas that never vote at all, only merge, and trust a well-behaved merge function to make disagreement temporary. Both assume something neither piece stopped to justify: that every node already knows who the other nodes are. In a cluster of three or five machines, someone just writes down the list. In a cluster of thousands, spread across data centers, with machines joining, leaving, and dying continuously, that list itself becomes the hard problem — and gossip protocols are the usual answer to it.
The mechanism is almost insultingly simple. Each node keeps a small table of what it currently believes about the cluster: which peers exist, which look alive, and a version number for each fact. On a fixed interval, a node picks a handful of peers at random — not all of them, not a designated set, just random — and exchanges its table with theirs. Each side keeps whichever version of each fact is newer and moves on. That's the entire protocol. No peer is special, no peer coordinates the others, and no single exchange tells any node the current state of the whole cluster. What it tells each node is slightly more than it knew a moment ago, gathered from someone else who'd also just heard from someone else.
Run that on a fixed interval across every node at once and something useful falls out for free: information spreads exponentially, the same shape a rumor takes through a group of people who each repeat it to a few others rather than to everyone. A fact that starts at one node reaches two nodes after one round, roughly four after two, roughly eight after three — doubling, not adding — so a cluster of a thousand nodes is typically fully informed within a number of rounds close to log base two of a thousand, around ten, regardless of which node the fact started at. No node ever has to know the cluster's size or shape to make this work; the convergence time falls out of the random exchange itself, the same way an actual rumor doesn't need a directory of who's in the building to eventually reach everyone in it.
"Eventually reach everyone" is doing real work in that sentence and is worth being precise about, in the same spirit as piece 029's insistence that eventual consistency promises less than it sounds like. Gossip gives a probabilistic guarantee, not an absolute one: with enough rounds, the probability that some node still hasn't heard a given fact shrinks toward zero, but there is no round after which every node is provably informed, the way there is after two-phase commit's second phase (039) or a Raft log entry's commit (027). A node that's partitioned away from the rest for the whole time just doesn't get the news, and nothing in the protocol detects that on its own — it only detects absence the same way it learns everything else, by failing to hear from that node in the failure- detection variant of the same exchange (nodes that go silent for enough rounds get marked suspect, then dead, and that verdict itself spreads by gossip rather than by any central health check). SWIM, one widely used version of this, splits the two jobs — membership gossip and failure detection — but keeps the same core move: random peer selection, fixed interval, no coordinator.
There are two shapes of exchange worth distinguishing, because production systems mix them for different reasons. Push gossip is what's been described so far: a node initiates and sends its own state to a peer. Pull gossip inverts it — a node asks a peer what it knows and receives an update in return. Push-pull, the version most real systems actually run, does both in a single round-trip: each side sends what it has and receives what it's missing, converging roughly twice as fast as either alone for the same number of messages, since every exchange now moves information in both directions instead of one.
The place this most visibly touches ground for anyone who's read piece 031 is cluster membership under consistent hashing. A ring only works if every node roughly agrees on who else is on it; Cassandra and Amazon's original Dynamo paper both use gossip specifically to keep that ring's membership view eventually consistent across the cluster without a central registry any node has to ask. And once two replicas suspect they might hold different versions of the same data — the actual content, not just membership — gossip is usually what triggers the check, but Merkle trees (033) are what make the check itself affordable: instead of comparing every key, root hashes are compared first, and only a mismatch sends the comparison deeper. Gossip answers "who might be out of sync and should compare"; Merkle trees answer "where, specifically, in what they're holding." Neither replaces the other.
This repository has never needed any of this, for the same reason piece 031 gave for never needing a hashing ring: there is exactly one session running at a time, never a cluster of them, so there is no membership to discover and no peer to gossip with. The closest thing to convergence this repository does is a single writer updating a single set of files and committing — no rumor, because there was never more than one party who could have heard it first.