On Wed, Apr 25, 2018 at 2:22 PM, nusenu nusenu-lists@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.