Currently our global discovery server is a single point of failure for most setups. The discussion in the DHT issue is pretty long and I doubt that we’ll come up with a pretty solution for it in the near future.
While we can’t replace it at the moment, we can make clients a little more resilient to temporary outages.
The rough idea is that each node stores discovered addresses of its peers in the local database. Most ISP assign external IPs up to a few days, so chances are that some of them are still dialable.
We can even go a step further and propagate discovered addresses via BEP. This one is a bit tricky as we don’t want to leak information about indirectly connected peers. e.g A knows B and C, but B doesn’t know about C. Limiting this feature to introducers might solve that.
Good idea in principle. We should make sure that the different sources of addresses are stored as metadata, to be able to add filtering later on. And probably also the predicted chances of success. If A found B at some address, it’s likely that it will work for C as well. But some address that A couldn’t dial for B might still work from C’s network perspective, so sending it anyway would not hurt.
But the whole thing should have settings to opt out of sharing stuff from different kinds of sources. Relaying global discovery responses will probably be fine, but locally discovered IPs some people might not want to share, especially with IPv6.
Regarding the confidentiality issue you mentioned, we do already send the other peer IDs (C to B and vice versa, from A) as part of the ClusterConfig message. Which is useful information IMHO. I once started to build some GUI feature on top of that, and will try to pick it up again when I find the time for it.