[tor-project] [TSoP] stem.client - status report #4
dmr-x at riseup.net
Fri Jul 13 03:53:41 UTC 2018
This is my fourth status report for the stem.client TSoP project .
You may see my previous reports on the tor-project ml. 
This report is much of a week late - I'm quite sorry about that.
I've still been feeling ill, and it's been a bit unpredictable for when
symptoms flare up, so that's been tough to deal with and work around.
(I'm still moving forward, though, just not as effectively as I'd like.)
Some of my progress comes in longer-term plans than I can effectively
showcase here, but I'll try.
## GitHub mirroring
I think #26197  sparked a lot of discussion on Tor's use of GitHub as
a mirror and means to accept PRs. Preliminary discussions when trying to
move the ticket forward by bringing it up in a network-team meeting
revealed a bit of uncertainty into how mirroring was done, and (iiuc)
eventually led to Isa getting involved to survey all the teams on
current and future usage.
It looks like things are working out well for stem now :), and overall
Tor's GitHub usage seems better understood and better standardized!
(For instance, the most recent PR was marked as auto-merged/closed by
'torproject-pusher' today )
I'll continue to be involved as needed to facilitate stem and nyx needs
w.r.t. GitHub repos. (Damian mentioned he's got a lot on his plate
already and asked if I could take the lead on this.)
nyx still doesn't have a repo, so I'll be sure to follow up on this.
## stem.client - re-roadmapping
I continued to push some lingering things in code review  and
architecture  discussions forward.
That led to a reconsideration of goals and roadmap between Damian, teor,
Based on the primary goal of prototype allowing exit traffic, I've
mapped out the main tasks of the remainder of the project as follows:
1. refactor: Relay cell encryption/decryption/processing
2. centralize ORPort reads/sends (demux/mux) at connection level
3. implement required RelayCell subclasses (e.g. parsing of decrypted
4. <potentially: other RelayCell subclasses>
5. use these RELAY cells in Circuit / Stream construction/management
6. re-envision Circuit.send() and other methods (e.g. Circuit.extend())
7. refactor into Stream class, subclass(es)
8. introduce "dumb" path selection for exit traffic
This roadmap will be re-evaluated as progress on #1-3 is made.
## stem.client - further review, fixes
A few tickets/PRs have been done to follow up on Damian's changes ,
which followed up on the previous commits I did from code review. 
These two tickets/PRs include bug fixes and some other improvements:
* NetinfoCell doesn't preserve unused content during unpacking 
* Cell unused content is ignored while packing 
## stem.client - RELAY cells
I've started outlining the class hierarchy for the required RELAY cells,
tackling roadmap items #1-3. It's still in very early stages, so I
don't have changes ready to push.
## stem, general
Nothing to show this time around. I've taken minor notes for 'dev'
tickets, but I won't be pursuing much of these yet, in the interest of
focusing on the roadmap first.
## tor protocol, general
I'm still glancing through the tor-design paper  and updates
 while reading the specification. I think I've read through
enough of the paper now that I won't need to glance often, but I'm still
keeping it in mind.
As I've been working through the spec, I've been tracking changes to
make that improve it. Some of these are just shorthand notes (so I don't
have them available to share in an understandable way), but others have
made it to (probably) solid commits.
I've pushed a WIP branch to GitHub , which I will be rebasing /
force-pushing as necessary. *Please* feel free to check it out - just
don't rely on it to be git-stable.
# What's next
I'll be working on the roadmap mentioned above.
The first thing I'll be working out into commits is moving some of the
bytes-level handling of RELAY cells out of the Circuit class and into
cell.py, since this handling currently seems to violate the abstractions
## stem, general
I still have a few 'dev' tickets I'd like to work on. For a while I've
wanted to work on the tox configuration, but I may break that up into
more important and nice-to-have changes to it.
As aforementioned, I'll continue to push forward on improvements to
Again, you may see what I've got mostly push-ready in my WIP branch on
I'll bring this up in the next network-team meeting and figure out the
best logistics for merging these in.
# Other Tor things
Not too much on the side - still an advocate for Tor in-person when
people chat with me, but it hasn't happened as much in the past few
Still trying to attend the Community team meetings when I can.
As with before, I've been active and reachable over IRC, where my nick
is dmr. Please don't hesitate to reach out to me via IRC or email!
I've been *much* less proactive in reading scrollback recently, in order
to combat some of the reduced capacity due to illness. Please mention my
nick if you'd like to get my attention, otherwise it's *very* unlikely
I'll see it outside of a meeting!
More information about the tor-project