Meta for non-specific project tickets, projects management and general information in the wiki.

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 network simulators, the scripts that supports directory authorities, onion services, etc. Basically, everything that sends and receives bytes from the network. It used to maintain the pluggable transports and the bridge distribution but now we have the anti-censorship team doing it.

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.)

Team Meetings UTC CEST EDT PDT
Primary team meeting
(in #tor-meeting)
Monday 17:00 Monday 19:00 Monday 13:00 Monday 10:00
Monthly retrospective
(in #tor-meeting)
Tuesday 20:00 Tuesday 22:00 Tuesday 16:00 Tuesday 13: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.

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. Or just stop by the #tor-dev IRC channel and see who is around!

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

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

Have a look at the First Contribution label on gitlab; it has things that we thought, at some point, would be a good place to begin.

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 GettingStarted.md 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 WritingTests.md 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: HelpfulTools.md can tell you how to use them with Tor.
  • If it's your job to put out Tor releases, see ReleasingTor.md 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 HowToReview.md.


We use doxygen to generate documentation in html out of our comments on the code. We keep an up-to-date version of the generated documentation online at https://src-ref.docs.torproject.org.

This documentation should cover the overall code structure, data structures, and individual functions. It's a work in progress, but we hope it'll be useful to you.

More on Network Team

🛠 These links may be outdated.
—nickm, 14 August 2020.

Task Tracking

Older Releases

Tor Meetings


Processes and Policies


Provisional policies:

  • (none right now)

Draft policies:


Security Releases

Plans for 2021

  • Making the Tor network faster & more reliable for users in Internet-repressive places
    • Main large things:
      • Proposal 325 (packed relay cells) [possibly join with prop319]
      • Proposal 324 (congestion control)
      • Proposal 329 (conflux)
      • Reach item: Re-do floodflow experiment; provide relays way to specify shared machine/link
    • Smaller things:
      • Proposal 328 (Relay overload reporting)
      • Proposal 291 (Two guards - ensuring it works; it seems to in CBT experiments)
    • Long tail of bugfixes/likely issues:
      • EWMA/KIST
      • OOMkiller issues wrt conflux and congestion control
      • Shadow vs live network discrepancies
      • Refactoring ancient pieces of circuit timeouts? (seems not needed)
  • Arti
    • what do we need to have it ready for replacement of C code? Is that possible?
      • more involvement. maybe funding.
      • define scope for MVP
    • what could be a reasonable timeline?
    • by the end of the year have a client (milestones B and C completed)
      • MILESTONE B: Secure minimal client
        • Guard nodes <--- first thing to work on
        • Correct path selection <-- important but current restrictions have issues
        • Timeouts
          • Circuit timeout logic
          • Connection timeout logic.
          • What other kinds of timeouts?
        • Connection padding <-- not necessary
        • Circuit padding (with padding machines)
        • Build preemptive circuits <-- very important
        • Change behavior depending on network parameters
        • CBT logic?
        • Pathbias logic <-- it can be dropped
        • Figure out where to put a specific async executor and/or TLS implementation in our stack.
      • MILESTONE C: Client feature parity
        • V3 onion services
        • Fairness on circuits/streams?
        • Support for using bridges
        • Pluggable transport support
        • Controller API?
        • Dormant mode?
        • Transparent proxy mode(s)
    • what could be a timeline for deprecating tor C?
  • Technical debt
    • Tooling: CI
    • Transition to arti is the best way to tackle technical debt right now.
  • Preparation for future work:
    • Proposal 319 (fragmented cells) [may be needed for proof-of-work, will be needed for pq or walking onions]
    • Proposal 321 (happy families)
  • Walking onions (if funded)
  • Authority contact decentralization
  • Evaluating potential next-step cryptography (tagging + pq)
  • Prototype of Proposal 327 (PoW over intro)

Update on June 2021

  1. security fixes
  2. tor network performance
  • shadow experiments
  • congestion control
  1. arti
  • margot things for network health team
  • shadow simulations should be possible with arti
  1. CI with follow up with sysadmin teams
  2. HS v2 deprecation
  • Onion Balance for V3: Multi-service support. Possibly to reduce memory consumption to avoid having to run multiple instances.
  1. Shadow v2 will come out in this period.

Active Sponsors and Contracts


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


  1. security fixes for medium/high severity bugs [No sponsor]
  2. Regular releases [no sponsor] - Nick with help from Team
  3. sbws - Alex [Sponsor 61] (support from GeKo )
  4. Supporting S30 and S28 (anticensorship) work - Alex

Other priorities (everybody):

  • community handling:
    • volunteers
    • relay operators
    • answering email lists (tor-dev@, tor-relays@)
    • do support on irc? (#tor-dev, #tor, etc.)
  • fixing bugs for each release
    • release blockers
  • what else does other teams ask us for?
    • liaison with network health team (usually 1-2 hours a week for dgoulet)
  • Fixing bugs for android and iOS for the guardian project [see #33522 and #33837 for ios issues]
  • ongoing tech-debt reduction
  • Fixing windows bugs (ahf / ... others?):
    • [UTF-8/16 names in filepaths makes Tor unable to start: #10416]
    • Issues with mmap on some platform
    • issues with mmap leading to relays spinning on consdiffcache [#24857 #24857]
    • condition variable issue with 100% cpu [#30187 #30187]
    • Windows DLL load order (possibly a Tor Browser packaging bug) reproducible in CI [#33702, #33643]
  • Writing more grant proposals
  • Miscelaneous onion service tasks that require our attention
    • Onionbalance. Standardizing Onion-Location with the IETF. HTTPS-E
    • Ricochet Refresh support
  • Gitlab transition stuff for network-team related projects (ahf / gaba):
    • CI?
    • Code base movements: chutney, tor.git, fallback-scripts.git on Github and git.torproject.org, torsocks, trunnel
    • Code base movements (archive?): torflow, pytorctl, leekspin (+ dependencies), rpm-packaging
    • DirAuth and sbws to network health, TorDNSEL to metrics

Other Projects