Repository navigation
multi-region, bake in lat/long to fixed-region conn blobs, have clients search nearby regions? #7
Description
To improve robustness of static connection tokens, perhaps they should optionally include the derp region's lat/long too, and then if the DERP map changes over time, the client can try the nearest two (Haversine distance probably good enough) to look for the server's public key again
And/or maybe the server should be able to register at two DERP regions.
Activity
gmkbenjamin commentedon Sep 4, 2026
Context: I'm looking at tailcat to manage remotely deployed devices that
move between locations, so being able to reach them reliably is the thing
I care about most here.
It might help to separate the failure cases, because they don't all have
the same answer.
The map changes. Say fra gets retired or renumbered. lat/long handles
this in principle。
The server moves. Here lat/long works against you. A device I ship from
Frankfurt to Tokyo comes back up on tok, but its address still carries
fra's coordinates — so a client working outward tries nyc and sfo first and
tok last, which is the one place it actually is.
A region goes dark. Multi-region helps with movement, since the regions
stay put even when the device doesn't. But naming two of four is naming
half the map, and each region currently has a single node, so one node
going down takes the whole region with it.
Given the map is four regions today, probing them by node key seems like the
simplest durable answer: at that size it's one parallel round rather than a
search, and it assumes nothing about where the server went, so movement, a
retired region and a changed map all come out the same. It only kicks in
once an address has already failed.
Curious what you think.