[Twisted-Python] tor hidden service endpoint parser returns a deferred

[David Stainton]

>> Ah ha! Of course it is so obvious now that you point it out to me.
>> The onion endpoint parser can do this setup work in it's  `listen`
>> method which returns a `Deferred`.
>> Thanks for your observation/advice!
>
> Cool! Thanks for doing this. Can I pull it into txtorcon when it's
> finished?

Yes of course! I have every intention of helping out the Tor project
as much as I can... I want as many developers to benefit from this as
possible so that many more applications can and will utilize the tor
network... for anonymity, censorship resistance and great good.

> Also (more from the Tor end), someone specifying a service will also
> want to specify the keys for that service. Following the 'ssl' stuff, I
> guess something like "onion:80:hiddenServiceDir=/dev/shm/foo" might be
> appropriate? Or perhaps even a way to specify the private key directly?

Yes... precisely what I was thinking. For now specifying a directory
containing keys might be good enough...
but like you say... I should also provide a way to specify the private
key directly. Sounds good!

> ...and to bikeshed a bit, what about "anontcp:" as a prefix? Then for

Yes I agree this is essentially in the bikeshed category of discussions.
Let's try to reach consensus. Perhaps off the tahoe-lafs and twisted
mailing lists... and perhaps on the tor-dev list.
I look forward to collaborating with you (and anyone else who wants to
help out).

> client-side strings, it could look similar
> (e.g. "anontcp:encrypted.google.com:443") which could in worst-case
> launch a new tor instance, wait for it to bootstrap etc in
> connect(). Perhaps "looking similar" is a non-feature, though :)

Yeah... earlier today I also got the naive client side tor endpoint
parser working.
It uses txsocksx of course. I briefly chatted with the txsocksx author
_habnabit on #twisted about possible designs for the client side tor
endpoints. Basically we seem to all be on the same page.... in that
there may well be a need for multiple types of client side endpoints;
We can have an endpoint that has internal logic to retry the tor
connection on various ports; 9050, 9150... and another tor client side
endpoint that launches it's own tor process (using txtorcon of course)
and then uses txsocksx to establish the socks connection to tor.
Or maybe it'll be the same endpoint that behaves according to the
arguments it's passed.

> Another point for this is that "someday" tor will have UDP support...
>
> thanks,
> meejah

cheers,

david