Repository navigation
Integrating Kovri? #943
Description
Activity
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.
Why not use a new protocol message named "i2paddr" that will include the I2P addresses. Then the old nodes would just ignore it.
@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.
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.
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