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

[Tor Bug Tracker & Wiki]

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

 * milestone:  Onionoo 1.17.0 => Onionoo 1.18.0


Comment:

 Versions 1.17.0 and 1.17.1 are already released, the next released version
 will be 1.18.0.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 This looks good to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * reviewer:   => irl


Comment:

 Will look at this tomorrow UTC morning unless anything more urgent comes
 up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * status:  accepted => needs_review


Comment:

 Please review
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-6947=9740ce76bd10d11772ec7250b9c23d33b4e99866
 commit 9740ce7 in my task-6947 branch]. Once this patch is merge-ready,
 let's schedule the next major version for a month later and put the merge
 on hold for that time. Thanks!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * owner:  metrics-team => karsten
 * status:  assigned => accepted


Comment:

 Okay, great, I think that's enough to start writing some code. Grabbing
 the ticket.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-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:
-+--

Comment (by irl):

 Replying to [comment:11 karsten]:
 > Hmm, on second thought, `:` wouldn't work so well with qualified search
 terms. Imagine a search for `version:0.3.2.1:0.3.2.5` (for versions
 0.3.2.1, 0.3.2.2, 0.3.2.3, 0.3.2.4, and 0.3.2.5) or even
 `version::0.3.2.5` (for everything ''until'' 0.3.2.5) or
 `version:0.3.2.1:` for 0.3.2.1 or newer).

 Good point.

 > New idea (sorry for the brainstorming, I'm just trying to find the best
 solution): `..`, as in `version:0.3.2.1..0.3.2.5` or `version:..0.3.2.5`
 or `version:0.3.2.1..` for the examples given above. Yet unimplemented, so
 no guarantee that it will work well in all cases. We'd only have to
 require that versions don't contain two consecutive `.`, but that should
 be a safe assumption. What do you think? Are there better alternatives?

 Yes, I think a double `.` is safer than a `:`. I know that `:` is
 perfectly valid in Debian package version numbers and perhaps there would
 be other clients that use it in the future.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-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:
-+--

Comment (by karsten):

 Replying to [comment:10 irl]:
 > Replying to [comment:9 karsten]:
 > > However, I'm not sure what the most intuitive interface is. Maybe it's
 something else, like a different character for ranges, such as
 `/details?version=0.3.2.1:0.3.2.5`. (If so, we should consider changing
 `first_seen_days` and `last_seen_days`, too, for consistency.)
 >
 > I think using `:` for ranges is better, as long as we can be certain
 that we'll never see a `:` in a released Tor version. We should probably
 require this in torspec somewhere. If we do a major version change, which
 I think we should for this, then we would also change
 `{first,last}_seen_days`.

 Hmm, on second thought, `:` wouldn't work so well with qualified search
 terms. Imagine a search for `version:0.3.2.1:0.3.2.5` (for versions
 0.3.2.1, 0.3.2.2, 0.3.2.3, 0.3.2.4, and 0.3.2.5) or even
 `version::0.3.2.5` (for everything ''until'' 0.3.2.5) or
 `version:0.3.2.1:` for 0.3.2.1 or newer).

 New idea (sorry for the brainstorming, I'm just trying to find the best
 solution): `..`, as in `version:0.3.2.1..0.3.2.5` or `version:..0.3.2.5`
 or `version:0.3.2.1..` for the examples given above. Yet unimplemented, so
 no guarantee that it will work well in all cases. We'd only have to
 require that versions don't contain two consecutive `.`, but that should
 be a safe assumption. What do you think? Are there better alternatives?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-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:
-+--

Comment (by irl):

 Replying to [comment:9 karsten]:
 > However, I'm not sure what the most intuitive interface is. Maybe it's
 something else, like a different character for ranges, such as
 `/details?version=0.3.2.1:0.3.2.5`. (If so, we should consider changing
 `first_seen_days` and `last_seen_days`, too, for consistency.)

 I think using `:` for ranges is better, as long as we can be certain that
 we'll never see a `:` in a released Tor version. We should probably
 require this in torspec somewhere. If we do a major version change, which
 I think we should for this, then we would also change
 `{first,last}_seen_days`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-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:
-+--

Comment (by karsten):

 Replying to [comment:8 irl]:
 > We have version ordering logic now thanks to the `version_status` field.

 Yes! It might that we need to write some more code to also support version
 prefixes, but most of the code should already be there.

 > We can have a `from_version` and `to_version` parameter?

 Hmm, let's ignore for a moment that we already have a `version` parameter
 and let's discuss how we would like to build version-related parameters.
 Wouldn't it be more intuitive if we had a single `version` parameter that
 supports single versions, dash-separated version ranges, and possibly even
 comma-separated versions or version ranges? Keep in mind that some users
 may want to use these parameters as qualified search terms.

 Maybe my list of design questions looked too alarming, but that was not my
 intention. I think it's perfectly fine to make a major protocol update, if
 it's a useful change. We just need to give folks the chance to update
 their clients, bookmarks, etc. But if the result is a more intuitive
 interface, that's worth the effort.

 However, I'm not sure what the most intuitive interface is. Maybe it's
 something else, like a different character for ranges, such as
 `/details?version=0.3.2.1:0.3.2.5`. (If so, we should consider changing
 `first_seen_days` and `last_seen_days`, too, for consistency.)

 > We can then separately also have comma separated versions for prefix
 matches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-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:
-+--

Comment (by irl):

 We have version ordering logic now thanks to the `version_status` field.
 We can have a `from_version` and `to_version` parameter?

 We can then separately also have comma separated versions for prefix
 matches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-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 irl):

 * component:  Metrics/Atlas => Metrics/Onionoo


Comment:

 Relay Search will magically support this for both single relay lookup and
 aggregations if it's supported by Onionoo.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs