As far as tutorials go, I was thinking about dealing with manual stream attachment (as a follow up to #8728), exploring more operations on circuits i.e. tearing down, forcing hops through specified countries or address ranges (maybe a more robust example as an excuse to come up with good use cases for REDIRECTSTREAM and TRUNCATE).
Great! Actually I was just thinking about this yesterday too. Indeed, a couple things that would be great to have are...
* A truncate_circuit() method. From what I can tell TRUNCATE isn't an operation (just a REMOTE_REASON for CIRC events), so this might require expanding the tor controller interface.
* The ability for new_circuit() and extend_circuit() to handle paths where tor picks some of the hops. For instance...
circ_id = controller.new_circuit([None, None, 'amunet1'])
... to construct a circuit where tor picks the first two hops normally but we exit through amunet1. There are a couple ways of doing this. The right way is to add this capability to tor, and the hacky way is to construct a normal circuit, truncate the exit, then replace it.
If you're willing to get your hands dirty with tor code as well as stem then two other things that have been high on my wish list are...
https://trac.torproject.org/7953 https://trac.torproject.org/8323
Though that said while these would certainly make for a meaty proposal a lot of this work would be C rather than Python. I'd understand if that makes this less than appealing - there's plenty of other options too.
Some stem specific ideas are...
* Navigation of our API documentation presently sucks a bit. Two ideas for things that could help it are...
https://trac.torproject.org/7632 https://trac.torproject.org/8780
* Controllers often iterate over descriptors but it's presently horribly inefficient. The trouble is that we read the full controller response into memory which can be hundreds of kilobytes and parse it before providing the first reply. Unfortunately fixing this will be tricky, requiring some additional capabilities in the stem.socket module.
https://trac.torproject.org/8248
* As you've found the process for attaching a stream to a circuit is presently pretty clunky. Maybe the controller should have a method that takes two arguments: a circuit id and a functor which will generate a stream. It then makes the stream, attaches it to the circuit, and returns to the caller when its done?
Besides that I'm really having trouble coming up with meaty ideas that solely involve working on stem. Most ideas that I'm coming up with are either limited by tor's control protocol (so would require work in C) or would involve a new project.
One that Karsten warned me away from suggesting for GSoC but I'd love to see happen is Pyonionoo, a python rewrite of our Onionoo service. That project would involve a fair bit of stem expansion...
https://trac.torproject.org/8252
All that said maybe a fresh pair of eyes are best here. Do you have any ideas, maybe some expansion to stems site, capabilities, or tests that you think would make a good project?
Cheers! -Damian