Closed 1977er closed 2 years ago
Why is this blocked?
Furthermore, whether permanently unavailable supernodes like sn02, sn03 or sn07 should have a key could depend on the intended implementation of wgpeerselector. Maybe @CodeFetch or @lemoer can say something about how the dead keys might affect the connection establishment.
Something minor, but having only existing supernodes on the statuspage is something I find pretty satisfying and intuitive.
At very least I want to hear proper arguments, like 'in order to deploy supernodes faster without new firmware' and not something about
good-old fastd times ...
I have no problem with filtering supernode listings on the status page based on their current existence.
In the past we managed to lose supernode private keys. The more we have on a node the better. Imaging a firmware with only three keys: we would not be able to connect to that node ever again, if we lose all three.
@AiyionPrime The dead keys are not a problem. The peerselector is very fast.
In good-old fastd times we shipped cryptokeys for ten supernodes (sn01...sn10.s.ffh.zone). The current wireguard firmware only ships keys for the currently known sn01, sn05, sn09 snd sn10.
This is okay for a (closed) beta release but should be fixed for a public (beta/gamma) release.