meejah

Hi @lwm there hasn't been any more work on this, no. The tests in #158 are pretty basic ... One thing that would be *great* to get out of a...

Yeah it's big :/ I will probably merge some of the "completely new" features into 0.x (since they don't change/break any APIs). I would appreciate feedback on the `txtorcon.Tor` object...

"Tor" etc have been merged to master

txtorcon already does this, see https://github.com/meejah/txtorcon/blob/master/examples/circuit_for_next_stream.py or the attach-by-country example both of which build custom circuits and then attach streams to them. Also, "carml" can do it from the command-line...

Hmm, maybe you mean something higher-level like exists in TorFlow? I once tried to understand what that code was really doing, but failed. But at a high level it allowed...

Worth noting I think: it's not possible to attach streams destined to hidden-services (even if the circuit is a rendevous circuit etc); this would require a patch to `tor`.

Yes, I agree about multiple attachers -- but care would be needed for ordering etc. (e.g. call them in order? do they chain?) but not that hard. As to the...

This could potentially be exposed to the endpoint string-parsers, too, so you could maybe have `tor:host=torproject.org:port=443:path=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,bbbbbb....` but that might not be a good idea...

What if `Circuit` instances provided a `.create_client_endpoint` method. This would return an `IStreamClientEndpoint` implementation that -- when `.connect()` is called on it -- makes sure the resulting stream goes over...

Looking at the code @aagbsn pointed to, it seems like the uses-case that code is interested in is "a stream over a circuit which has a particular exit" (doesn't care...