George Kadianakis desnacked@riseup.net writes:
The "meeting" was impromptu and IRL because we all happened to be at the same place. There is no next meeting and it's up to us (Tor/network team) to figure out what are the next steps here.
I want to help. Anyone please bug me on IRC for any Python etc help required to make bwauth/scanners better. I don't have enough volunteer cycles right now to "take over" bwscanner entirely though.
This project is not quite there yet, and will require some non-trivial engineering time, but it's probably a much easier task compared to peerflow due to the design being more understood and already coded.
I'm not convinced this part is completely accurate ;) because at TorDev MTL it seems to me the consensus was that nobody actually knows what torflow is doing and so answering the question "is bwscanner doing the same thing" is approximately NP-hard.
I think 2-3 weeks of developer time could be quite fruitful here. I also heard that some bw auth operators are eager to run bwscanner instead of torflow on their setup in January.
Wooo! (I think the best path to answering "does bwscanner do the same thing as torflow" is to Run It And See...) If any of these parties are having problems deploying bwscanner this is probably something I can help with.
Currently my intuition is to work on (b) above, while also preparing the ground for (a) which seems to be The Right Thing.
+1 I think the next step for a) isn't "implement it", but "write a spec for it" instead.
Ideally we would probably apply for some sort of grant on this work so that some actual developer time is allocated. I think this is definitely fundable work since it deeply impacts the *performance* and security of the Tor network [..]
+5