Nominate proposals and other activities for 045

On this ticket, we'll be suggesting things we want to work for on the 0.4.5 timeframe. Feature-freeze is planned for 15 November.

When nominating a proposal, please say whether you think we should implement it, or just refine and discuss it.

We'll talk about this on 30 July.

changed due date to July 31, 2020

changed the description

I want to nominate these proposals as things that we could reasonably build between now and November. We can't do all of them, but we could probably do some.

319-wide-everything.md
325-packed-relay-cells.md

Rationale: these are prerequisites for lots of other things we'd like to build in the future.

321-happy-families.md

Rationale: this would make life easier for relay operators.

315-update-dir-required-fields.txt
318-limit-protovers.md

Rationale: these are pretty easy and would simplify our code.

275-md-published-time-is-silly.txt

Rationale: it's mostly implemented, and making the final change here will allow us to make microdescriptor consensus diffs significantly shorter.

285-utf-8.txt

Rationale: this is pretty easy, and will help with any eventual Rust transition. I think it's also (mostly) done already?

I suggest that we revise these proposals and turn them into something implementable:

239-consensus-hash-chaining.txt
267-tor-consensus-transparency.txt

These proposals are ones we need to discuss, iterate on and possibly improve, since they either are, or soon will be, under active development.

316-flashflow.txt
323-walking-onions-full.md
324-rtt-congestion-control.txt

Here are other activities we can do with spare time in 0.4.5 that I want to nominate:

• A design/proposal for a flexible deployment and iteration plan for token-based exit/reputation features.
• Improving our API for applications that want to embed Tor; making designs for future improvement. (In collaboration with apps and guardian people.)
• Continuing our modularization work; making more relay-only code optional.
• Technical debt tickets TBD.
• Revising our specifications for readability, organization, and consistency.
• Adding support for curve25519-dalek.

I have one:

• Configurable cutoffs for fast, stable, and guard flags

Those are currently hard coded and/or #defines. The ability for dirauths to change them via config rather than recompile would be nice.

Is that something that the dirauths are doing today? Recompiling with different thresholds?

Determining good threshold candidates is one of the planned performance experiments that we've been discussing for the past couple years, but it is non-trivial to try different values, due to the need to sync recompilation of custom patches across dirauths.

I also nominate:

• Improvements to work with static openssl
• Revising proposal 245 (removing TAP keys) and implementing its first phases (making TAP keys optional.

By looking at 000-index.txt, I nominate those:

Implement

249  Allow CREATE cells with >505 bytes of handshake data
319  RELAY_FRAGMENT cells
321  Better performance and usability for the MyFamily option (v2)
325  Packed relay cells: saving space on small commands

Discuss

316  FlashFlow: A Secure Speed Test for Tor (Parent Proposal)
323  Specification for Walking Onions
324  RTT-based Congestion Control for Tor

Revise

279  A Name System API for Tor Onion Services

We should make ourselves independent of Github, Travis CI, and AppVeyor:

• This involves cleaning up our CI scripts: Nick already started a script to simplify some of this.
• Get infrastructure up and running on TPO with Gitlab-CI runners with KVM with Windows and macOS.
• Ensure that we have feature paritity between Travis-CI+Appveyor and what we move to with Gitlab CI.

Let's add a coveralls replacement to the plan.

@dgoulet and I talked about having an interface for systems such as Prometheus to collect stats that are useful for Onion Service operators: for example: connection counts, lifetimes, etc.

I'm gonna echo all the suggestions of people here. I particularly like the idea of "wide everything" since that's gonna open up lots of potential for the future.

Personally I'd like to also have an onion service DoS-protection system built in tor soon. Either the PoW one, or the CAPTCHA tokens idea. I noticed that the PoW one is still not merged to torspec (it's waiting yet another round of revisions), and the CAPTCHA token one is still not a full proposal.

changed due date to September 30, 2020

In the spirit of throwing ideas in case we have no sponsor to answer to for a period of time, I would really love to be able to spend time on cell scheduler work like tor#33763 (closed) and all the work done with Rob to remove the KIST grace-period of 10msec between scheduling rounds.

It is non trivial work but we believe would really improve tor's relay performance by removing that waiting period but also avoiding 2 syscalls per socket every loop.

Process idea: Let's copy these items into a pad spreadsheet, then rank them with:

• How hard/how much work they are
• Who might want to do them
• How much value they'd be
• Whether they're about to be funded in the immediate future

This seems to have been handled.

closed