[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