[tor-dev] Your input on the Tor Metrics Roadmap 2017/18

nusenu nusenu-lists at riseup.net
Tue Oct 10 12:26:00 UTC 2017

> we, the Tor Metrics Team, are currently drafting a roadmap for the work
> we'd like to do on in the upcoming 12 months until September 2018.
> If you believe that you're affected by these plans and want your ideas
> to be included in this roadmap, please read our current draft and send
> your feedback either to this list, to the metrics-team@ mailing list, or
> to iwakeh or irl and/or me directly.
> https://people.torproject.org/~karsten/volatile/metrics-team-roadmap-2017-10-06.pdf

Thanks you for shareing your roadmap - appreciated.

Here are some ideas:

1) metrics.tpo is focused on number of relays. I think it should be more
(additionally) about cw fraction /exit/guard prob. and shares

This is especially useful where a relatively low number of relays make
up a relevant CW fraction (i.e. BSD relays, alpha version relays, ...).
Currently the progress in OS diversity is basically invisible on metrics
platform graphs because it is based on relay count.

tor network wide resilience graphs at family / AS / country level

- Is the tor network becoming more or less resilient / more or less
distributed / more or less centralized?
Is the number of _operators_ (Family) and ASes running n-percent
of exit/guard probability going up or down?

These graphs would show us if fewer operators run more (bad) of the tor
network or vice versa (better).

(I know using family data as an aggregation criteria is non-trivial but
a non-perfect solution could work as well - example:

for operators at relay level I consider bwauth vote graphs very
important / useful:

Atlas graphs about the bwauth measurements on relays level.
Depends on onionoo providing the data, which I filed here:

generic aggregate graphs instead of specific family based graphs:

I've been thinking again about the recently added atlas ticket:

Implement family-level pages showing aggregated graphs

and realized that it would be much more powerful to graph whatever the
the user found with an arbitrary search term.
The problem with that is probably scalability as searches might result
in many hundret results.


twitter: @nusenu_

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171010/7a28ddf1/attachment.sig>

More information about the tor-dev mailing list