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