[metrics-bugs] #6947 [Metrics/Onionoo]: Allow filtering relays by version ranges

[Tor Bug Tracker & Wiki]

#6947: Allow filtering relays by version ranges
-----------------------------+------------------------------
 Reporter:  rransom          |          Owner:  metrics-team
     Type:  enhancement      |         Status:  assigned
 Priority:  Medium           |      Milestone:
Component:  Metrics/Onionoo  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------
Changes (by karsten):

 * cc: metrics-team (added)


Comment:

 I started to think about this today and came up with a few design
 questions that we need to answer first:

  - Dashes in tor versions: As of now, a query for
 `/details?version=0.3.4.5-rc` returns relays with version "0.3.4.5-rc".
 But the dash is also a quite intuitive notation for a range, just like
 we're using a dash in the `first_seen_days` and `last_seen_days`
 parameters. If we're going to support version ranges, we might want to use
 the dash for queries like `/details?version=0.3.4.5-0.3.4.6`. If we do,
 the first query won't work anymore, and would have to be changed to
 `/details?version=0.3.4.5`. The result set will remain the same, it's just
 that people will get it wrong in the beginning. Needs a major protocol
 update.

  - Prefix matching: The query `/details?version=0.3.2.1` returns relays
 with version 0.3.2.1 as well as 0.3.2.10, 0.3.2.11, and so on. Following
 that logic, which versions would we expect that the query
 `/details?version=0.3.2.2-0.3.2.1` returns? Everything from 0.3.2.1 to
 0.3.2.29, plus 0.3.2.100 to 0.3.2.199, etc. Maybe we should consider
 changing the matching algorithm to attempt to parse the version (prefix)
 and do the matching numerically. In this case the example above would
 simply be rejected, and a query `/details?version=0.3.2.1-0.3.2.2` would
 just return those two versions and nothing else. Needs a major protocol
 update.

  - Comma-separated versions or version ranges: I could imagine use cases
 where somebody wants all relays with non-consecutive version numbers.
 While we're changing this parameter for version ranges we could as well
 start supporting comma-separated versions or version ranges. As in:
 `/details?version=0.3.2.1,0.3.2.5`. Needs a minor protocol update unless
 combined with the changes above.

 Thoughts?

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