The Question Every Request Asks
Before Delta moves a single byte to another Mac, it has to answer a question that sounds trivial: is that Mac in the same house as me right now? The answer decides everything downstream. In the same house, two Macs can talk over a Thunderbolt cable at tens of gigabits a second or over the house's Ethernet at nearly ten. Away from home, the only road is the tailnet, a WireGuard mesh that crosses the internet and, in the family's measurements, moves about a third of a gigabit per second even when both ends sit on the same desk. Pick wrong in one direction and a 1 GiB file takes twenty seconds instead of a third of one. Pick wrong in the other and a laptop in a café spends its connect timeout dialing an address that only exists at home.
So the question matters, and it is easy to answer badly. This lesson is about answering it from facts.
Four Wrong Answers
- A machine name. "The workbench is always at home" is true until the day it is not, and a name says nothing about which cables are plugged in. Delta's invariant 8 forbids it outright: no address, port or machine name in code.
- A hard-coded address. Addresses change when a router is replaced or a lease expires, and a list of them in a config file is a second source of truth that drifts silently.
- A subnet that looks familiar. Home and hotel routers hand out the same handful of private ranges by default. A laptop in a hotel can sit on a network with exactly the same prefix as the home LAN. The match is a coincidence of numbering, not a fact about the room.
- "It answered a ping quickly." Latency is a symptom, not an identity. A fast answer from an address you guessed proves that something lives there.
The Right Answer, in Three Facts
Delta's rule (the same one the family's NAS mounts already used, Coop 1108-9) is called on-link, and it is built from three facts nobody had to remember:
- The peer says where it is. Every Delta publishes
/v1/identity, and one of its fields,lan, lists the peer's own physical addresses: address, prefix length, interface and link kind (thunderbolt,ethernetorwifi). This Mac reads that document over the tailnet, where the caller is already authenticated, and checks that thelabelinside it is the Mac it meant to ask. A peer cannot be impersonated by whoever happens to answer on the LAN, because the LAN is not where the question is asked. - This Mac knows its own interfaces.
networksetup -listallhardwareportssays which device is the Thunderbolt Bridge, which is Ethernet, which is Wi-Fi;ifconfigsays which of them are active and what private addresses they hold. Link-local and loopback addresses are discarded: a self-assigned USB interface is not a road to anywhere. - The routing table agrees. An advertised address is a candidate only if it falls inside the network of one of those live interfaces and
route -n get <address>names that same interface with noGATEWAYflag. No router in between means the packets go straight down the wire to the peer.
If no address the peer advertised passes all three, the reason is written down in plain words, away: no address of the peer is on-link with an active physical interface here, and the route is the tailnet. Nothing was guessed and nothing was configured.
On-Link Is Necessary, Not Sufficient
Go back to the hotel, and say both networks happen to use the same prefix (written here in the documentation range, 192.0.2.0/24). The peer advertises 192.0.2.20; the laptop sits on the hotel's 192.0.2.0/24; route -n get happily says en0, no gateway. All three facts pass, and the conclusion is wrong. Delta does not stop at on-link. Every candidate must also answer GET /v1/health before it is chosen, with a short connect timeout (two seconds for Thunderbolt, three for the LAN). In the hotel nothing answers on Delta's gateway port, so the candidate fails, the failure is listed in the route's reason, and the tailnet wins. And if some stranger's device did answer, the shared-LAN route is TLS pinned to the certificate fingerprint the peer published over the tailnet (track 4): a mismatch refuses the route before a single request goes through it.
That layering is the real lesson. Each fact is cheap and each is fallible. Stacked, with the expensive check (a real request to the real peer) last, they make a decision you can defend line by line.
What It Costs, and Why It Is Memoized
Reading the interfaces means three subprocesses (networksetup, ifconfig, route), and those are slow next to a thumbnail request. On 2026-11-09 a revalidated Eagle thumbnail over the Thunderbolt bridge took 56 to 62 ms, because every request on a cached LAN route re-ran all three to prove the peer still on-link (and wrote a ticket's last-use time to SQLite besides). The fix kept the rule and moved the cost: this Mac's interface facts are memoized for 10 seconds, a route's on-link proof is re-checked at most every 10 seconds, and a request that fails still drops its route at once. On the serving side, the lan list in the identity document is cached for 30 seconds; on the asking side, a peer's whole identity document is kept for five minutes. Each layer stores a fact for a stretch shorter than the time it takes a person to unplug a cable and carry a laptop out the door.