Changes between Version 1 and Version 2 of org/teams/NetworkTeam/NetworkTeamProducts


Ignore:
Timestamp:
Dec 4, 2015, 5:21:25 AM (3 years ago)
Author:
isabela
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • org/teams/NetworkTeam/NetworkTeamProducts

    v1 v2  
    1515
    1616|| '''Product''' || '''Who is/are the lead maintainer(s)?''' || ''' Scope''' || '''Status''' || '''Future''' ||
    17 || '''Tor''' || nickm || Tor is the network daemon that makes Tor clients, relays, directories, and authorities run. || Under active development since 2002 or so.  Tor 0.2.7 will come out this fall. ||       In the near-term, there are many proposals in the pipeline that would enhance the Tor protocol.       We're working on modularizing Tor's design to make it easier to test ,  easier to sandbox components, and easier to write pieces in simpler  languages.      Ongoing work to improve crypto throughout the Tor protocol.      Ongoing work to improve path selection throughout the Tor protocol      Work to improve test coverage throughout Tor daemon.       Resist DoS better      Write major components in safer languages      Remove the leading 0 from the version number      Drop TLS?      Better resist traffic-analysis attacks.      One day, we will merge the Consensus Diffs SOP code.      Improve performance throughout code ||
    18 || '''Tor Specifications/Proposals''' || nickm (with help from atagar, dgoulet and isis.) ||       The specifications describe what a program must do to interoperate correctly and safely with Tor clients and relays.      The proposals each describe a proposed change to the specifications. ||        The specifications are mostly accurate, but a bit disjointed: they  haven't received any comprehensive attention for flow since we first  wrote them, mostly.       The older proposals are getting stale; Nick used to write a  periodic  "what's new, what are the statuses" document, but that hasn't happened  in a while.       We don't have a real change control process on proposals; perhaps we should. ||        See if we can't make the specs more accurate and readable       Switch our protocol descriptions to something a bit more rigorous than the plain-english descriptions we use today?       Consider a better change-tracking process.       See if we can't reinstate regular review of the proposals' status.       Try to move more proposals to accepted/rejected.              Integrate proposals more quickly ||
    19 || '''Trunnel[[BR]]'''  https://gitweb.torproject.org/trunnel.git/ || nickm ||          Trunnel is a set of python scripts that generate human-readable binary-format parsing/unparsing code. ||           In use for Tor today. Recommended for use with all new binary formats Tor needs to parse/generate.  ||           No current improvements planned.          Correctness proof might be nice          Might be nice to make it parse TLS.          Encourage other protocols to use          Rigorously document transformations          Support more languages (WTB C++11 support)          Fuzzing as a correctness / security check ||
    20 || '''Tor design documentation:[[BR]]'''  https://gitweb.torproject.org/tor-design-2012.git/ ||      sjmurdoch, nickm, arma, syverson? ||       Producing an updated version of the Tor design document, providing an  academic-paper-style thing to describe the current Tor network and how  it works. Provides more design rationale and less interoperability  details than the specs do. ||      We have a work-in-progress from 2012. ||      Nick isn't aware of current plans to finish this or keep it  up-to-date... but if we did, it would be a solid introduction to Tor's  modern structure, and would help academics who haven't been following us  for the last 10 years get started in the field. ||
    21 || '''Tor implementation documentation:''' || nickm ||        We'd like to cover as much as possible about Tor's current internals and some future plans ||         nickm is writing this and isn't sure where to put it. ||        First revision should be finished by end-of-October.        Future revisions as patches arrive       We need a maintainance plan for this document, to keep it up-to-date, and make it cover more. ||
    22 || '''Tor directory authorities''' || Roger? ||         There are about 9 directory authorities, who need to coordinate running  a set of scripts, advertising parameters, banning bad relays, upgrading  their authorities, etc etc ||         Nobody finds the current system easy; scripts are too numerous and hard  to run; adding parameters and bad relays is tricky.        We haven't had a complete outage in years and years.        There's often one or two authorities acting funny (as in needs-a-kick, not probably-evil)        It seems to work, mostly! ||        We need to get the entire suite of things that we'd like directory authorities to run as tested and maintained as Tor.       We need to get the entire suite of things we'd like authorities to run easily installed and launched.       We need to actively work to get directory authority operators happier!        On the politics side, the !BadRelay/BadExit process is Entirely Lacking In Transparency from the user base's perspective. ||
    23 || '''Chutney''' ||      teor / nickm || * Tor test network configuration, launch, connectivity and CPU-limited bandwidth testing. || * Creating a user guide.[[BR]][[BR]] * https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide[[BR]][[BR]] * Incrementally being improved until it's easier for people to pick up and modify.[[BR]][[BR]] * https://trac.torproject.org/projects/tor/ticket/16949[[BR]][[BR]] * Tested Tor features:[[BR]][[BR]] * Authorities,  Relays (Exit (IPv4/IPv6), Non-Exit), Bridges (!BridgeAuth, Bridge Client  (IPv4/IPv6), Bridge Relay (IPv4/IPv6)), Hidden Services[[BR]][[BR]] * Networks with a mix of Old/New Tor Versions[[BR]][[BR]] * Making  multiple connections ($CHUTNEY_CONNECTIONS/$CHUTNEY_HS_MULTI_CLIENT),   transporting lots of traffic at once ($CHUTNEY_DATA_BYTES),[[BR]][[BR]] * Tor's make test-network-all runs a series of chutney tests and reports PASS/FAIL/SKIP for each (like make check) [[BR]][[BR]] * Untested Tor features (currently):[[BR]][[BR]] * Bandwidth Weights, Bandwidth Authorities, Pluggable transports, exit policies, failing clients, IPv6 connections (we set up IPv6 bridge clients/bridges/exits, but then use IPv4 addresses)[[BR]][[BR]] * Not yet implemented testing features:[[BR]][[BR]] * Refactor networks and maybe torrc_templates to make chutney more configurable (chutney 2?) || * Transformed into chutney 2 without losing everything we've learnt in the process. ||
    24 || '''Hidden Services''' || *   asn, dgoulet , nickm ||       anonymous publishing.of data ||       working.      very active and growing user base and community.      many known security issues with the current protocol.      improvements from SoP, including !OnionBalance (trac !#14846) and OnioNS (?) ||       lots of proposals have been made to improve security (prop224, prop250, prop247)      all require significant engineering effort, currently unfunded.      few hidden service developers, and lots of distractions. (All the funded stuff is adding more stuff, and not fixing the security of existing stuff)      how do we avoid duplication between hidden services, single onion services, and tor2web?      DoS resilience still needs work.      ADD_ONION ships in 0.2.7.x which should encourage use.  Still needs work. (!#15588) ||
    25 || '''Single Onion Services (client-location-hidden, server-location-known services)''' ||          dunno         special,  teor, hidden services team (?) ||       client-location-hidden access to data ||       in proposals/ideas (https://gitweb.torproject.org/user/special/torspec.git/log/?h=xxx-direct-onion - trac !#2555)      multiple experimental prototypes, not based on proposal (Facebook, teor, NRL?)      one known prototype user (Facebook), not based on proposal (implemented pre-proposal)      strong desire for performant, authenticated, path-secure (secure-routing?) access to onion sites, with client anonymity (Desire by who? NRL? Spacebook????)       some known security issues with current hidden services also affect  single onion services, but server-side discovery attacks are irrelevant ||       interactions with hidden services proposals (prop224, prop250, prop247)      compatibility with current / future hidden services - open questions on security, engineering, and deployment cost      research / implementation by NRL      consideration of load balancing, and geographically-(topologically)-aware load balancing for extra performance      few hs / onion service developers, and lots of distractions      how do we avoid duplication between hidden services, single onion services, and tor2web? ||
    26 || '''tor2web (client-location-known, server-location-hidden services)''' || * virgil? ||       client access to server-location-hidden data ||       working.      active user base and community. (????)       some known security issues with current hidden services also affect  tor2web clients, but client-side discovery attacks are irrelevant ||       proposal to improve performance (prop233)      request to build a tor2web mode-enabled tor binary (trac !#15199)      request to always have tor2web mode compiled-in, and to activate it via a long command-line option - https://trac.torproject.org/projects/tor/ticket/2555#comment:13        pro: makes deployment easier, con: makes accidental loss of privacy easier      few hs / onion service developers, and lots of distractions      how do we avoid duplication between hidden services, single onion services, and tor2web?      prop227 socks extensions (extended error information was requested by this stuff) ||
    27 || '''Pluggable Transports''' || Depends on the PT.  Out of the ones maintained by the Tor Project, a  combination of asn/dcf/Yawning. Other things maintained by blanu, kpd  and mjuarez also exist.  But from the Tor perspective, mostly Yawning  for now. ||    Providing client access to the Tor network despite censorship, and  (sometimes) to serve as a testbed for experimental network protocol  things. ||    Depends on the PT. Some deployed and widely used.  Some deployed and  rarely used. Some experimental and undeployed. Some waiting large scale  deployment. ||    PT The Spec:              Ongoing efforts to rewrite the existing spec so that other people feel like using it (!#10629/!#16754).       New and Improved spec that fixes everything that's wrong with the current spec (!#16755).          PT The Protocols:              Depends on the PT....              Deprecate: obfs2, flashproxy-nonWebRTC (?), fte (?)              Maintain obfs3, !ScrambleSuit, meek, obfs4              Deploy: Dust2 (???)              Write: flashproxy-WebRTC (???), (YA: I have some extra ideas here, not that I have time these days)          PT The Implementation:              Fix the logging situation (!#9957, !#11542)       Fix the termination process (!#15593)       Implement prop227       Implement the New And Improved PT spec          PT The Politics:          Figure out the deployment process for new PTs (!#16756)        Come up with a sustainable long term maintenance strategy for PT  codebases that don't originate from Tor Developers (No, "Yawning will  maintain them all" is not an option here)       Figure out how to involve other projects as users of the PT interface (???)                 (isis and mike have been working on getting the bitcoin devs to accept a BIP for                   PT/obfsproxy integration into bitcoin nodes, but it doesn't have a number yet)       Get more people to write PTs       Write stuff that isn't broken, because absolutely everything deployed has feasible attacks. - List of PTs under active development and their maintainers:     meek: David Fifield     flashproxy: David Fifield (XXX do people still use flashproxy?)     pyptlib: ???     obfsproxy: asn?     obfs4proxy: Yawning     goptlib: ???     Other people: fteproxy (Not our problem????) (agreed) * dust*: blanu  (I have no idea what I want to do with this yet) (also agreed)     ||
    28 || '''Bridges''' || (isis doesn't mind being a caretaker of bridges), nickm ||       Special entry guards for censorship circumvention ||        They work. Code is clunky. Heavily depends on TBB, PTs and BridgeDB. ||  https://trac.torproject.org/projects/tor/raw-attachment/ticket/7144/the-bridges-they-will-be-so-awesome.gif :)  Code  should be refactored into separate module(s), imo. The Bridge  reachability and self-reachability code needs redesign and  reimplementation due to enumeration attacks. (!#7144 ish) Bridges should be able to work without ORPort. (!#7349) ||
    29 || '''BridgeDB''' || Isis || Distribute Bridges and PTs to users ||  Doing  pretty peachy. Could use more stable funding to make improvements go  faster. After said improvements, BridgeDB very likely will need only  nominal funding/attention/maintenance. ||  The things described in [https://people.torproject.org/%7Eisis/otf-etfp-sow.pdf https://people.torproject.org/~isis/otf-etfp-sow.pdf] along with !#7250 ||
    30 || '''Shadow''' || Rob ||      discrete-event network simulator     testing tor in a network environment || * working and maintained.[[BR]][[BR]] * currently improving towards supporting 0.2.7 + || * planning to add native instrumentation to tor[[BR]][[BR]] * one single developer and maintainer, Rob. ||
    31 || '''Nyx''' || Damian ||     Provide a command line interface to monitor a local Tor relay or bridge ||     Under use by many Tor relay operators!  Quoting Damian: "Nyx is my main focus right now and getting closer to its firstrelease since 2012. Plan is to finish Nyx then focus on Erebus,Cristobal's SoP project to make a relay web dashboard. Presentlythe options we give users in terms of UIs suck. Nyx and Erebus willbe stepping in to fill that gap." ||     Improve user interface. Add features. Make web interface (SoP project).    (I'm not Damian!) ||
    32 || '''Stem''' || Damian ||  Provide easy-to-use parsers for various document formats and protocols within Tor.    ||   Quoting Damian: "Stem is feature complete. Its goal was to be a pythonimplementation of the control and directory specifications, and itdoes that. As the backbone of Nyx and Erebus it's naturallyimproving with their development, but not much dedicated focus onStem itself at present." || ||
    33 || '''txtorcon''' ||         meejah (dawuud is helping out as well i think) ||      Asynchronous Tor controller library written in Twisted Python. Used by OONI and a few other projects. || The code is like the most perfect Twisted Python ever written. And 100% test coverage. It's doing awesome. ||      Continued bugfixes and reasonable features. Immediate future:         - "tahoe/LAFS" will be using txtorcon -- anything they need         - last nit or two for Debian reproducible builds         - a higher-level circuit-builder/stream attacher (see [https://github.com/meejah/txtorcon/issues/125%29 https://github.com/meejah/txtorcon/issues/125)]         - "play more nicely with Stem" (see "optional-stem" branch, should be merged soon)         - any features/bugfixes desired by other Tor projects/users[[BR]]    further future:        - possibly port to !``txaio!`` so it supports asyncio as well as Twisted ||
     17|| '''Tor''' || nickm || Tor is the network daemon that makes Tor clients, relays, directories, and authorities run. || Under active development since 2002 or so.  Tor 0.2.7 will come out this fall. || * In the near-term, there are many proposals in the pipeline that would enhance the Tor protocol.[[BR]][[BR]] * We're working on modularizing Tor's design to make it easier to test ,  easier to sandbox components, and easier to write pieces in simpler  languages.[[BR]][[BR]] * Ongoing work to improve crypto throughout the Tor protocol.[[BR]][[BR]] * Ongoing work to improve path selection throughout the Tor protocol[[BR]][[BR]] * Work to improve test coverage throughout Tor daemon.[[BR]][[BR]] * Resist DoS better[[BR]][[BR]] * Write major components in safer languages[[BR]][[BR]] * Remove the leading 0 from the version number[[BR]][[BR]] * Drop TLS?[[BR]][[BR]] * Better resist traffic-analysis attacks.[[BR]][[BR]] * One day, we will merge the Consensus Diffs SOP code.[[BR]][[BR]] * Improve performance throughout code ||
     18|| '''Tor Specifications/Proposals''' || nickm (with help from atagar, dgoulet and isis.) || * The specifications describe what a program must do to interoperate correctly and safely with Tor clients and relays.[[BR]][[BR]] * The proposals each describe a proposed change to the specifications. || The specifications are mostly accurate, but a bit disjointed:[[BR]][[BR]] * they  haven't received any comprehensive attention for flow since we first  wrote them, mostly.[[BR]][[BR]] * The older proposals are getting stale; Nick used to write a  periodic  "what's new, what are the statuses" document, but that hasn't happened  in a while.[[BR]][[BR]] *  We don't have a real change control process on proposals; perhaps we should. || * See if we can't make the specs more accurate and readable[[BR]][[BR]] * Switch our protocol descriptions to something a bit more rigorous than the plain-english descriptions we use today?[[BR]][[BR]] * Consider a better change-tracking process.[[BR]][[BR]] * See if we can't reinstate regular review of the proposals' status.[[BR]][[BR]] * Try to move more proposals to accepted/rejected.[[BR]][[BR]] * Integrate proposals more quickly ||
     19|| '''Trunnel[[BR]]'''  https://gitweb.torproject.org/trunnel.git/ || nickm || * Trunnel is a set of python scripts that generate human-readable binary-format parsing/unparsing code. ||  * In use for Tor today. Recommended for use with all new binary formats Tor needs to parse/generate.  || * No current improvements planned.[[BR]][[BR]] * Correctness proof might be nice[[BR]][[BR]] * Might be nice to make it parse TLS.[[BR]][[BR]] * Encourage other protocols to use[[BR]][[BR]] * Rigorously document transformations[[BR]][[BR]] * Support more languages (WTB C++11 support)[[BR]][[BR]] * Fuzzing as a correctness / security check ||
     20|| '''Tor design documentation:[[BR]]'''  https://gitweb.torproject.org/tor-design-2012.git/ || sjmurdoch, nickm, arma, syverson? || * Producing an updated version of the Tor design document, providing an  academic-paper-style thing to describe the current Tor network and how  it works. Provides more design rationale and less interoperability  details than the specs do. || * We have a work-in-progress from 2012. || * Nick isn't aware of current plans to finish this or keep it  up-to-date... but if we did, it would be a solid introduction to Tor's  modern structure, and would help academics who haven't been following us  for the last 10 years get started in the field. ||
     21|| '''Tor implementation documentation:''' || nickm || * We'd like to cover as much as possible about Tor's current internals and some future plans || * nickm is writing this and isn't sure where to put it. || * First revision should be finished by end-of-October.[[BR]][[BR]] * Future revisions as patches arrive[[BR]][[BR]] * We need a maintainance plan for this document, to keep it up-to-date, and make it cover more. ||
     22|| '''Tor directory authorities''' || Roger? || * There are about 9 directory authorities, who need to coordinate running  a set of scripts, advertising parameters, banning bad relays, upgrading  their authorities, etc etc || * Nobody finds the current system easy; scripts are too numerous and hard  to run; adding parameters and bad relays is tricky.[[BR]][[BR]] * We haven't had a complete outage in years and years.[[BR]][[BR]] * There's often one or two authorities acting funny (as in needs-a-kick, not probably-evil)[[BR]][[BR]] * It seems to work, mostly!|| * We need to get the entire suite of things that we'd like directory authorities to run as tested and maintained as Tor.[[BR]][[BR]] * We need to get the entire suite of things we'd like authorities to run easily installed and launched.[[BR]][[BR]] * We need to actively work to get directory authority operators happier![[BR]][[BR]] * On the politics side, the !BadRelay/BadExit process is Entirely Lacking In Transparency from the user base's perspective. ||
     23|| '''Chutney''' || teor / nickm || * Tor test network configuration, launch, connectivity and CPU-limited bandwidth testing. || * Creating a user guide.[[BR]][[BR]] * https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide[[BR]][[BR]] * Incrementally being improved until it's easier for people to pick up and modify.[[BR]][[BR]] * https://trac.torproject.org/projects/tor/ticket/16949[[BR]][[BR]] * Tested Tor features:[[BR]][[BR]] * Authorities,  Relays (Exit (IPv4/IPv6), Non-Exit), Bridges (!BridgeAuth, Bridge Client  (IPv4/IPv6), Bridge Relay (IPv4/IPv6)), Hidden Services[[BR]][[BR]] * Networks with a mix of Old/New Tor Versions[[BR]][[BR]] * Making  multiple connections ($CHUTNEY_CONNECTIONS/$CHUTNEY_HS_MULTI_CLIENT),   transporting lots of traffic at once ($CHUTNEY_DATA_BYTES),[[BR]][[BR]] * Tor's make test-network-all runs a series of chutney tests and reports PASS/FAIL/SKIP for each (like make check) [[BR]][[BR]] * Untested Tor features (currently):[[BR]][[BR]] * Bandwidth Weights, Bandwidth Authorities, Pluggable transports, exit policies, failing clients, IPv6 connections (we set up IPv6 bridge clients/bridges/exits, but then use IPv4 addresses)[[BR]][[BR]] * Not yet implemented testing features:[[BR]][[BR]] * Refactor networks and maybe torrc_templates to make chutney more configurable (chutney 2?) || * Transformed into chutney 2 without losing everything we've learnt in the process. ||
     24|| '''Hidden Services''' || *   asn, dgoulet , nickm || anonymous publishing.of data || * working.[[BR]][[BR]] * very active and growing user base and community.[[BR]][[BR]] * many known security issues with the current protocol.[[BR]][[BR]] * improvements from SoP, including !OnionBalance (trac !#14846) and OnioNS (?) || * lots of proposals have been made to improve security (prop224, prop250, prop247)[[BR]][[BR]] * all require significant engineering effort, currently unfunded.[[BR]][[BR]] * few hidden service developers, and lots of distractions. (All the funded stuff is adding more stuff, and not fixing the security of existing stuff)[[BR]][[BR]] * how do we avoid duplication between hidden services, single onion services, and tor2web?[[BR]][[BR]] * DoS resilience still needs work.[[BR]][[BR]] * ADD_ONION ships in 0.2.7.x which should encourage use.[[BR]][[BR]] * Still needs work. (!#15588) ||
     25|| '''Single Onion Services (client-location-hidden, server-location-known services)''' || * dunno, special, teor, hidden services team (?) || * client-location-hidden access to data || * in proposals/ideas (https://gitweb.torproject.org/user/special/torspec.git/log/?h=xxx-direct-onion - trac !#2555)[[BR]][[BR]] * multiple experimental prototypes, not based on proposal (Facebook, teor, NRL?)[[BR]][[BR]] * one known prototype user (Facebook), not based on proposal (implemented pre-proposal)[[BR]][[BR]] * strong desire for performant, authenticated, path-secure (secure-routing?) access to onion sites, with client anonymity (Desire by who? NRL? Spacebook????)[[BR]][[BR]] * some known security issues with current hidden services also affect  single onion services, but server-side discovery attacks are irrelevant || * interactions with hidden services proposals (prop224, prop250, prop247)[[BR]][[BR]] * compatibility with current / future hidden services - open questions on security, engineering, and deployment cost[[BR]][[BR]] * research / implementation by NRL[[BR]][[BR]] * consideration of load balancing, and geographically-(topologically)-aware load balancing for extra performance[[BR]][[BR]] * few hs / onion service developers, and lots of distractions[[BR]][[BR]] * how do we avoid duplication between hidden services, single onion services, and tor2web? ||
     26|| '''tor2web (client-location-known, server-location-hidden services)''' || * virgil? || * client access to server-location-hidden data || * working.[[BR]][[BR]] * active user base and community. (????)[[BR]][[BR]] * some known security issues with current hidden services also affect  tor2web clients, but client-side discovery attacks are irrelevant || * proposal to improve performance (prop233)[[BR]][[BR]] * request to build a tor2web mode-enabled tor binary (trac !#15199)[[BR]][[BR]] * request to always have tor2web mode compiled-in, and to activate it via a long command-line option - https://trac.torproject.org/projects/tor/ticket/2555#comment:13[[BR]][[BR]] * pro: makes deployment easier, con: makes accidental loss of privacy easier[[BR]][[BR]] * few hs / onion service developers, and lots of distractions[[BR]][[BR]] * how do we avoid duplication between hidden services, single onion services, and tor2web?[[BR]][[BR]] * prop227 socks extensions (extended error information was requested by this stuff) ||
     27|| '''Pluggable Transports''' || * Depends on the PT.  Out of the ones maintained by the Tor Project, a  combination of asn/dcf/Yawning. Other things maintained by blanu, kpd  and mjuarez also exist.  But from the Tor perspective, mostly Yawning  for now. || Providing client access to the Tor network despite censorship, and  (sometimes) to serve as a testbed for experimental network protocol  things. || Depends on the PT. Some deployed and widely used.  Some deployed and  rarely used. Some experimental and undeployed. Some waiting large scale  deployment. ||  PT The Spec:              Ongoing efforts to rewrite the existing spec so that other people feel like using it (!#10629/!#16754).       New and Improved spec that fixes everything that's wrong with the current spec (!#16755).          PT The Protocols:              Depends on the PT....              Deprecate: obfs2, flashproxy-nonWebRTC (?), fte (?)              Maintain obfs3, !ScrambleSuit, meek, obfs4              Deploy: Dust2 (???)              Write: flashproxy-WebRTC (???), (YA: I have some extra ideas here, not that I have time these days)          PT The Implementation:              Fix the logging situation (!#9957, !#11542)       Fix the termination process (!#15593)       Implement prop227       Implement the New And Improved PT spec          PT The Politics:          Figure out the deployment process for new PTs (!#16756)        Come up with a sustainable long term maintenance strategy for PT  codebases that don't originate from Tor Developers (No, "Yawning will  maintain them all" is not an option here)       Figure out how to involve other projects as users of the PT interface (???)                 (isis and mike have been working on getting the bitcoin devs to accept a BIP for                   PT/obfsproxy integration into bitcoin nodes, but it doesn't have a number yet)       Get more people to write PTs       Write stuff that isn't broken, because absolutely everything deployed has feasible attacks. - List of PTs under active development and their maintainers:     meek: David Fifield     flashproxy: David Fifield (XXX do people still use flashproxy?)     pyptlib: ???     obfsproxy: asn?     obfs4proxy: Yawning     goptlib: ???     Other people: fteproxy (Not our problem????) (agreed) * dust*: blanu  (I have no idea what I want to do with this yet) (also agreed) ||
     28|| '''Bridges''' || (isis doesn't mind being a caretaker of bridges), nickm || Special entry guards for censorship circumvention || They work. Code is clunky. Heavily depends on TBB, PTs and BridgeDB. || https://trac.torproject.org/projects/tor/raw-attachment/ticket/7144/the-bridges-they-will-be-so-awesome.gif :)  Code  should be refactored into separate module(s), imo. The Bridge  reachability and self-reachability code needs redesign and  reimplementation due to enumeration attacks. (!#7144 ish) Bridges should be able to work without ORPort. (!#7349) ||
     29|| '''BridgeDB''' || Isis || Distribute Bridges and PTs to users || Doing  pretty peachy. Could use more stable funding to make improvements go  faster. After said improvements, BridgeDB very likely will need only  nominal funding/attention/maintenance. || The things described in [https://people.torproject.org/%7Eisis/otf-etfp-sow.pdf https://people.torproject.org/~isis/otf-etfp-sow.pdf] along with !#7250 ||
     30|| '''Shadow''' || Rob || discrete-event network simulator    testing tor in a network environment || * working and maintained.[[BR]][[BR]] * currently improving towards supporting 0.2.7 + || * planning to add native instrumentation to tor[[BR]][[BR]] * one single developer and maintainer, Rob. ||
     31|| '''Nyx''' || Damian || Provide a command line interface to monitor a local Tor relay or bridge || Under use by many Tor relay operators!  Quoting Damian: "Nyx is my main focus right now and getting closer to its firstrelease since 2012. Plan is to finish Nyx then focus on Erebus,Cristobal's SoP project to make a relay web dashboard. Presentlythe options we give users in terms of UIs suck. Nyx and Erebus willbe stepping in to fill that gap." || Improve user interface. Add features. Make web interface (SoP project).    (I'm not Damian!) ||
     32|| '''Stem''' || Damian ||  Provide easy-to-use parsers for various document formats and protocols within Tor.  || Quoting Damian: "Stem is feature complete. Its goal was to be a pythonimplementation of the control and directory specifications, and itdoes that. As the backbone of Nyx and Erebus it's naturallyimproving with their development, but not much dedicated focus onStem itself at present." || ||
     33|| '''txtorcon''' || meejah (dawuud is helping out as well i think) || Asynchronous Tor controller library written in Twisted Python. Used by OONI and a few other projects. || The code is like the most perfect Twisted Python ever written. And 100% test coverage. It's doing awesome. || Continued bugfixes and reasonable features. Immediate future:         - "tahoe/LAFS" will be using txtorcon -- anything they need         - last nit or two for Debian reproducible builds         - a higher-level circuit-builder/stream attacher (see [https://github.com/meejah/txtorcon/issues/125%29 https://github.com/meejah/txtorcon/issues/125)]         - "play more nicely with Stem" (see "optional-stem" branch, should be merged soon)         - any features/bugfixes desired by other Tor projects/users[[BR]]    further future:        - possibly port to !``txaio!`` so it supports asyncio as well as Twisted ||
    3434|| '''carml''' || meejah || * command-line thing that uses txtorcon to do fun things with tor.[[BR]][[BR]] * plays nicely with grep etc.[[BR]][[BR]] * some things you can do: run tor-controller commands, monitor circuits/streams, create/delete circuits,[[BR]][[BR]] * download TBB, pastebin/copybin tools, continuously updated xplanet viz. of circuits, ... || * hasn't been tested extensively. || * useful for prototyping and experimenting, will add things as I need/want them. ||
    35 || '''Torsocks''' || * dgoulet || * Library that allows a user to run application without Tor support to go over tor. || *  Maintained. Very little feature development. ||      (YA) !#16765 * More features should be added.[[BR]][[BR]] * Crazy idea: Windows support.[[BR]][[BR]] * IPv6 support, please pretty please? ||
    36 || '''onionbalance''' ||       donncha, (asn?) ||     Assists in load balancing busy hidden services.    Improve availability by serving hidden service from multiple boxes. ||      Onionbalance alpha was released and was tested by a few volunteers. Seems to work, needs more testing and advertisement.     There is a more advanced version in the works, that will be developed over the next months (not part of SoP) ||      Onionbalance as it is, is incompatible with prop246. If we decide to  proceed with prop246, we will need to change onionblanace accordingly. ||
    37 || '''bandwidth authority script''' || aagbsn[[BR]]    meejah is willing to help out here and there, but cycles are (somewhat) scarce ||     measure bandwidth of relays to include better consensus weights in network status consensus ||     about to be rescued from bit rot ||  Need to incorporate BW scanning in the relatively short run and peer flow in the long run. Bridge bandwidth measurements ||
     35|| '''Torsocks''' || * dgoulet || * Library that allows a user to run application without Tor support to go over tor. || *  Maintained. Very little feature development. || (YA) !#16765 * More features should be added.[[BR]][[BR]] * Crazy idea: Windows support.[[BR]][[BR]] * IPv6 support, please pretty please? ||
     36|| '''onionbalance''' || donncha, (asn?) || Assists in load balancing busy hidden services.    Improve availability by serving hidden service from multiple boxes. || Onionbalance alpha was released and was tested by a few volunteers. Seems to work, needs more testing and advertisement.     There is a more advanced version in the works, that will be developed over the next months (not part of SoP) || Onionbalance as it is, is incompatible with prop246. If we decide to  proceed with prop246, we will need to change onionblanace accordingly. ||
     37|| '''bandwidth authority script''' || aagbsn[[BR]]    meejah is willing to help out here and there, but cycles are (somewhat) scarce || measure bandwidth of relays to include better consensus weights in network status consensus || about to be rescued from bit rot || Need to incorporate BW scanning in the relatively short run and peer flow in the long run. Bridge bandwidth measurements ||