I withdraw my desire this proposal. In Roster we wouldn't want these /16 network families---we just wanted to collapse some relays together when we reliably believe they have the same operator, and there's no reason to believe the majority of relays within a /16 are owned by the same person.
Ergo, Roster will forgo this kind of merging. -V On Friday, 5 February 2016, Karsten Loesing <kars...@torproject.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [Removing metrics-team@ to avoid cross posting.] > > On 28/01/16 21:22, Tim Wilson-Brown - teor wrote: > > > >> On 29 Jan 2016, at 07:20, Roman Mamedov <r...@romanrm.net <javascript:;>> > wrote: > >> > >> On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor > >> <teor2...@gmail.com <javascript:;>> wrote: > >> > >>> Tor already considers relays in the same IPv4 /16 to be in the > >>> same family. > >> > >> Maybe a step further in this would be to autoextend manually > >> declared families with all relays running on the same IPs of any > >> relays in the family. Dunno how complex or how useful this would > >> be. It could at least fix-up some outdated or missed > >> declarations. > > > > In Tor, or OnionOO? > > > > Tor already does this using the IP address whenever a path is > > built. If Tor added it on the relay side, then we'd bloat > > descriptors for no reason. > > Agreed. > > > If OnionOO added it, it would save OnionOO clients some work. > > Let's consider this. I'm pasting current definitions of related > Onionoo fields here, so that people can follow more easily: > > - "effective_family": Array of $-prefixed fingerprints of relays that > are in an effective, mutual family relationship with this relay. These > relays are part of this relay's family and they consider this relay to > be part of their family. Omitted if empty or if descriptor containing > this information cannot be found. > > - "alleged_family": Array of $-prefixed fingerprints of relays that > are not in an effective, mutual family relationship with this relay. > These relays are part of this relay's family but they don't consider > this relay to be part of their family. Omitted if empty or if > descriptor containing this information cannot be found. > > - "indirect_family": Array of $-prefixed fingerprints of relays that > are not in an effective, mutual family relationship with this relay > but that can be reached by following effective, mutual family > relationships starting at this relay. Omitted if empty or if > descriptor containing this information cannot be found. > > Now, from reading this thread I can see us adding or extending the > following fields: > > - Extend "effective_family" to also include relays on the same IP > address or in the same /16. I'd rather not want to do this, because > we wouldn't be able to say whether that other relay is in a mutually > declared family relationship or just runs on a nearby IP address. > > - Add new "network_family" field with fingerprints of all relays in > the same /16. Plausible, but duplicates fingerprints that are already > in "effective_family". > > - Add new "network_family" field with only those fingerprints of > relays in the same /16 that are not contained in "effective_family". > "Tor considers these relays to be part of your relay's family, because > they have similar enough network addresses. If you are running them, > please consider setting the family option." Plausible, though not > trivial to grasp without further explanation. > > - Add new "extended_network_family" field with fingerprints of relays > in the same /16 as this relay or relays in "effective_family" and > "indirect_family", except for fingerprints in those two fields. Also > plausible for the Roster use case to identify all relays close to the > family that the user may have omitted in their family definitions. > Not sure if this is necessary. > > - Add new "abandoned_family" field with fingerprints of relays that > declare this relay to be part of their family but that are not > contained in this relay's family declaration. Looks like we never > considered this field before, but it might be useful to help relay > operators fix their family declarations. > > Which of these fields would be useful to have? "All of them" is not a > good response, because we shouldn't make Onionoo responses bigger if > nobody uses the new data. But I'm happy to discuss use cases and then > add new fields as required. > > All the best, > Karsten > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJWtGubAAoJEJD5dJfVqbCrwDEIAMN/JCYq99J/H3AZKqkt3pLe > qvWP8uQxBfbnmxwOhOq4IFFCa1o+FpITOxmhZEuxVNGaqszBqSxFpDn62pjK8YCS > 7Wi2IqUoZDIdHwLsJMgfrn+/HH4BoctTu0PzHWsZsmcdjJqPr8R+AP7WRZN3SM2W > /ML8AULWIwSUVmIfKD3iYM9RbFfxFeCARirDsAxC394z2ei06git4sJA5cSROx35 > 9IzqdpPyJoplYBRk7INCmr0bHNXvsIRODQ0n0QIJrIl1ESHpqhsy13fTo/1ndlKR > BUM2XCao0HABwpdBOrinfpybuGUSPXjrqw8expkUE+w2VuzOdkkNod1J3wgFyXc= > =KM0S > -----END PGP SIGNATURE----- > _______________________________________________ > tor-relays mailing list > tor-relays@lists.torproject.org <javascript:;> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays