Notify people about relays that recently qualified for a Tor t-shirt

17:06:01 < arma10> kaner: my next feature request will be to subscribe some address as hearing about tshirt qualification for every single relay 17:06:23 < arma10> then a few tor people could be on that list, and whenever a relay passes that threshold, we learn about it and can reward them with personal attention

added component::metrics/tor weather owner::kaner priority::medium resolution::wontfix status::closed type::enhancement labels

One way I could imagine doing this is just to auto-subscribe that address for every relay in every consensus (no need to think of it as subscribing -- it's just modifying a db line I hope). Then weather would just do its normal thing.

I could imagine wanting to do something more efficient, depending on how weather looks on the inside.

How does the 'has earned a tshirt' feature work anyway? Does weather need to be up and maintaining its database for a month before any tshirt winners appear? Or is there a way to import old consensuses? Perhaps what we really want is a script that runs over a pile of consensuses and spits out a list of tshirt winners, and then some shell commands can tell us which ones are new?

While working on #2862 (moved) I looked how this feature works: weather is based on subscriptions. You can get a tshirt if 1) you subscribe for notification 2) you are up for X hours after that (+ get min required bandwidth). Problem: if you ever unsubscribe and re-subscribe, too bad, you need to wait again. I'd be curious if some exploited that to get multiple t-shirts :)

For reference, this is how a TShirtSub is created: https://gitweb.torproject.org/weather.git/blob/HEAD:/weather/weatherapp/views.py#l52 https://gitweb.torproject.org/weather.git/blob/HEAD:/weather/weatherapp/models.py#l1206

So as arma suggested, a quick solution would be to subscribe every node for tshirt, and keep that updated when new nodes appears in the consensus.

So yes weather would need to be up maintaining its database. I didn't see a way to import old consensuses, but I agree it would be nice. Question: using the fact that both uptime and bandwidth are trusted values because in the consensus, we can immediately tell if someone has earned a tshirt, right? That would be an interesting alternate solution: no need for t-shirt subscriptions, just listen to consensuses and e-mail (once) when requirements are met.

Thoughts? (and please correct me if I missing something)

Trac:
Username: StalkR
Cc: N/A to tor+trac@stalkr.net
Actualpoints: N/A to N/A

Oops, reading the spec (https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt) uptime, unlike bandwidth, is not part of the consensus, so we need to calculate it differently and it's not immediate (we need a list of consensuses as arma said).

Knowing:

• we cannot rely on router descriptors for uptime as they can be faked
• a node marked Running in consensus can be considered up
• node bandwidth in consensus can be trusted
• we do not want to reset uptime if a router is down, we want to resume increasing uptime next time it is up

I propose we can calculate the uptime of a given node by adding delays between consecutive consensuses in which we have seen the node was up. Also when incrementing the uptime, maintain node average bandwidth using node bandwidth in consensus (as done currently).

That way, we can calculate if a node owned a t-shirt by importing old consensuses.

Now do we prefer a script? (a)

• can be run offline, on an archive of consensuses

• need to run it manually/cron somewhere and some logic to distinguish which ones are new

or a quick solution integrated to TOR weather? (b)

• automated
• can easily have a page "did I win a t-shirt" #8999 (moved)

• no uptime accounting if weather is down/not maintaining its database, delaying t-shirts

Trac:
Username: StalkR

I am attempting to rewrite Weather.

I would like to move the uptime code out of Weather and have it published by a separate service. It would be nice to integrate this information with an existing service instead of creating and maintaining a different service just for publishing uptime. Does it make sense to have Onionoo publish a relay's uptime as a part of details document?

Replying to neena:

I am attempting to rewrite Weather.

Wonderful!

I would like to move the uptime code out of Weather and have it published by a separate service. It would be nice to integrate this information with an existing service instead of creating and maintaining a different service just for publishing uptime. Does it make sense to have Onionoo publish a relay's uptime as a part of details document?

Onionoo probably already has everything you need. Please see the discussion on #9889 (moved) for details. Let me know if you're missing something else.

Tor Weather has been discontinued as of May 24, 2016: https://lists.torproject.org/pipermail/tor-relays/2016-June/009424.html. Batch-closing all remaining tickets as announced in #19382 (moved). A list of these tickets and any other Weather tickets modified after June 26, 2016 will be available here: https://trac.torproject.org/projects/tor/query?changetime=Jun+27%2C+2016..&component=^Metrics%2FTor+Weather

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed

mentioned in issue #8999 (moved)