[tor-dev] Potential projects for SponsorR (Hidden Services)
nickm at torproject.org
Tue Oct 21 03:02:30 UTC 2014
[Removed tor-dev from cc]
On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis <desnacked at riseup.net> wrote:
> this is an attempt to collect tasks that should be done for
> SponsorR. You can find the SponsorR page here:
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.
More information about the tor-dev