[tor-onions] Renaming Rendezvous Single Onion Services

[Paul Syverson]

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