[metrics-team] onionoo exit_addresses semantics

[teor]

On 17 Feb 2018, at 11:05, nusenu <nusenu-lists at riseup.net> wrote:

>> On 17 Feb 2018, at 09:30, nusenu <nusenu-lists at riseup.net> wrote:
>> 
>>>>> 1. Stop deduplicating exit addresses and just include everything from
>>>>> exit lists found in the past 24 hours. Would this help?
>>>> 
>>>> This would be more accurate for my exit, which does not ever exit on
>>>> its ORPort address.
>>> 
>>> Why would that be more accurate? (it would not actually change exit_addresses
>>> compared to the current state if it never exits on the ORPort, right?)
>> 
>> The current format does not distinguish between:
>> * an exit that exits on its ORPort address and another address
>> * an exit that only exits on another address
> 
> Ok, I think I got your point now, it would not change your exit's exit_addresses
> field but it would result in a change for other exit relays that exited via their 
> ORPort IP _and_ some other address (within the last 24 hours) - and the fact that 
> it does _not_ include the OR IP would actually mean something (because currently
> there is not way it would be included).
> 
> I would still omit that field if ORPort IP would be the _only_ member in the exit_addresses 
> array because it increases size without increasing information.

That's true, but it also increases client code complexity, because a user has to
write something like:

Set actual exit addresses to exit addresses

if exit policy is not reject all IPv4 and exit addresses field is blank:
  Add ORPort IPv4 addresses to actual exit addresses

if exit policy is not reject all IPv6 and exit addresses field is blank:
  Add ORPort IPv6 addresses to actual exit addresses

Use actual exit addresses

Do we think users will understand the definition of exit addresses, and
write correct code like this every time?

It might be worth the extra data. Compression should reduce the extra
network bandwidth.

T