-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi,
when requesting a new group by feature for compass [1] (#6662 [2]) I discussed with Karsten about how to handle asynchronous/overlapping families: karsten: > Here's an example. Assume we have three relays: A, B, and C. These > relays state the following family relationships: > > A: A, B B: A, B, C C: B, C > > We require mutual agreement about being in the same family, so we > could either come up with family A, B or with family B, C. Which > one is correct? I proposed to go with family = A, B, C because there is a mutual agreement between A<->B and B<->C. A and C agreed to be in a family with B, and B agreed to be in a family with A and C. Such configurations can be found in the wild mostly due to incomplete MyFamily configurations on relays in big families. As every big relay operator knows configuring families is a non-trivial effort with a growing number of relays. Now I thought about it and wanted to suggest this MyFamily interpretation as an alternate approach to the fully mutual setup where *every* relay must be reconfigured as opposed to just two of them. Why? This would reduce the configuration effort required when adding a new relay to *two* relays regardless of how many relays are in your family. Now, the MyFamily configuration overhead for big families is a well known problem so I suppose someone else did already propose this approach? What do you think about it? [1] https://compass.torproject.org [2] https://trac.torproject.org/projects/tor/ticket/6662 a additional example to make this clearer: A: A, B, C B: A, B, C C: A, B, C D: A, B, C, D family = A, B, C A family member must have a *mutual* agreement with at least *one* node. -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlA2YkoACgkQyM26BSNOM7Yp2wD/VTBw8BmUJlRZtIfXahIGX+t0 zwzP6MfRDwgPCsQMeEUA/3dUyyoq91Fx4lmihWHis2DZNAoM/CHh2MnwgMNL/W1W =FWRU -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev