<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello onioneers,<div class=""><br class=""></div><div class="">We’ve had several naming discussions for single onion services at this point. They started out as “encrypted services”, then they shifted to “direct onion services”, and most recently “single onion services” seems to be winning. I have been collecting all the suggested names at <<a href="https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology" class="">https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology</a>>. I have added all terms in this discussion to that wiki page. </div><div class=""><br class=""></div><div class="">That page also includes other suggested terminology name changes for onion services. The broader “hidden”->”onion” shift seems to have been successful since this was first created, so that’s encouraging! It does seem that everybody still isn’t satisfied with “single onion services”, though.</div><div class=""><br class=""></div><div class="">A couple of points I would make:</div><div class=""> 1. I think it’s really useful to keep “onion services” as a broad term that includes all onion flavors, including hidden, single, etc.</div><div class=""> 2. I think the “rendezvous” adjective is not going to be used outside of discussions by developers. Therefore we need not worry about how ugly or confusing the qualifier “rendezvous" is, and we should feel free to attach it when necessary to make the distinction in our technical documents and discussions. At most, in my opinion, enabling rendezvous for single onion services will be a minor configuration option to be considered when setting up your single onion service. Probably, in my opinion, the non-rendezvous variety of single onion services will never get implemented, because the performance cost of including the rendezvous is incredibly minor, while (i) the cost of splitting the anonymity set of services even further is *not* minor, and *(ii) the advantage of enabling NAT-punching is widely useful.</div><div class=""><br class=""></div><div class=""><div class="">> open: very good, traditional, positive word, but with overloaded meaning</div></div><div class=""><br class=""></div><div class="">For what it’s worth, I like “open onion services” for the reasons Alec stated. “Known” and “overt” seem fine to me, but I like the sound and connotation of “open” better.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Aaron</div></body></html>