#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs