[tor-dev] RFC: Ephemeral Hidden Services via the Control Port

carlo von lynX lynX at time.to.get.psyced.org
Tue Feb 17 12:07:06 UTC 2015


Let me chime in on saying that this looks to me like a great 
development. I even imagine that in a couple of years most
end-to-end encrypted services on the Internet may be using
this interface, so for the sake of accessibility for future
devs, I would suggest something totally superficial:

On Sat, Feb 14, 2015 at 12:45:24AM +0000, Yawning Angel wrote:
>   ADD_EPH_HS - Adds a new ephemeral hidden service.

The "ephemeral" vs current behavior seems to be an aspect
that might go away soon anyway, so I would leave the cryptic
"EPH" out. Also, the idea that hidden services are hidden is
a bit outdated - many are intentionally not hidden at all and
only interested in the aspect of providing authenticated end-
to-end encryption and/or anonymization for the calling entity,
so "HS" isn't exactly an acronym which speaks a clear language.
Thus I would think it will be easier for future generations of 
devs and sysadmins to grok this, if the functions were simply
named

    ADD_SERVICE,
    REMOVE_SERVICE.

Concerning the "ephemerality" of it, I can imagine services
being configured en passant by a cat >> socket from a shell
script or so, while the actual application was merely told
to receive connections on localhost:something and has no
awareness of Tor at all, like most Tor HS are, I presume.
So in the spirit of Leif's suggestion I would make the 
dependency on a ControlPort link staying up the non-default.

KUTGW!


-- 
  E-mail is public! Talk to me in private using Tor.
  torify telnet loupsycedyglgamf.onion		DON'T SEND ME
          irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
         http://loupsycedyglgamf.onion/LynX/    OR FACEBOOGLE


More information about the tor-dev mailing list