[Removed tor-dev from cc]
On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis desnacked@riseup.net wrote:
Hello,
this is an attempt to collect tasks that should be done for SponsorR. You can find the SponsorR page here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR
Hi! Since I can't make the declared meeting time tomorrow, I thought I should brain-dump now about more ideas that might fit under the categories you list. I do not guarantee that these are the best places for these ideas.
I'm also deliberately writing these *before* I go through the rest of your email, so that I'm hopefully generating new things.
I'm going to focus only on the subset of those categories that Roger/David told me are the most important for the sponsor. These are:
- Safe statistics collection
To make statistics collection safe, I'd argue that we really need something like the design from proposal 224 that de-correlates multiple instances of a single hidden service. That way, aggregate statistics are safer to maintain.
- Tor controller API improvements
People have wanted something in this area for a while, but I don't think i've seen any really solid and comprehensive proposals. I think there are two ways to go at it, and we should do them both at once:
* Get somebody who wants to access hidden services over the controller API to explain what they want to build. Then design an API as needed to support it.
* Look at what somebody might want to do with hidden services via the controller API; then design an API to expose that.
I'm fairly well equipped to design something in the second area -- so are a lot of people. But for the first, I think we could benefit a bit from some conversations with people who'd use such improvements.
- Performance improvements
Tons of stuff from proposal 224 (and a fair bit from proposal 220) fits in this area. Parallelizing hidden service crypto should help some, and there are performance improvements on the ed25519 side that should make it quite a bit more CPU efficient.
But in the area of getting visible performance improvements, I also think we need to be data-directed in terms of instrumenting where the time is actually going in a connection to an HS. We should also run a busy HS and profile it, and do profile-directed optimizations.