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