Opened 9 years ago

Closed 3 years ago

#2461 closed enhancement (wontfix)

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

Reported by: karsten Owned by: kaner
Priority: Medium Milestone:
Component: Metrics/Tor Weather Version:
Severity: Keywords:
Cc: tor+trac@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

TicketTypeStatusOwnerSummary
#8999defectclosedStalkRCreate a page "did I earn a t-shirt?"

Change History (6)

comment:1 Changed 9 years ago by arma

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?

comment:2 Changed 7 years ago by StalkR

Cc: tor+trac@… added

While working on #2862 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)

comment:3 Changed 7 years ago by StalkR

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

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

comment:4 Changed 6 years ago by neena

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?

comment:5 in reply to:  4 Changed 6 years ago by karsten

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 for details. Let me know if you're missing something else.

comment:6 Changed 3 years ago by karsten

Resolution: wontfix
Status: newclosed

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. 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

Note: See TracTickets for help on using tickets.