Re: [tor-dev] Potential projects for SponsorR (Hidden Services)

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

[Removed tor-dev from cc]

On Mon, Oct 20, 2014 at 9:37 AM, George Kadianakis <desnacked@xxxxxxxxxx> 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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev