(since this is not really part of that ticket I'm moving this reply to tor-dev) Replying to [comment:21 virgil][1]: > Re: comment #15 >> 2) there are no incentives for a relay operator to set it properly > > Roster aims to fix this. http://tor-roster.org Quite the opposite I think. tor-roster creates incentives for lazy operators because it does not require a proper MyFamily configuration to aggregate relays into a group. tor-roaster's way to group relays (one mutual connection into a group of relays is enough iirc) does not match tor's definition of MyFamily. While tor-roster's way to group actual set of relays to it's operator might represent a more accurate picture of reality than systems that do require proper MyFamily configs, it misses the possibility to create incentives for proper configurations. > For what it's worth, Roster also makes MyFamily a bit less painful to > work with because the detected families are now robust to changes > in the Family graph. For details see [3] This causes the offset between tor's and tor-roster's interpretation/definition. To give you an example, roster says this relay is part of a 24 relays group [4] even though it has only a mutual MyFamily with two other relays: https://atlas.torproject.org/#details/E6E18151300F90C235D3809F90B31330737CEB43 Ideally tor-roster would make it very clear on their website that groups do not require a complete mutual MyFamily agreement between all relays in that group, or require proper MyFamily configuration to create incentives for properly configured families. [1] https://trac.torproject.org/projects/tor/ticket/6676 [3] ttps://trac.torproject.org/projects/tor/ticket/16750 [4] http://tor-roster.org/family_detail/E26AFC5F718E21AC502899B20C653AEFF688B0D2
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev