-----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 rm@romanrm.net wrote:
On Fri, 29 Jan 2016 06:33:51 +1100 Tim Wilson-Brown - teor teor2345@gmail.com 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