Add Onionoo's exit_addresses field

[cypherpunks]

Ideally display them similarly to the entries in the MyFamily lists.

[cypherpunks]

Replying to cypherpunks:

Ideally display them similarly to the entries in the MyFamily lists.

I don't think this is ideal because it would be inconsistent with the style of the OR and Dir addresses fields.

Regarding the implementation of this feature, the Onionoo documentation on the exit_addresses field states it is an

[a]rray of IPv4 or IPv6 addresses that the relay used to exit to the Internet in the past 24 hours. IPv6 hex characters are all lower-case. Only those addresses are listed that are different from onion-routing addresses. Omitted if array is empty.

This means exit relays that use the same address(es) for both OR and exiting have no exit_addresses field. Showing the field as empty (or none as is common for empty fields in Atlas) is confusing IMO. I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

[irl]

Replying to cypherpunks:

I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

I'm not sure about this. Maybe when I see it I'll have a better idea. OR addresses have ports, exit addresses do not. While I can see how these are related, I wonder what the best presentation would be. It also cannot be assumed that an empty exit_addresses means that it will exit from the OR address, as it may just be that the exit scanner is broken, so that confusion should be avoided also.

[cypherpunks]

Replying to irl:

Replying to cypherpunks:

I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

I'm not sure about this. Maybe when I see it I'll have a better idea. OR addresses have ports, exit addresses do not.

I will strip off the ports before merging the fields.

While I can see how these are related, I wonder what the best presentation would be. It also cannot be assumed that an empty exit_addresses means that it will exit from the OR address, as it may just be that the exit scanner is broken, so that confusion should be avoided also.

From the wording of the Onionoo description i assumed the OR address is always an exit address. Is this not correct?

[nusenu]

Replying to cypherpunks:

This means exit relays that use the same address(es) for both OR and exiting have no exit_addresses field. Showing the field as empty (or none as is common for empty fields in Atlas) is confusing IMO.

I disagree, there is a distinction between OR address and exit_address.

I plan to solve this confusion by merging the or_addresses and exit_addresses field and using the result for displaying the exit addresses.

Please do not merge them.

[nusenu]

Replying to cypherpunks:

From the wording of the Onionoo description i assumed the OR address is always an exit address. Is this not correct?

No this is not correct.
See also:
​https://www.torproject.org/docs/tor-manual.html.en#OutboundBindAddressExit

[nusenu]

Onionoo is rather clear about exit_addresses:

Only those addresses are listed that are different from onion-routing addresses

the same level of clearness should be on the atlas page displaying exit_addresses.

Empty exit_addresses for exits that exit with their OR IP address are clear in the context of the above statement.

[cypherpunks]

Replying to nusenu:

Onionoo is rather clear about exit_addresses:

Only those addresses are listed that are different from onion-routing addresses

the same level of clearness should be on the atlas page displaying exit_addresses.

Empty exit_addresses for exits that exit with their OR IP address are clear in the context of the above statement.

Okay, I'll not merge the two fields and add emphasis to the distinction in a tooltip.

[nusenu]

thanks.
The title for the list of exit_addresses could be
"Not-announced Exit IP Addresses"

[cypherpunks]

Replying to nusenu:

thanks.
The title for the list of exit_addresses could be
"Not-announced Exit IP Addresses"

I kept the title similar to existing fields by simply naming it Exit Addresses.

I've opened #22160 for improving the address list style because some relays have more than two exit addresses which leads to styling issues.

[nusenu]

Also note that this list can be rather long (biggest entry I've seen so fare was 297 chars long).
That is why I suggested to use a vertical style like the fingerprints in family blocks.

[cypherpunks]

Replying to nusenu:

Also note that this list can be rather long (biggest entry I've seen so fare was 297 chars long).
That is why I suggested to use a vertical style like the fingerprints in family blocks.

Can you give the fingerprint so i can use it while working on #22160?

[nusenu]

this one is 173 chars long:

​https://onionoo.torproject.org/details?fingerprint=8ED43EC3683D7E261BB8FEA4EA8122952968CF8E&
fields=exit_addresses

[irl]

Can the patch be updated to work better with the longer lists?

[cypherpunks]

I've attached two additional patches. 0001-Support-long-address-lists.patch​ uses pre blocks to display addresses, and fields that represent arrays of addresses are made scrollable. 0002-Reorder-fields-to-group-similar-styling-together.patch​ reorders the fields so fields that use pre blocks are grouped together which IMO looks better.

#22160 is now a child of this ticket because these patches fix the issue that that ticket addresses.

Curiously the number of exit addresses per relay have been reduced significantly, at the time of writing there are at most 3 exit addresses.

[irl]

I've not looked at this yet, but I think I'm going to find that having things grouped by presentation as opposed to content is less than optimal...

(I've closed #22160 as this is being done here and only affects this bug anyway.)

[irl]

Sorry, could these patches be rebased against the current master?

[karsten]

Use more capital letters in summary.

[irl]

Moving this into my queue.

[irl]

Fixed in e565a2ea1952901b95ed93c3536652378493a5d8.

I have not included the presentation patches. If this becomes an issue in the future we can take another look at this.