Integrating Kovri?

[CameronRuggles]

It seems like it could be valuable to integrate Kovri, which is a C++ version of I2P being built by the Monero developers.

This could help hide from where the messages are originating and limit the ability of correlation attacks.

https://github.com/monero-project/kovri

[PeterSurda]

I'm not opposed to it, but it requires a protocol change (because the I2P addresses don't fit into the current addr variables) so it would have to wait until more protocol changes are gathered.

[jakobvarmose]

Why not use a new protocol message named "i2paddr" that will include the I2P addresses. Then the old nodes would just ignore it.

[PeterSurda]

@jakobvarmose What an interesting proposition. I need to think about it but I'm inclined to agree with you. I'm redesigning the network system anyway, so it will be easier for developers to add new commands.

[PeterSurda]

The "version" command won't be compatible with a different addressing scheme. However it probably isn't a big deal as the values from this command aren't really usable if using an anonymising layer.

The current net_addr specification also only allows 32bit streams and would have to be expanded to 64 to coincide with the rest of the protocol anyway. So I propose to merge these two attempts by creating a new command and a new data type that is both able to handle 64bit stream identifiers and a greater range of address types. Let's call it "addrv2" or "addr64". The data type would add a new field, addr_type, a varint representing an enum, bump the stream length from 32bit to 64bit and that of the "IPv6/4" field from 64 to 256bit (the length of an I2P identifier). Also it could change the "stream" field to an array, so that multi-stream node could be advertised more efficiently and make routing path discovery easier.