[tor-bugs] #9889 [Atlas]: Add "Tshirt: yes/no" to Atlas and Globe

[Tor Bug Tracker & Wiki]

#9889: Add "Tshirt: yes/no" to Atlas and Globe
-----------------------------+---------------------
     Reporter:  arma         |      Owner:  hellais
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Atlas        |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------

Comment (by karsten):

 Onionoo has the data you're looking for.  Here's how you'd ask for it:
  - Fetch the relay's bandwidth history at
 https://onionoo.torproject.org/bandwidth?lookup=DA24B9CD2AA8C02B9068A168C420DC302D969937
 and look at the `3_months` part of `write_history`.
  - Skip the first values until you reached the time interval starting 2
 months ago.
  - Sum up the remaining values, counting `null` as 0.
  - Add 0's for the time interval between `last` and today.
  - Divide total sum by number of values.
  - Multiply result with `factor` (because values are normalized to
 `0..999` range).
  - If result is >= 500000, operator gets a t-shirt.
  - If 100000 <= result < 500000 and if the relay's details document at
 https://onionoo.torproject.org/details?lookup=DA24B9CD2AA8C02B9068A168C420DC302D969937
 lists port 80 under `accept` in `exit_policy_summary` (or alternatively
 doesn't list it under `reject`), operator gets a t-shirt.

 So, should there be a "Tshirt: yes/no" in Atlas and Globe?  Maybe not.  An
 unexpected "no" or "yes" would only leave people wondering which of the
 requirements they failed to meet.

 How about Somebody (TM) writes a simple script to run the steps above and
 provide debugging information why the relay operator should have a t-shirt
 or not?  There can be many reasons, like the relay not being around long
 enough, too much downtime, not permitting port 80, etc.  This script could
 be a shell script or a simple website with a JavaScript part.  This could
 be a fine volunteer task.

 The better long-term fix would be to make Weather use Onionoo's data for
 all its operation.  In fact, it's one of the example use cases I had in
 mind when designing Onionoo (search for "Weather" on
 https://www.torproject.org/projects/onionoo.html.en).  That rewritten
 Weather service would use Onionoo to:
  - search for relays, similar to how Atlas and Globe perform searches,
 which would allow us to stop linking to metrics' relay search for
 searching for a relay fingerprint (of course, it could also link to Atlas
 for that search);
  - check the `last_seen` field of a subscribed relay to detect if a relay
 goes offline; and
  - implement the check above to decide whether a relay operator should
 have a t-shirt.
 I bet the codebase of that rewritten Weather would be much smaller than of
 the current Weather.  All the hard work is already done by Onionoo.  This
 rewrite would also be a fine volunteer task.

 But let's do the short-term things before the long-term things: write a
 script (Python, JavaScript, $your-favorite-scripting-language-that-can-
 parse-JSON, etc.) to perform the steps sketched out above.  Anybody?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9889#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online