<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div></div><div>Hi All,</div><div><br></div><div>There seems to be some confusion in this thread about the</div><div>current state of the hidden service to onion service name transition.</div><div><br></div><div>So I'm going to describe the state of things as they are, then try to</div><div>describe what would need to be done.</div><div><br></div><div>I'd also appreciate feedback from Steph and others on our priorities for</div><div>transitioning to the onion service name. I think we have been prioritising</div><div>user-facing text. (The blog, website, Tor Browser, metrics, etc.)</div><div><br></div><div>Is this a sensible way of prioritising things?</div><div><br>On 26 Apr 2018, at 16:42, Paul Syverson <<a href="mailto:paul.syverson@nrl.navy.mil">paul.syverson@nrl.navy.mil</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite"><span>Have OnionService aliases for controller commands, events, </span></blockquote></div></blockquote><div><br></div><div>These are current called "hidden service" or an abbreviation.</div><div><br></div><div>Tor could add an alias mechanism for controller commands, events,</div><div>and fields, and use it to do the rename:</div><div><br></div><div><a href="https://trac.torproject.org/projects/tor/ticket/25922#ticket">https://trac.torproject.org/projects/tor/ticket/25922</a></div><div><br></div><div>I don't think they are as high a priority as the torrc options and man page.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>descriptor</span><br></blockquote><blockquote type="cite"><span>fields</span></blockquote></div></blockquote><div><br></div><div>These are currently called "hidden service", or an abbreviation.</div><div><br></div><div>Descriptor fields are part of the directory specification and</div><div>implementation, and they are highly technical. So I'm not sure we gain</div><div>much from aliasing them or renaming them.</div><div><br></div><div>Similar arguments might apply to other codebases:</div><div>* Onionoo</div><div>* stem</div><div>* consensus health</div><div>* Tor (network daemon)</div><div><br></div><div>But the following user-facing applications should add documentation or</div><div>change names, if they haven't already:</div><div>* Relay Search / metrics website</div><div> * uses HSDir for relay search, because that's what it's called in the</div><div> directory protocol</div><div> * uses "onion service" for statistics</div><div>* Tor Browser</div><div> * uses "onion site"</div><div>* the Tor website</div><div>* new tor blog posts</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><span> and anything else referencing 'HS' or 'HiddenService'.</span></blockquote></div></blockquote><div><br></div><div>We considered adding OnionService* torrc option aliases for every</div><div>HiddenService* option in 0.2.9. But we deferred that change because we</div><div>ran out of time.</div><div><br></div><div>All we need to do is add some new entries in the alias table, then do a</div><div>search and replace in the tor man page:</div><div><a href="https://trac.torproject.org/projects/tor/ticket/17343">https://trac.torproject.org/projects/tor/ticket/17343</a></div><br><blockquote type="cite"><div><blockquote type="cite"><span>Speaking of which, how do we plan to replace abbreviations? Having an</span><br></blockquote><blockquote type="cite"><span>'OSFETCH' or 'OS_CREATED' event doesn't exactly have the same ring as</span><br></blockquote><blockquote type="cite"><span>their HS counterparts. ;P</span></blockquote></div></blockquote><div><br></div><div>That's a good question.</div><div><br></div><div>OS conflicts with "operating system", so we could use:</div><div>* Onion</div><div>* OnSrv</div><div>* no abbreviations</div><div>Or any other colour you want to paint the bikeshed.</div><div><br></div><div>To avoid an endless discussion, let's leave the decision to</div><div>the people who write, review, and merge the code.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>Adjust all our docs to be consistent about the name.</span><br></blockquote><span></span><br><span>Right, anything v3 should be consistently calling these 'onion</span><br><span>services'. Variable names, etc. particularly those still in use in</span><br><span>code shared with v2, don't need to be changed. It is OK if such</span><br><span>vestiges of older usage remain in abbreviations, as long as the</span><br><span>description of them, e.g., in any new Tor proposal, describes them</span><br><span>with appropriately current terminology.</span></div></blockquote><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">torrc options, the tor man page, and the v3 onion service </span><span style="background-color: rgba(255, 255, 255, 0);">code</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">mainly use "hidden service", and sometimes use "onion service".</span></div></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I don't see much value in changing the code.</span></div><div><br></div><div>If we decide there is value in changing the torrc options and man page,</div><div>we need to allocate a few days of work on the roadmap to make it</div><div>happen.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>Renaming takes work. Lesson I learned from Nyx is that it works best</span><br></blockquote><blockquote type="cite"><span>if you draw a line in the sand and stand by it. With Nyx, version 2.0</span><br></blockquote><blockquote type="cite"><span>is called Nyx (you won't find any docs saying otherwise) and version</span><br></blockquote><blockquote type="cite"><span>1.x is the legacy 'arm' project.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If I was in your shoes I'd opt for the same. Either prioritize the</span><br></blockquote><blockquote type="cite"><span>aliases and be firm that v3 are 'Onion Services' or abort the rename.</span><br></blockquote><blockquote type="cite"><span>Otherwise this will live in a confusing dual-named limbo land</span><br></blockquote><blockquote type="cite"><span>indefinitely. ;P</span><br></blockquote><span></span><br><span>I'm prettty sure that v3 being 'onion services' has been the official</span><br><span>Tor Project position since at least half a year. We wouldn't be</span><br><span>aborting the rename, because 'abort' would imply it is not</span><br><span>complete. Anything now not using the current name is not part of an</span><br><span>incomplete process, it is simply wrong and outdated. Steph correct me</span><br><span>if I am wrong about that.</span><br><span></span><br><span>So I think you've answered your own question. Nothing in v3 should be</span><br><span>called 'hidden services'.</span></div></blockquote><div><br></div><div>That's not the current state of the tor network daemon v3 onion service</div><div>code, specs, options, and man page. They use a mix of terminology</div><div>(see above).</div><div><br></div><blockquote type="cite"><div><span>And anything new in code and documentation</span><br><span>should be called 'onion services'. </span>If you want to think of v2 and</div></blockquote><blockquote type="cite"><div><span>earlier as 'hidden services' for purposes of understanding legacy</span><br><span>component and variable names, e.g., HSDir that's fine. And as such,</span><br><span>variable names, etc. in code that continues to be used for both v2 and</span><br><span>v3 can can persist. But again, any new specs, documentation, etc.</span><br><span>should call them 'onion services'.</span><br></div></blockquote><div><br></div><div>We have gradually been using onion services in new documentation and</div><div>specs, since "single onion services". But we haven't changed existing</div><div>code and documentation.</div><br><blockquote type="cite"><div><span>This acceptance of existing v2 documentation calling them 'hidden</span><br><span>services' while refusing this for anything v3 is a little misleading</span><br><span>about when and why the naming transition happened, but its close</span><br><span>enough to serve as your line in the sand if you feel one is needed. </span><br><span>I actually argued the value of essentially such a line-in-the-sand</span><br><span>position to Steph a while ago. This doesn't preclude also calling v2</span><br><span>and earlier 'onion services'. Indeed, it's not just OK but preferable,</span><br><span>for the above mentioned reasons.</span></div></blockquote><div><br></div>It looks like we are doing a gradual transition. I think we prioritised</div><div>the things that are seen by the most users (Tor Browser, statistics,</div><div>blog, website).</div><div><br></div><div>We did not take a line in the sand position in the past, but we could</div><div>adopt one for the remaining changes. We could decide on a particular</div><div>Tor release (and releases of other codebases). But we need to schedule</div><div>the work on the relevant roadmaps.</div><div><br></div><div>And maybe there are some obscure technical things (code, comments,</div><div>descriptor fields) that just aren't worth changing.</div><div><br></div><div>T</div></body></html>