On Fri, Apr 27, 2018 at 6:44 AM, Jonathan Marquardt mail@parckwart.de wrote:
v3 onion services just seem like a way worse deal to the average user and the unknowledgeable admin. Mainly because the addresses are way too long.
Then it's analyzing whether shifting the default to v3 for the clueless and the perhaps at risk is helpful anti-footshooting more than say string length. What are the tools and threat models where v3 overrides v2. Do they include proper educational docs and config options. Are such things themselves an intolerable risk.
Before at least Facebook, DuckDuckGo, The New York Times, the Debian Project
What capabilities, including string representations, do such large public realworld services, and their users, need. Are those served by v3 and or v2. Are they trading something for the other.
Mainly because the addresses are way too long.
Though ux was mentioned, v3 can be mangageable by users to whatever degree. In onionland, there's usually commentary that some do memorize a few memorable v2 onions if generated lucky (phonetic, etc) or by regex matching generators, fewer users brute memorize hard v2 strings, the rest just bookmark / file them, or use various search / entry portals. Though v3 is a bit unwieldy, that gets traded off by those that need the capabilities that only v3 can provide. Among those that do know of v3, but don't explicitly need its capabilities, yes, they often choose v2 for that reason, in that case that's probably reasonable.
"Deprecation" may be vague term... a) If defined as shifting v3 to be "provisioned by default" via docs and function, while *continuing to support v2* functionality on the network, there's no problem, everyone is happy. b) While v2 and v3 do share some capabilities, since v2 and v3 do offer their own exclusive subset of capabilities to users that cannot currently be found in the opposing version, *removing v2 support* is a definite issue.
v3 is a nice advancement and is needed by lots of users for what it can do for them, just as v2 is.