[tor-dev] onion v2 deprecation plan?

[grarpamp]

On Wed, Apr 25, 2018 at 2:22 PM, nusenu <nusenu-lists at riseup.net> wrote:
> even though you are probably years away from deprecating onion v2 services
> it is certainly good to have a clear plan.
>
> I'm asking because the sooner onion v2 are deprecated the sooner some
> people can stop worrying about malicious HSDirs.

The publisher of the onion is the one who decides which to use
and what level of concern / tech applies to their use case.
In onionland, there seems to be little knowledge of v3, thus little worry
about v2 in cases where v3 would actually apply to benefit, that's bad.
And mooting of v3 in cases where it doesn't much benefit use case.
Rather than removing v2 support from the code [1]...
- the risk / benefit / tradeoffs / ux / uses of v2 vs v3 should be widely
publicized to educate about v3.
- common tools and applications such as ricochet, onionshare,
onioncat, onionvpn, bittorrent, securedrop, control, stem, nyx, etc
should add v3 support, thus also feeding back into education.
- some future release should change the default
documentation and operation inflection from v2 to v3.
At that point if a user goes to create an onion, everything
should lead to and result in them having created a v3,
other than a standalone v2 reference section in manpage on how
to create v2 onions, and continue v2 dirservices support, etc [1].

[1] v2 does have legitimate long term use cases exists,
there's a ticket opened for extended nonremoval support of v2.