I'm not entirely sure whether it is due to low usage or little problems with the service, but it seems to work pretty OK. My primary concern is that as opposed to DNS based system, the onionbalance system requires my node to be running and available and as such constitutes a SPOF. Although I've cleaned up my scripts sufficiently, e.g network outage will make this service unavailable whereby the hkps pool will continue to function.

I spoke with the author of onionbalance, and they said:

normally the single onionbalance daemon is the SPOF. One solution for this is to run multiple onionbalance daemons with the same configuration on different machines.

Each onionbalance daemon will publish it's own master descriptor and these descriptors will replace each other on the HSDirs. If either daemon stops, then the other daemon will keep publishing an updated master descriptor.

So if the SPOF is the only thing @kristianf has a concern, he could:

• run a second instance of onionbalance, on distinct infrastructure
• share the config information (and, presumably the coresponding secret key) with another party, so that they can run the second instance.

I note that back when we were shipping "skeleton" options files, the default dirmngr.conf actually did include the onionbalance address as well, so some people may already have inherited that configuration. However, i think that was before dirmngr tried to opportunistically connect to tor, so presence of that configuration would have been masked except for those folks who manually set use-tor.

Thanks, that is interesting info, I need to look into that.