for v3 support, HSFETCH won't be ncessary...
Noooo...
HSFETCH <v2.onion | v3.onion>
is an absolutely necessary control function now critical to operation of a variety of onionland search / index / status / webhosting / research services, and any other basic commandline checks that have zero wish to be spawning heavy browser / wget / specific application apparatus or wasting resources establishing TCP connections to the services themselves, and for debugging tor client and network itself independant from all such other tools, and helpful for "Why can't I connect" questions from users, etc.
Further, a minimum request and result option semantics of HSFETCH regarding the above were roughly specified previously...
HSFETCH <v2.onion | v3.onion> [fetch_mode] [output_each] [raw_desc] [sync_here] [update_cache] as integrated with vN-DescId and SERVER= elements
General operation - fetch mode: 0 default client resolution method, 1 force from network [3 only, do not recurse to cache], 2 force from cache [4 only, do not recurse to network] - source of the returned descriptor: network, or local cache - network may have different data than cache so [update_cache] or not, default yes - result status of the fetch [a]: ok found, 404 not found, network failure + why: reason - status of the descriptor [a]: ok good, bad + why: crypto failed, expired, parsing data type, truncated, corrupt, etc - decoding and printing out all fields of the returned descriptor, optionally also print the whole descriptor as received, regardless of any bad status, in hex [raw_desc] to further help debugging and other uses For each HSDir by respective HSDir identifier [output_each=true] - above result status of the fetch for each HSDir queried (typically six) - above status of the descriptor from each responding HSDir - above decoding and printing for each responding HSDir [output_each=verbose]
[a] These should be tagged 0 if all sources / HSDirs were ok, or 1 if an ok descriptor was ultimately able to be returned to the fetch but some of the sources / HSDirs had negatives thus pointing to further investigation, or 2 if none were ok (and print the status if all six had same status, or print "various" if they varied).
Since nodes may be performing other tasks in parallel, even over the same onions, and due to various mandatory modes and sources being selected, and network delays, it is very helpful and unambiguous if the output is selectably synchronus to this command and console [sync_here], thus leaving the HS_DESC / HS_DESC_CONTENT event streams doing their thing if so enabled possibly on / for other control connections / monitors. A command instance identifier should be added to be returned to match up with respective event logstream (which would otherwise perhaps be identified as "socks / tunnel / trans / dns / natd / etc" for those sources), but that does not replace utility of [sync_here] for lesser capable users or cases.
Future applications may (and perhaps already do) use HSDir descriptor mechanism as their own datastore via HSPOST, for which similar HSFETCH models would be useful, thus good to consider herein, certainly as an extensible.
There were a tickets and emails somewhere on these concepts so that they could be further and better implemented. Some elements were committed, others remain :)
It is the main reason it hasn't been done that is for a lack of use case. The HSFETCH for v3 is much more tricky in terms of engineering and interface thus we decided to implement it on the "need it basis".
If OnionBalance actually needs it for v3, then we should try to get that on the roadmap.