[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #16276 [Onionoo]: bug in onionoo's family set detection
#16276: bug in onionoo's family set detection
-----------------------------+-----------------
Reporter: cypherpunks | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Onionoo | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
-----------------------------+-----------------
Comment (by leeroy):
Okay. One way of implementing this would be to include an (optional)
effective_family_diff key to the details document. This could store the
set difference between the declared family (from parsing the descriptor)
and effective family (as in computing index for the family parameter).
If a node, W_OR, declares in it's descriptor a family including X_OR,
Y_OR, Z_OR, the effective family for all four nodes is { W_OR, X_OR, Y_OR,
Z_OR } iff a bidirectional relationship exists when checking the declared
family of each. The effective_family_diff key would not exist in this
case.
If, when checking a node in the family of W_OR, say Y_OR, the
bidirectional relation does not exist, it is added to
effective_family_diff. In this case the family key still contains { X_OR,
Y_OR, Z_OR } but now effective_family_diff, for W_OR, contains { Y_OR }.
A client of Onionoo, which hasn't been updated, would only know to use the
family key. An up-to-date client would be able to use
effective_family_diff when rendering a view. Preserving backwards
compatibility and giving the client a choice in how to visualize the
family. How does it sound?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16276#comment:8>
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