[metrics-bugs] #23829 [Metrics/Onionoo]: Add support for search term negation
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Oct 20 07:47:41 UTC 2017
#23829: Add support for search term negation
-----------------------------+------------------------------
Reporter: cypherpunks | Owner: metrics-team
Type: enhancement | Status: needs_review
Priority: Medium | Milestone:
Component: Metrics/Onionoo | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------+------------------------------
Comment (by karsten):
Replying to [comment:4 nusenu]:
> Replying to [comment:3 karsten]:
> > Mind opening one if you think that would be a useful feature?
>
> #23914
Thanks!
> > Regarding the other parameters that you suggest that should support
negation, that list sounds reasonable. What it does not mention is the
"search" parameter itself, which means unqualified search terms for which
you give use cases further down below.
>
> Since I realized that nickname and IP are mutually exclusive (nickname
can not contain dots, IPs can not contain chars) it makes sense to add
them as well even without specific IP: nickname: parameters.
Ah! Well, you're right that nicknames and IPs are mutually exclusive. But
other unqualified search terms are not. For example, `aaaa` could be the
beginning of a hex-encoded fingerprint, any 4 hex character block in the
middle of a space-separated fingerprint, the beginning of a base64-encoded
fingerprint, the beginning of an IPv6 address, the beginning of a
nickname, and maybe even something else I didn't think of right now. It
would probably be very confusing to look at the results of `search=!aaaa`
and guess which relays were excluded and why. Hmm.
> > Before I go write more code, can you answer the following usability
questions (numbered for easier reference, not to indicate priority)?
> > 1. Is `!` the best character we can find to indicate negation? Or
should we instead pick `-`? Or something else?
>
> `!` is IMHO the most intuitive and most common character for this use-
case. This would be my first try before reading any documentation.
Sounds good. I'll leave this question open here for a few more days to
hear if somebody strongly disagrees. Otherwise it's going to be `!`.
> > 2. We'll have to extend the various parameters to support `!` as part
of the parameter value as in `search=flag:!exit`, and we'll have to allow
unqualified search terms starting with `!` as in `search=!default`. But
should we also allow qualified search terms starting with `!` as in
`search=!flag:exit` which would be equivalent to `search=flag:!exit`? Note
that if we do, `search=!flag:!exit` would be a valid parameter, as would
`search=!flag:exit,guard` or `search=!flag:!exit,guard` if we extend the
"flag" parameter as mentioned in my first paragraph. It would be up to the
user to interpret what that might possibly mean. But maybe they're to
blame if they write such a complex query rather than us for accepting it.
;)
>
> All use-cases can be formed with the `!` sign being used in the value
part only, right?
Yes.
> `!flag:!guard,exit == flag:guard,!exit` ?
Unfortunately, no:
`NOT (NOT guard AND exit) == guard OR NOT exit != guard AND NOT exit`
I'm inclined to take back the suggestion to negate search terms. If we
limit negation to parameters like "flag", "as", and so on, that might be
more intuitive. And we could always extend it to the "search" parameter
later on in a backward-compatible if we change our minds. But I think we
should start without the "search" parameter, except for values of
qualified search terms, of course.
Alright, I think I can work with this and write some more code. That won't
happen today, but I'll try to do this next week.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23829#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the metrics-bugs
mailing list