Hello everyone,
This summer I'll be working on a Relay Web Dashboard as part of Tor's Summer of Privacy [1]. The goal of this project is to develop a web application to monitor Tor relays. A good part of the back-end code will be based on what nyx [2] currently does (using stem [3]).
You can take a look at my SOP proposal here [4] to get a better idea of what I'm planning to do. TL;DR : use Javascript to fetch information from a 'Relay API'. This 'Relay API' will use stem to collect data from the relay, keeping in mind that the idea is to follow a 'read-only' approach, in other words: just monitoring (at least for now).
On the first half of SOP I'll be working on making this app based on nyx features. On the second half I'm planning to add new features if necessary, and for that I'd be very interested in hearing your feedback and ideas, specially if you are a relay operator and you think there are features that will help you with the task of running a relay.
I hope this project would be of help to relay operators community by giving them a secure, useful and easy-to-use tool for their relays.
I'll be informing you about my progress with bi-weekly reports to this list. I'm also on IRC by the nickname @clv
Looking forward to hear from you!
Best regards, Cristobal GPG: 2ACA 8DD4 444E 358F B72E 8C3C 7196 690D 9E03 CDFD
[1] https://trac.torproject.org/projects/tor/wiki/doc/gsoc [2] https://gitweb.torproject.org/nyx.git [3] https://stem.torproject.org/ [4] https://leivaburto.github.io/sop-proposal
On 07/07/2015 09:26 PM, Cristobal wrote:
This summer I'll be working on a Relay Web Dashboard as part of Tor's Summer of Privacy [1]. The goal of this project is to develop a web application to monitor Tor relays. A good part of the back-end code will be based on what nyx [2] currently does (using stem [3]).
Cool. Nice to see this project picked up. It can be a great component for a standalone 'plug-and-play' relay.
Arlo did a small prototype a while ago. You should talk to him some time soon to exchange ideas, he may have some. https://github.com/arlolra/bulb
Enjoy your time with Tor! May it be long and prosperous ;-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
is this strictly a one dashboard for one tor daemon or will this also be usable to monitor multiple tor instances without running multiple dashboard instances in parallel? (while leaving the 'how to securely connect to a remote controlport' task to the operator)
August 15 - October 5 Implementation of further statistics that were not included in nyx but are going to be included in Relay Web Dashboard.
Would that include data that is not available via the controlport, like exit/guard probability, (measured bw), cw and cw fraction (available via onionoo) or is that not something that you are planing to include?
thanks
Hi,
On 28/07/15 17:06, nusenu wrote:
is this strictly a one dashboard for one tor daemon or will this also be usable to monitor multiple tor instances without running multiple dashboard instances in parallel?
It's being developed as one tor instance <-> one dashboard instance, although it'd be a nice feature to include what you mention into **future development**.
Would that include data that is not available via the controlport, like exit/guard probability, (measured bw), cw and cw fraction (available via onionoo) or is that not something that you are planing to include?
This is still a matter of discussion. To mention some of the things I'd consider to decide which info to include or not to include...
- Is this doable within SoP time schedule (if not, we could consider it for further developments, like the one you mentioned before). - Is there a reliable way of getting this info? - Is this a priority for relay operators? - etc.
A priori, including onionoo stats sounds doable and useful.
Thanks for reaching out with this! - Cristobal
is this strictly a one dashboard for one tor daemon or will this also be usable to monitor multiple tor instances without running multiple dashboard instances in parallel?
It's being developed as one tor instance <-> one dashboard instance, although it'd be a nice feature to include what you mention into **future development**.
Hi nusenu. This is something I've long wanted to do with Nyx, and definitely something for long term consideration. It's a valid use case, especially for gigabit relay families that run multiple instances to saturate their connection. We did this, for instance, with Amunet. But that said, not a feature for the initial release.
Would that include data that is not available via the controlport, like exit/guard probability, (measured bw), cw and cw fraction (available via onionoo) or is that not something that you are planing to include?
Think I'm gonna need to say 'patches welcome' for these. First step would be to add them to Stem. Anything in Onionoo is easy to bring in (it's chiefly just distilled descriptor information), but I'm not positive about the exit/guard probabilities. Is it a simple ratio? Or do tor clients do something more sophisticated? If it's something simple I'd be happy to take a patch adding it to the Consensus class.
Cheers! -Damian
-
Cristobal -
Damian Johnson -
Moritz Bartl -
nusenu