Choose relays by who they reach, not by how popular they are

[sepehr-safari]

Ranking by popularity answers which relay should this reader consider adding. It does not answer which four relays reach the most people, and the top four of a popularity list is not that: they all carry the same crowd, and somebody publishing to one quiet relay is never reached however many popular ones are dialled.

Measured on a real account: 215 of 257 follows have a relay list, naming more than 128 distinct relays between them. A long tail of relays with one or two writers each, which no top-N can cover.

So the two questions get two algorithms. Suggestions stay ranked by how many follows write there, which is right for a human reading a list. Connections are chosen by marginal coverage: repeatedly take the relay reaching the most people not yet reached twice, and stop when the next would reach nobody new.

Two is the target because one is enough to see somebody and two keeps a single relay going down from hiding them. Jumble uses the same number from the other end (prune only when every pubkey is covered twice elsewhere). Amethyst wrote this exact algorithm and never called it.

The reader's own relays are pre-seeded as already-paid-for coverage and never dialled again. Without that the greedy spends its whole budget re-reaching the crowd already on nos.lol.

Live, 257 follows

Reached 193, of those 134 twice, 64 residual riding the pool. Chosen: nostr.wine, snort.social, nostr.land, premium.primal — which is not the top of the popularity list.

The silent cap, found and fixed

relay_rank_candidates was 128 and it was a guess. On the same account it was hit exactly, dropping 63 further relay references without a word. That is the silent-cap rule this codebase has, and I wrote the violation myself in #196.

Now 384, with RouteCoverage.candidates_dropped saying so out loud when even that is not enough.

Raising it changed nothing about coverage — 193/134/64 before and after — because the dropped relays were tail entries that would not have been chosen. Saying that rather than implying the fix bought reach: it bought an honest number.

A bug worth recording

g_route_bits is indexed by table position, and the suggestions sorted the table in place. Every bitset silently re-pointed at a different relay, so the routing read one relay's authors and dialled another. The symptom was choosing a relay with two writers over one with four. An order is sorted now, never the table.

Tests

Five, each verified by breaking it:

• coverage beats popularity when the popular relays carry the same crowd (the quiet relay reaching two people must be dialled)
• a relay carrying only people the pool already covers twice is not dialled, even though four follows write there and one writes to the alternative
• a relay the reader is already on is not dialled again but still counts as cover
• one author naming four relays gets exactly two connections, not four
• the candidate cap is counted

The pre-seed probe needed a second attempt: the first version's assertions did not depend on it, so removing it failed nothing.

Second of four

Still to come: per-slot generations so one relay changing does not redial the rest, in-place REQ replacement, hysteresis and a settle window, then the routed budget.