On Wed, May 4, 2016, at 10:41 AM, Paul Syverson wrote:
On Wed, May 04, 2016 at 07:36:23AM +0000, Yawning Angel wrote:
On Wed, 4 May 2016 01:30:13 +0000 Alison Macrina alison@libraryfreedomproject.org wrote:
So, I want to propose that we choose onion sites or onion services once and for all (I'm in favor of the former because most users have no idea what is meant by "services"; it sounds too vague). Then, whenever we see somewhere on torproject.org or any of our documentation or whatever that still reads hidden services or onion services, that we kill it with fire.
Disagree, because this further reinforces the idea that the internet is centered around port 80/443, and is nonsensical given some of our prominent use cases ("Ricochet is based around Tor onion services" vs "Ricochet is based around Tor onion sites". One of these statements is correct, and one is not).
To further Yawning's point and provide an example of using both terms: Ricochet is an onion service in which each Ricochet client creates a local onionsite that others connect to.
Actually, for me, the user of the word "service" is something that is a machine-readable endpoint, an API or protocol, while "site" is a meant to have some human-facing aspect that is able to be browsed or read through a web browser or something of that nature.
I would say that Ricochet is only an onionservice, while something like SecureDrop or Globaleaks would be an onionsite that offers onionservices as part of the application.
+n
On 05/04/2016 11:54 AM, Nathan Freitas wrote:
Actually, for me, the user of the word "service" is something that is a machine-readable endpoint, an API or protocol, while "site" is a meant to have some human-facing aspect that is able to be browsed or read through a web browser or something of that nature.
I would say that Ricochet is only an onionservice, while something like SecureDrop or Globaleaks would be an onionsite that offers onionservices as part of the application.
I agree. These terms correspond to existing terms like websites, webpages, and web services.
Just for clarification, it looks like we're thinking: "hidden services": old term, migrating away from this name "onion services": new term, applies to servers bound to any TCP port "single onion service": a non-anonymous onion service "onionsite": a website hosted in the .onion space
We wrote up a proposed terminology for onion services up as part of Sponsor R work: <https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminol... https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology>. I’ll quote the terms we recommended:
1. "onion service" should be preferred to refer to what is now called a "hidden service". If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction. 2. “onionsite" should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as onion chatroom, onion storage, onion cloud service, etc. 3. "onion address" should be preferred to refer specifically to the xyz.onion address itself. 4. “onionspace" should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”. 5. "onion namespace" should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent).
Best, Aaron
On May 5, 2016, at 7:58 AM, Jesse V kernelcorn@riseup.net wrote:
On 05/04/2016 11:54 AM, Nathan Freitas wrote:
Actually, for me, the user of the word "service" is something that is a machine-readable endpoint, an API or protocol, while "site" is a meant to have some human-facing aspect that is able to be browsed or read through a web browser or something of that nature.
I would say that Ricochet is only an onionservice, while something like SecureDrop or Globaleaks would be an onionsite that offers onionservices as part of the application.
I agree. These terms correspond to existing terms like websites, webpages, and web services.
Just for clarification, it looks like we're thinking: "hidden services": old term, migrating away from this name "onion services": new term, applies to servers bound to any TCP port "single onion service": a non-anonymous onion service "onionsite": a website hosted in the .onion space
-- Jesse V
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Aaron Johnson:
We wrote up a proposed terminology for onion services up as part of Sponsor R work: <https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminol... https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology>. I’ll quote the terms we recommended:
- "onion service" should be preferred to refer to what is now called a "hidden service". If other flavors of onion services develop in the future, this term could refer to all of them, with more specific terms being used when it is necessary to make the distinction.
- “onionsite" should be preferred to refer to a website (i.e. an HTTP service serving up HTML) available as an onion service. This can be extended to other specific types of services, such as onion chatroom, onion storage, onion cloud service, etc.
- "onion address" should be preferred to refer specifically to the xyz.onion address itself.
- “onionspace" should be used to refer to the set of available onion services. For example, you can say “my site is in onionspace” instead of “my site is in the Dark Web”.
- "onion namespace" should be used to refer to the set of onion addresses currently available or used "recently" (context-dependent).
Best, Aaron
This is great Aaron, thank you!
Alison
FWIW, the upcoming 1.x series of txtorcon has changed all the class and interface names to IOnionService. The default (an OnionService instance) is "ephemeral" (i.e. uses the "ADD_ONION" API). "Keys on disc in a directory" ones are called FilesystemOnionService and use the HiddenServiceDir APIs.
I am happy to accept new color-schemes for this bikeshed before I release any 1.x stuff ;)
You can follow along via the docs, which I'm trying to change "first" (not always successfully): http://txtorcon.readthedocs.io/en/release-1.x/
Personally I don't care what we call them, but I *do* care about consistency. Stem continues to call them Hidden Services because nobody has offered to take ownership of renaming all the things. For instance the tor, spec, and website codebases still heavily use the old name...
torspec$ grep -i 'hidden service' ./* | wc -l 105
webwml$ grep -iR 'hidden service' ./* | wc -l 369
tor$ grep -iR 'hidden service' ./* | wc -l 1054
... and this doesn't count the dozens of other codebases we have, aliasing torrc parameters, aliasing controller methods/events, etc. Personally I really like Sebastian's idea - hidden services are the name of the old thing, and onion services are the new thing. This avoids a lot of headaches.
That said, renaming is certainly doable. It'll just take someone interested in investing days to hunt down all the old things and make pull requests. The one course of action I *do* object to is saying "we've renamed these to Onion Services" without actually changing all the things. That's just confusing for our users.
Cheers! -Damian
On 05 May (10:28:06), Damian Johnson wrote:
Personally I don't care what we call them, but I *do* care about consistency. Stem continues to call them Hidden Services because nobody has offered to take ownership of renaming all the things. For instance the tor, spec, and website codebases still heavily use the old name...
torspec$ grep -i 'hidden service' ./* | wc -l 105
webwml$ grep -iR 'hidden service' ./* | wc -l 369
tor$ grep -iR 'hidden service' ./* | wc -l 1054
... and this doesn't count the dozens of other codebases we have, aliasing torrc parameters, aliasing controller methods/events, etc. Personally I really like Sebastian's idea - hidden services are the name of the old thing, and onion services are the new thing. This avoids a lot of headaches.
That said, renaming is certainly doable. It'll just take someone interested in investing days to hunt down all the old things and make pull requests. The one course of action I *do* object to is saying "we've renamed these to Onion Services" without actually changing all the things. That's just confusing for our users.
I have to agree here. A very important place imo that we need to change is the "torrc" configuration file of tor where a hidden service is actually configured by an operator. Someone new wanting to setup a "Onion service" will get all sorts of confused when the documentation and options do not exists :).
We opened that ticket some months ago and you can see by yourself the first comment that popped in few minutes after :)
https://trac.torproject.org/projects/tor/ticket/17343
Anyway, I'm fine renaming them which is also a good time for us to take a decision on that because the next generation hidden service (proposal 224), the prefix "hs_" is being used everywhere in the code to identify the hidden service subsytem thus we could settle and use something that is more towards onion service instead.
Cheers! David
Cheers! -Damian _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
We could kill two birds with one stone by calling prop 224 and beyond as "onion services", while everything prior retains the original hidden services nomenclature. This can reduce confusion with old documentation, etc.
-V
On Friday, 6 May 2016, David Goulet dgoulet@ev0ke.net wrote:
On 05 May (10:28:06), Damian Johnson wrote:
Personally I don't care what we call them, but I *do* care about consistency. Stem continues to call them Hidden Services because nobody has offered to take ownership of renaming all the things. For instance the tor, spec, and website codebases still heavily use the old name...
torspec$ grep -i 'hidden service' ./* | wc -l 105
webwml$ grep -iR 'hidden service' ./* | wc -l 369
tor$ grep -iR 'hidden service' ./* | wc -l 1054
... and this doesn't count the dozens of other codebases we have, aliasing torrc parameters, aliasing controller methods/events, etc. Personally I really like Sebastian's idea - hidden services are the name of the old thing, and onion services are the new thing. This avoids a lot of headaches.
That said, renaming is certainly doable. It'll just take someone interested in investing days to hunt down all the old things and make pull requests. The one course of action I *do* object to is saying "we've renamed these to Onion Services" without actually changing all the things. That's just confusing for our users.
I have to agree here. A very important place imo that we need to change is the "torrc" configuration file of tor where a hidden service is actually configured by an operator. Someone new wanting to setup a "Onion service" will get all sorts of confused when the documentation and options do not exists :).
We opened that ticket some months ago and you can see by yourself the first comment that popped in few minutes after :)
https://trac.torproject.org/projects/tor/ticket/17343
Anyway, I'm fine renaming them which is also a good time for us to take a decision on that because the next generation hidden service (proposal 224), the prefix "hs_" is being used everywhere in the code to identify the hidden service subsytem thus we could settle and use something that is more towards onion service instead.
Cheers! David
Cheers! -Damian _______________________________________________ tor-project mailing list tor-project@lists.torproject.org javascript:; https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
tor-project@lists.torproject.org
-
Aaron Johnson -
Alison -
Damian Johnson -
David Goulet -
Jesse V -
meejah -
Nathan Freitas -
Virgil Griffith