[Removed tor-dev from cc] On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis <[email protected]> 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. -- Nick _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
