[tor-relays] Metrics for assessing EFF's Tor relay challenge?

Lukas Erlacher tor at lerlacher.de
Fri Apr 4 19:24:47 UTC 2014


Hello everyone (reply all ftw),

On 04/04/2014 07:13 PM, Karsten Loesing wrote:
> Christian, Lukas, everyone,
>
> I learned today that we should have something working in a week or two.
>  That's why I started hacking on this today and produced some code:
>
> https://github.com/kloesing/challenger
>
> Here are a few things I could use help with:
>
>  - Anybody want to help turning this script into a web app, possibly
> using Flask?  See the first next step in README.md.
I might be able to do that, but currently I don't have enough free time to make a commitment.
>  - Lukas, you announced OnionPy on tor-dev@ the other day.  Want to look
> into the "Add local cache for ..." bullet points under "Next steps"?  Is
> this something OnionPy could support?  Want to write the glue code?
onion-py already supports transparent caching using memcached. I use a (hopefully) unique serialisation of the query as the key (see serializer functions here: https://github.com/duk3luk3/onion-py/blob/master/onion_py/manager.py#L7) and have a bit of spaghetti code to check for available cached data and the 304 response status from onionoo (https://github.com/duk3luk3/onion-py/blob/master/onion_py/manager.py#L97).

I don't really understand what the code does. What is meant by "combining" documents? What exactly are we trying to measure? Once I know that and have thought of a sensible way to integrate it into onion-py I'm confident I can infact write that glue code :)

Cutting off the rest of the quote tree here (is that a polite thing to do on mailing lists? Sorry if not.), I just have two more comments towards Roger's thoughts:

1. Groups of relays taking the challenge together could just form relay families and we could count relay families in aggregate. (I'm already thinking about relay families a lot because gamambel wants me to overhaul the torservers exit-funding scripts to use relay families.)
2. If you want to do something with consensus weight, why not compare against all other new relays based on the first_seen property? ("new" can be adjusted until sufficiently pretty graphs emerge; and we'd need to periodically (every 4 or 12 or 24 hours?) fetch the consensus_weights from onionoo)

Cheers,
Luke

PS: If you'd like me to support different backends for the caching in onion-py, I'm open to integrating anything that has a python 3 library.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140404/91639ac1/attachment.sig>


More information about the tor-relays mailing list