The core issue is that the bridge strategy we're currently implementing calls for hard coding the default bridge IP address inside the tree. This hard coding was meant as an interim strategy. We originally wanted to deploy additional bridges.
However, robustness would be even bigger if we can re-add some DNS back into the mix. This would allow us to have a way to be resilient in case we're forced to change the whole set of IP addresses that we're using.
It would also be useful to improve the overall documentation about the bridge strategy, at least as far as its implementation inside the ooni/probe-cli tree is concerned. We should probably do something similar to what we did with the "mini ooni run v2" prototype and have a document inside probe-cli.
The core issue is that the bridge strategy we're currently implementing calls for hard coding the default bridge IP address inside the tree. This hard coding was meant as an interim strategy. We originally wanted to deploy additional bridges.
However, robustness would be even bigger if we can re-add some DNS back into the mix. This would allow us to have a way to be resilient in case we're forced to change the whole set of IP addresses that we're using.
It would also be useful to improve the overall documentation about the bridge strategy, at least as far as its implementation inside the ooni/probe-cli tree is concerned. We should probably do something similar to what we did with the "mini ooni run v2" prototype and have a document inside probe-cli.