On Wed, Mar 09, 2016 at 12:22:31PM -0500, Aaron Johnson wrote:
All qualitative labels will have this problem: Free, Libre, Open, Closed, Hidden, Public, Private ... all of these describe an abstract intent, rather than a technology. Such qualitative label-names are inevitably presumptuous of {some} implementer's intent.
I am definitely arguing to convey intent rather than to convey technical implementation. We had reached an equilibrium with “single onion services” that nickm upset because it didn’t properly convey intent.
Well I remain completely opposed to anything conveying intent and regard that as just a mistake for our purposes.
The people who understand the technology don't need it, they just need a simple word to use around the office (so to speak). The people who don't understand the technology are going to be misled by anything conveying intent into thinking they are getting something that they're not or just be confused (not "I don't know what that means" but "I think I know what that means, but it's wrong somehow").
First because it won't have the "hidden" "free" "public" "closed" whatever semantics that they will bring with them, and I think are _more_ likely to hurt themselves because of this than if it were given an architecturally descriptive name. You will also need to give them detailed explanations of the system ever after anyway, be it the misunderstanding of "hidden", "anonymity", what have you.
Second, because function creep/new applications is/are bound to happen and it will become a weird misnomer for important or even perhaps the most widespread use, e.g., facebookcorewwwi.onion
Even for internal use just in specs, code, or Tor proposals we should be aware that if they don't have a simple name for the public already, then somebody for some journalistic or other reason will grab a name and use it. (E.g., I'm calling these 'excellent beer services', for my own purposes because it's such an awesome name. 'EBS' for short.)
I favor:
"onion services" for all kinds of err onion services "single onion services" for all kinds of err single onion services
rendezvous can come up as needed, but as Aaron noted is specialized. If you are in a position to ask, you should already have something of a description. (Even if it's coming up in a configuration gui, "Is your single onion service behind a firewall or a NAT? etc. For easy writing RSOS, for easy saying "arr sauce" This becomes even more moot if RSOS are the only kind of single onion services that get widely deployed. (I would currently argue against abandoning the other kind of single onion service design, but that's for another time.)
A possible compromise I'm mixed about, but hey compromise
plain onion services or simple onion services
(Keep rendezvous as needed).
This is a compromise because it can have an architectural as well as intent of use meaning. This means that if the intent of use doesn't apply after some time to some applications, the name still fits. This may still have the users/operators importing their own semantics and thus hurting themselves. But again, compromise. It also loses the nice duality with double onion services. Maybe 'plain' and 'double' can still work together. 'Simple' and 'double' do not as well IMO.
Hmm, time to go for a double big mac... but plain, hold the onions.
aloha, Paul