[tor-dev] Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"

[A. Johnson]

> I've been hesitant to weigh in on the naming conversation for hidden services. But I am concerned about the issues raised in the previous few emails on the topic.
> 
> Matt @ Speak Freely has a strong point about acronym collisions - they only serve to confuse users and dilute the search space. And usability becomes a security issue as soon as names are confusing to users.

I agree that it is helpful to have a unique acronym. However, I think that a more important naming principle (and one that has been omitted) is:
  4. Names should be easy to use
The suggestions (Client Anonymous Hidden Services, Exposed Server Hidden Services, Public Server Hidden Services) are all very long and not something that I would like to regularly use in conversation (oral or written). I would also argue that these suggestions violate 3A, in that direct onion services are not “hidden services” at all.

As far as “direct onion services” not describing which end is anonymous, I agree that a more descriptive term could be useful. The terms “server-direct onion service” or “server-known onion service” would satisfy this. Those are as long as the suggestions that you made, and so not great for regular use, but I can see such terms being used occasionally when clarity is important.

Aaron