[tor-dev] onion v2 deprecation plan?

[grarpamp]

> 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.