[metrics-team] onionoo search semantics: AND vs. OR?

[Karsten Loesing]

On 23.04.17 01:01, nusenu wrote:
> Hi,

Hi nusenu,

> (trying to find a stop-gap solution for
> https://trac.torproject.org/projects/tor/ticket/21366)

We should probably discuss this on the ticket, not here.  Quick response
below though.

> from onionoo.tpo:
>> search
>>
>> Return only (1) relays with the parameter value matching (part of a) 
>> nickname, (possibly $-prefixed) [...]
>> If multiple search terms are given, separated by spaces, the
>> **intersection** of all relays and bridges matching all search terms
>> will be returned.
> 
> 
> Karsten wrote
> (https://trac.torproject.org/projects/tor/ticket/21366#comment:4)
>> You could approximate the second example by using
>> search=contact:Neel%20contact:Chauhan, but that will also return all
>> relays that have those **two** strings somewhere in the contact line,
>> rather than just Neel Chauhan.
> 
> 
> So I would assume that
> https://atlas.torproject.org/#search/contact:Neel%20contact:Chauhan
> (backend:
> https://onionoo.torproject.org/summary?search=contact:Neel%20contact:Chauhan)
> 
> should only return relays where the contact field contains "Neel"
> **and** "Chauhan" but it also returns relays that have only "Neel" (and
> no "Chauhan"), so I would deduce that search terms are OR connected.
> 
> example contact result:
> "<neel AT rdkr DOT uk> 0xBBC1514B34CFB0F10231280F2FC36F0EF7887127"

Hmm, looks like my suggestion was misleading.  The two qualified search
terms are not OR-connected, but the second search term is simply
discarded.  Try swapping the two and see how that changes the result.

The spec says: "If the same parameter is specified more than once, only
the first parameter value is considered."

Now, the search term is only given once, but the qualified search terms
are treated as if the user passed values to keys matching search
qualifiers.  And the second contact parameter is simply dropped.

This is expected behavior that we might be able to document better.

All the best,
Karsten


> 
> If search terms are OR connected (not the "intersection")
> then I would simply list all the fingerprints to get a list of all
> relevant relays, but that does not work either (no results)
> example (2 fingerprints separated by a single space):
> https://atlas.torproject.org/#search/D5B8C38539C509380767D4DE20DE84CF84EE8299%201602E42D1DE3C7B3EF042F357F906DE55FA6C7C6
> Also tried:
> "lookup:D5B8C38539C509380767D4DE20DE84CF84EE8299%20lookup:1602E42D1DE3C7B3EF042F357F906DE55FA6C7C6"
> 
> In this search, the search terms are AND connected:
> 
> https://onionoo.torproject.org/summary?search=contact:Neel%20D46175487C3
> 
> So I'm not sure
> - if the current behavior works as documented and intended
> - How to get a stop-gap solution without false-positives/false-negative
> search results
> 
> Is this a bug or am I misunderstanding something?
> (or does the AND/OR mode depend on whether search qualifiers are used?)
> 
> thanks,
> nusenu
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> metrics-team mailing list
> metrics-team at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20170423/e3d4637c/attachment.sig>