[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #21366 [Metrics/Atlas]: Support whitespace in search term (as does Onionoo)



#21366: Support whitespace in search term (as does Onionoo)
---------------------------+--------------------------
 Reporter:  cypherpunks    |          Owner:  karsten
     Type:  enhancement    |         Status:  accepted
 Priority:  Medium         |      Milestone:
Component:  Metrics/Atlas  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+--------------------------
Changes (by karsten):

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


Comment:

 So, I just rediscovered this ticket after seeing the link from #23829.
 Let's try harder to resolve it, as it might help us with that other
 ticket.

 I'm summarizing and commenting on all possible solutions to this issue in
 order of appearance:

  1. Allow parameters and qualified search terms to be specified more than
 once. As a result, `search=contact:Neel%20contact:Chauhan` would become a
 valid search for all contacts containing both name parts. This is not
 exactly what the ticket reporter needed to satisfy their use case. But I
 could see similar use cases where this would be useful. Let's move this to
 a new ticket if there's general agreement on whether this would be useful
 at all.

  2. Support quotes in qualified search terms. This was my original
 suggestion, and even though I raised some mild concerns about this
 approach being less intuitive than it could be, I think it's the best
 option we have. After all, we'd be adding this option for pro users who
 want to perform an exact match on a contact line or partial contact line
 that just happens to contain spaces. I wrote a surprisingly short patch
 for this in
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-21366
 my task-21366 branch] that still needs review. We might document this
 change by saying: "Qualified search terms have the form 'key:value' or
 'key:"value"' (both without surrounding single quotes) with "key" being
 one of the parameters [...]". I'm inclined to say that this requires just
 a minor protocol version bump, because we're currently returning a 400
 status code for this newly introduced syntax. Let me know what you think!

  3. Add an Atlas-level qualifier to search only in the contact line. I'm
 not a fan of this approach, because it seems too limiting. We cannot
 combine the search with any other parameter. And we'd have this same
 discussion again when adding an `as_name` parameter (#23713). And wouldn't
 it be bad to introduce another Atlas-level qualifier to search only in the
 AS name which couldn't be combined with other search terms like the
 country, whereas AS number and country could still be combined? All in
 all, I'd say let's drop this idea.

  4. Add an extended search form to Atlas with inputs for other parameters
 than Onionoo's search parameter. This is not my call. Personally, I'd
 rather go in the other direction and make the search parameter as powerful
 as the other parameters. But I can see value in providing a complete
 overview of possible parameters in Atlas. Maybe that's just a
 documentation issue. But if it helps to really provide such an extended
 search form to Atlas, I won't object.

  5. Extend Onionoo's search parameter to also look at contact line parts
 when processing unqualified search terms. That would mean not only looking
 at nicknames, fingerprints, IP addresses, etc., but also at contact line
 parts. I'm opposed to that idea. The effect would be that a simple search
 for a relay nickname part would suddenly produce lots of seemingly
 unrelated hits, because those relays have the nickname part in their
 contact line. Let's better not touch the Onionoo basics and drop this
 idea.

 So, my suggestion is to create a new ticket for 1, get 2 reviewed and
 merged, and possibly create another ticket for 4. Thoughts?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21366#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs