[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: enhancement | Status: new
Priority: normal | Milestone:
Component: Onionoo | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
-----------------------------+-----------------
Comment (by karsten):
First of all, you're right that having both `"family"` and
`"effective_family"` fields is a contradiction to the redundancy
statement. The primary idea of leaving `"family"` untouched was to be
backwards-compatible, and the argument of avoiding redundancy was supposed
to avoid yet another field with the declared family members that did
''not'' make it into the family.
Regarding your first comment about detecting misconfigurations, the goal
would be to do this with a single details document for a given relay.
When Atlas or Globe display the details, they should have an easy way to
detect misconfigurations in the relay's family configuration. It's easy
for them to compute set diffs, so we wouldn't have to pre-compute a set of
unused family members for them. That's what I meant by "not a service
used by humans". The approach you mention might be too complicated for
Atlas/Globe. All they do is display data, and that's okay.
About your comment about considering worst cases, I agree that this might
get more complex than expected. And maybe we're overengineering this.
Maybe the better solution would be to make that backward-incompatible
change where we only list effective family members in the `"family"`
field. All I say is that this would require a major protocol change and 1
or 2 months time for Onionoo clients to adapt. But maybe it's the better
way, because people (in this case Onionoo client developers) won't be
confused by two different family fields.
By the way, my plan was indeed to update effective family sets every hour.
We already update details files of all running relays and of all relays
that just stopped running. Computing those sets every hour shouldn't be
difficult.
How do we proceed? What's your favorite solution? And would you want to
start hacking on this?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16276#comment:24>
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