Re: [tor-bugs] #15844 [Onionoo]: Develop database schema to support Onionoo's search parameter efficiently

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#15844: Develop database schema to support Onionoo's search parameter efficiently
-----------------------------+-----------------
     Reporter:  karsten      |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Onionoo      |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------

Comment (by karsten):

 Replying to [comment:19 leeroy]:
 > I've been familiarizing myself with the code in an effort to understand
 the properties of the various datatypes. I would like to ensure I'm
 correct in my understanding: Bridges can only be located by sha1 of
 fingerprint?

 That, plus the sha1 of the sha1 of the fingerprint.  Let me explain: when
 CollecTor sanitizes bridge descriptors it puts in the sha1 of the bridge
 fingerprint.  So, Onionoo doesn't even learn the original fingerprint.
 But Onionoo also returns that bridge if you ask it for the sha1 of the
 sha1 of the fingerprint, because Onionoo clients are encouraged to sha1
 any fingerprint they receive from clients in order not to accidentally
 include a non-sha1 fingerprint.

 Feel free to ignore the background and go by these rules:
  - relays can be looked up by fingerprint and sha1 of fingerprint,
  - bridges can be looked up by sha1 of fingerprint and sha1 of sha1 of
 fingerprint.

 > Relays can be located by fingerprint, sha1 of fingerprint, or base64
 encoding of fingerprint?

 Yep.

 > A function index using digest() and encode() will ensure all three are
 fast with the advantage of only storing one.

 Keep in mind that you'll have to handle partial fingerprints as input, so
 your plan might not work.  Similarly, converting partial fingerprints
 between hex and base64 might be problematic because of 4 vs. 6 bits per
 character.  I'd say never mind the storage and just put in everything you
 want into the database.

 > I would also like to ask how strict is the protocol wrt the ordering of
 keys in JSON responses? For example using Atlas as a client. I wouldn't
 want to break anything when using pgnosql. The RFC defines the set as
 unordered for interoperability.

 Ordering matters if users ask for a specific ordering using the `order`
 parameter.  Of course, if they don't pass that, you're free to return
 results in whatever order you want.

 Hope that helps!  Thanks for working on this!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15844#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