Network Team

About us

Welcome to the Network Team page. The Network Team is a group of Tor people who are working on Tor back-end: the program called tor, the pluggable transports, the bridge distribution, the network simulators, the scripts that supports directory authorities, onion services, etc. Basically, everything that sends and receives bytes from the network.

One of the reasons we are not listing the names of the team members here is because we want to keep the team open to everyone. You're on the team if you're participating in discussions and development, and you're not part of the team anymore if you decide you want to move on (which we hope won't happen).

Excited about joining the team? Here is more information on how to get started.

Meetings Schedule

We use IRC for our meetings, we meet on the OFTC network. (See detailed schedule for which channel; it varies by day.)

Primary team meeting (in #tor-meeting)
(except for the first meeting each month)
Monday 18:00 Monday 19:00 Monday 13:00 Monday 10:00 Tuesday 04:00
Monthly retrospective (in #tor-meeting) Tuesday 20:00 Tuesday 21:00 Tuesday 15:00 Tuesday 12:00 Wednesday 06:00
Patch party (in #tor-dev)
First team meeting each month (in #tor-meeting)
Wednesday 23:00 Thursday 00:00 Wednesday 18:00 Wednesday 15:00 Thursday 09:00
Optional catch-up (in #tor-dev) Thursday 11:00 Thursday 12:00 Thursday 06:00 Thursday 03:00 Thursday 21:00

(strikethrough means that most people in that timezone are asleep.)

The boldfaced time for a meeting is canonical in its time zone; the other times are computed and might not be correct for a given location depending on factors like daylight saving time. The primary meeting will track US daylight saving time. The canonical Patch Party time is in UTC and will not change with daylight saving time. The optional catch-up will track European daylight saving time.

If you want to participate, try to show up to the team meeting or patch party. Either one should be fine, though the primary meeting will be more attended. (If you need to meet during the optional catch-up, please let people know a few days in advance.) The meeting times are roughly 8 hours apart in the hopes that one will be convenient for each pair of time zones.

Also note that these meeting times are not permanent. We sometimes need to reconfigure them from time to time as developers join, as people's schedules change, and as the global daylight savings slouches across the face of the earth. See the tor-dev mailing list for updates.

For other type of meetings, see:

How we work

Besides meeting every week on IRC for status update and team discussions, our team also uses the following mechanisms to organize our work:

New features starts with proposals - normally we discuss them on tor-dev@ mailing list and try to finalize the discussions on IRC meetings.

How to find us

We have what we call 'patch parties' meetings, they are for any volunteer to come with patches they want to discuss or need review for. Check out the meetings information above for more details.

If you want to reach someone from the team between these meetings to ask a development-related question, just go to #tor-dev IRC channel, and somebody from the team might either be around or appear later and get back to you.

Our asynchronous medium of communication is the tor-dev@ mailing list. This list is public in the sense that anyone can subscribe, send emails and read archives. Feel free to subscribe and just listen if you want, and feel free to post if you have a question that you think is on topic.

Becoming a volunteer

Thanks for volunteering with us! This part of our wiki is a collection of information we believe might be useful for you who wants to help us develop our tools.

Getting started

You could start by submitting a patch! Patches can help you learn our code and how our team work.

Tips on finding a patch to work on

We have people on rotation triaging bugs every week, you could look for one of them online and ask for suggestions of what to work on.

Or you can dig it yourself! You are welcome to just create new tickets on if there is something in particular that you want to help with or a bug you found and has a patch for.

Tips on finding your way around our code

For the past couple years we spent great amount of our time documenting our code to help people understand it. Here are some links for documentation that will help you get started with our code!


The HACKING/ folder has helpful information about what you need to know to hack on Tor!

  • First, read to learn how to get a start in Tor development.
  • If you've decided to write a patch, CodingStandards.txt will give you a bunch of information about how we structure our code.
  • It's important to get code right! Reading will tell you how to write and run tests in the Tor codebase.
  • There are a bunch of other programs we use to help maintain and develop the codebase: can tell you how to use them with Tor.
  • If it's your job to put out Tor releases, see so that you don't miss any steps!
  • A very important part of our development is code review, if you would like to collaborate with this part or want to sharp your skills in this front, check


The core Tor development team created tor-guts, a compilation of chapters that aims to explain the general structure of the Tor codebase, how it fits together, what functionality is available for extending Tor, and gives some notes on how Tor got that way.

Some of the things we cover with this documentation:

  • Chapter covers networking and filesystems functions that helps us wrap differences between various operating systems we support.
  • Chapter is dedicated to Lower-level cryptography functionality in Tor, in general Tor code shouldn't be calling crypto library directly (e.g. OpenSSL), this documentation helps developers understand the functions available in src/common/crypto\*.c or src/common/tortls.c that they can use these libraries indirectly.
  • Chapter cover Tor’s time-related functions, they exist to help developers parse time, or access cached time for when you have to do thousands of call and don’t want to overload the system, or information on how to schedule things.
  • Chapter it's full of functions for manipulating the C string abstraction. It contains some often-missed highlights that will be helpful for developers who learning the ‘tor way’ of doing things in order to collaborate with our code base.
  • Chapter talks about the different collections we have available and how these resources are useful when writing code for Tor.
  • Chapter describes Tor’s functions for memory management. We advise developers to never use 'malloc', 'calloc', 'realloc, or 'free' on their own; always use the variants prefixed with 'tor_'. We also explain Tor’s convention for when the developer is writing their own functions, and some other choices we have made to help collaborators understand them.

Modules and functions:

We use doxygen to generate documentation in html out of our comments on the code. With that we have documentation for all the modules in Tor, their data flows, their intended interactions, and their actual behaviors. As well as nearly all the functions.

You will find this documentation in two places:

  1. In the source code, at the start of each C file.
  2. When you click on individual C files under (scroll down to "detailed description").

More on Network Team

Task Tracking

Older Releases

Tor Meetings


Processes and Policies

These policies are older than our meta-policy:

These processes are older than our meta-policy:


Provisional policies:

Active Sponsors and Contracts


The projects from sponsors/contracts that are making this work possible are:

Sponsor: Sponsor27-can (5 matches)

Ticket Summary Status Owner Priority Points
#20212 Tor can be forced to open too many circuits by embedding .onion resources new tbb-team Medium 6
#23764 hs-v3: No live consensus on client with a bridge new High 10
#24973 Tor should be more gentle when launching dozens of circuits at once new Medium 16
#26294 attacker can force intro point rotation by ddos needs_revision asn Medium 7
#31223 Research approaches for improving the availability of services under DoS new Medium 15

Sponsor: Sponsor27-must (12 matches)

Ticket Summary Status Owner Priority Points
#14389 little-t-tor: Provide support for better TBB UI of hidden service client authorization new tbb-team Medium 24
#21952 Onion-location: increasing the use of onion services through automatic redirects and aliasing needs_review acat Medium 6
#26768 Support onionbalance in HSv3 assigned asn Medium 8
#28005 Officially support onions in HTTPS-Everywhere new legind Medium 20
#29995 Objective 1, Activity 1.1: Make v3 the default on Core Tor stable new Medium 72
#29998 Objective 1, Activity 1.2: Adopt OnionBalance features into onion services v3 new Medium 23
#30029 Objective 2, Activity 5: POC for Human-memorable addresses for .onion services new tbb-team Medium 50
#30200 Potential circuit timeout issues on onion service circuits assigned dgoulet Medium 12
#30237 Tor Browser: Improve TBB UI of hidden service client authorization needs_review mcs Medium 17
#32542 hs-v3: Add the 2 missing SOCKS extended errors from prop304 needs_review dgoulet Medium 1
#32563 Merge HSv3 spec fixes we found during onionbalance creation assigned asn Medium 0.2
#32709 hsv3: Support onionbalance keys when handling INTRO2 cells assigned asn Medium 5

Sponsor: Sponsor28 (1 match)

Ticket Summary Status Owner Priority Points
#33019 Allow dynamically and statically linked PTs to be loaded into a Tor binary assigned ahf Medium 8

Sponsor: Sponsor28-can (8 matches)

Ticket Summary Status Owner Priority Points
#28930 consider reordering PT/proxy phases needs_revision ahf Medium 3
#29112 PTs should pass user count events back to Tor new Medium 1
#29267 CI for pluggable transports new Medium 13
#29690 Add a comment to chutney's, reminding us to copy changes to tor's assigned Medium 1
#30884 Test pluggable transports in chutney's CI new Medium 1
#30885 Add pluggable transports to Tor's chutney CI job new Medium 1
#30886 Add pluggable transport support to chutney's tools/ new Medium 1
#31009 Tor lets transports advertise private IP addresses in descriptor assigned ahf Medium 0.5

Sponsor: Sponsor28-must (5 matches)

Ticket Summary Status Owner Priority Points
#5304 Obfsproxy should respect OutboundBindAddress in torrc needs_revision ahf Medium 1
#29111 Optional heartbeat message from PT's new Low
#29128 Place complete obfs4 bridge line in accessible location new Medium
#29245 Tor 0.4 eventually hits "Delaying directory fetches: No running bridges" after some period of inactivity with bridges new Medium
#31103 Support ORPort picking a random port that persists across restarts new Medium 1

Sponsor: Sponsor30-must (1 match)

Ticket Summary Status Owner Priority Points
#30477 Tor should self-test reachability of TCP listeners exposed by PT's new Medium

Sponsor: Sponsor31-can (3 matches)

Ticket Summary Status Owner Priority Points
#29211 Distribute config.c functionality across more modules assigned nickm Medium 23
#31851 Allow Tor to be compiled without support for relay mode assigned Medium 5
#32139 Disable all dirauth options when those modules are disabled accepted nickm Medium 2

Sponsor: None (20 matches)

Ticket Summary Status Owner Priority Points
#23744 sched: Notification events have different meaning for each scheduler assigned High
#24554 sched: Have per-scheduler type data in a channel_t assigned Very High
#24839 Add a torrc option and descriptor line to opt-in as a FallbackDir assigned Medium 3
#29215 Document target, modular tor architecture accepted catalyst Medium 5
#29226 Automate application of C formatting to code new Medium 5
#29427 kist: Poor performance with a small amount of sockets needs_revision dgoulet Medium 0.1
#29494 Optimize interaction between circuitmux and circuitpadding needs_revision mikeperry High 5
#29698 Edge case that causes improper circuit prioritization for one scheduling run needs_revision dgoulet Medium 0.2
#30901 Add control port trace logging to tor assigned teor Medium 1
#32208 write description of control subsystem architecture accepted catalyst Medium
#32697 Require supported relay protocol versions based on new Medium 0.5
#32698 Require client protocol versions based on new Medium 0.5
#32773 Remove Jenkins tor master jobs which don't have OpenSSL 1.1.1 new Medium 1
#32775 Remove 0.2.9 from chutney's CI new Medium 0.1
#32776 Remove 0.2.9 from the jenkins builders new Medium 0.1
#32783 Investigate clusterfuzz build failures assigned nickm High 3
#32784 Find and remove upward dependencies in our codebase new Medium
#32943 factor out supporting shell scripts from CI configs new Medium 4
#32944 where are we still excessively strict about clock skew? pluggable transports? new Medium 4
#33014 Refactor hs configuration parsing assigned nickm Medium 1

Other Projects

Last modified 17 hours ago Last modified on Jan 22, 2020, 12:02:42 AM

Attachments (1)