[tor-dev] [TSoP] stem.client - introductions

[Dave Rolek]

Hi everyone!

I'm really excited to announce I'll be working on stem for the 2018 Tor
Summer of Privacy! The news is still sinking in.

This is going to be my first major chunk of contributing code back to
the Tor community. :)

In particular, I'll be working on expanding stem's support to act as a
Tor client, aka stem.client, speaking with Tor's ORPort. You can see
more about stem in general [1], and read concepts for stem.client [2],
but at the end of this email I list my high-level plan for the summer
project.

There's definitely more to a Tor client than one can write in a summer,
so my focus is on getting basic client functionality and on fetching
v2/v3 Onion Service descriptors. The official project period is May 14th
through August 21.

My existing work on stem is available by querying through Trac [3]
(easier for context) and browsing patches on GitHub [4].

I've been pretty active on IRC recently, but I wanted to broaden this.
Anyone is welcome to reach out to me with questions/comments!

On OFTC and Trac, I'm dmr.
I plan to attend the network team meetings [5] (at least lurk) to get a
sense of Tor's protocol development and to be around for any
littlet-tor/stem syncing discussions.

I'll also be sending updates biweekly to the tor-dev mailing list and
writing "/me status: [...]" posts in #tor-dev.

Lastly, my mentors for the project are atagar and teor.

Really looking forward to this!

Cheers!
Dave

--
My high-level plan is the following in this rough order:
* continue prework with stem and the tor specs
* get a stronger feel for / strengthen the CI testing for stem
* better understand the ecosystem of projects that use stem
* begin official coding by tackling minor stem.client improvements and
implementing classes for a few more Cell types
* continue developing stem.client.Relay and adding further testing using
more of the Cell classes already defined
* work on relay authentication
* move onto fetching relay descriptors from the ORPort
* work on the RELAY_EXTEN[sion] cells, to build multi-hop circuits
* build upon this to allow actual exit traffic, including implementing
RELAY_RESOLVE[D]
* work on fetching v2 Onion Service descriptors, since I already have
familiarity [6] with that spec, and v2 Onion Services probably will be
around for a while yet
* work on fetching v3 Onion Service descriptors
* work on other stem.client improvements, if time allows
* culminate the project with tutorials and a blog post introducing the
new user-facing features of stem


[1] https://stem.torproject.org/
[2]
https://www.torproject.org/getinvolved/volunteer.html.en#pythonTorClient
[3]
https://trac.torproject.org/projects/tor/query?cc=~dmr&or&reporter=dmr&or&owner=dmr&or&reviewer=~dmr&group=component
^ a bit noisy, sorry; look at "Core Tor"
[4] https://github.com/dmr-x/stem
[5]
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam#MeetingsSchedule
[6] https://github.com/dmr-x/talks

[meejah]

Post by Dave Rolek
Hi everyone!

Hi Dave,

Congratulations on your project/acceptance!

Post by Dave Rolek
In particular, I'll be working on expanding stem's support to act as a
Tor client, aka stem.client, speaking with Tor's ORPort. You can see
more about stem in general [1], and read concepts for stem.client [2],
but at the end of this email I list my high-level plan for the summer
project.

I don't know if you've gotten far enough to discuss code layout/design,
but it would be really cool if you follow the "sans-IO" approach for the
design of the actual "OR protocol" part of the project.

A great example of this is the Hyper/H2 libraries by Cory Benfield for
the HTTP2 protocol -- this what drives Twisted HTTP2 support as well as
threaded (blocking I/O) servers.

https://github.com/python-hyper/hyper-h2

There are several advantages to this approach:

- makes for a nice and clean separation between core "protocol stuff"
and the I/O.
- the above makes testing easier and cleaner (e.g. end-to-end tests
that don't use any "real networking", all in-memory)
- allows use in blocking / threaded implementations but also async
(event-based) implementations (for example, someone could then
leverage the bulk of your work to make an asyncio binding without
having to re-write all the parsing and state-machine code)
- it's the new hotness

I'm usually idling in #tor-dev as meejah, ping me any time

Good luck with your project, sounds interesting!