[tor-bugs] #16599 [Onionoo]: Onionoo feature

[Tor Bug Tracker & Wiki]

#16599: Onionoo feature
--------------------------------+-----------------
     Reporter:  virgilgriffith  |      Owner:
         Type:  enhancement     |     Status:  new
     Priority:  normal          |  Milestone:
    Component:  Onionoo         |    Version:
   Resolution:                  |   Keywords:
Actual Points:                  |  Parent ID:
       Points:                  |
--------------------------------+-----------------

Comment (by karsten):

 Before we discuss possible implementations of such a family ID, which is
 certainly algorithmically fun, I'd first want to talk more about the
 intended use case.  What do you need a unique family ID for?  Onionoo
 already has a `family` parameter that accepts a fingerprints and returns
 that relay plus all relays in that relay's family that also list that
 relay in their family.  What you could do in your Roster application is
 accept any relay fingerprint of a user's relay family and simply hand that
 fingerprint over to Onionoo.  Then you wouldn't have to introduce the
 concept of family IDs at all.

 Now to a possible implementation of such a family ID, assuming there's
 indeed a valid use case for it: I don't think we can implement the UUID
 schema you describe.  One issue is that two Onionoo instances, one of
 which having intermittend network problems, may have a slightly different
 view on the Tor network and therefore assign UUIDs differently.  And what
 if a relay that is around for years is suddenly reconfigured to join a
 family?  And more generally, what if two families are merged, or if a
 family falls apart?  I'm afraid we'd find many more edge cases where the
 proposed numbering schema would fail as soon as we start implementing it.
 The concept seems too fragile to me.

 There's also a problem with the definition of "effective family".  You
 write that "Relays of an effective family are defined as a set of relays
 where every relay has a symmetric connection to every other relay, or, in
 other words, every relay points to every other relay."  But that's not the
 case right now.  Consider a relay A with family A, B, C.  If B's family is
 A, B, and C's family is A, C, we'd right now say that A's effective family
 is A, B, C.  Maybe that means that our current definition of "effective
 family" is flawed.

 Here's an alternative idea which is, admittedly, not fleshed out yet.  Can
 we combine relay fingerprints of family members somehow into a family
 fingerprint and use that to identify the family?  Of course, that family
 fingerprint would change once family members leave or new members join,
 but maybe we can use some kind of distance metric and identify the family
 that is closest to that fingerprint: "The family fingerprint XY is
 unknown, but there are two families with similar fingerprints XZ and WY."
 I could trying out bit-wise operations or probabilistic data structures
 for family fingerprints and then using something like Hamming distance for
 the comparison.

 Another option to consider here is to just go ahead and implement proposal
 242.  This might be a good opportunity to do the research and the coding,
 and it's not only Roster/Onionoo users that would benefit from that, but
 all relay family operators.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16599#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online