I2P integration

[layters]

Details

By default all peers will be anonymized through the use of i2pd. Like how Monero has mandatory privacy, i2p will be mandatory for routing the network traffic of users. This is the only way to make neroshop truly private and censorship-resistant. Currently, I'm facing issues relating to bypassing NAT routers and firewalls while using the low-level C API (POSIX) sockets provided by the operating system and I need urgent help with i2pd integration.

Tor is primarily focused on TCP-based traffic and does not provide native support for routing UDP traffic so i2p is the only way forward since the neroshop DHT is based on the UDP protocol. Also, I believe i2p is a much more suitable option when it comes to DHT networks, torrenting, etc.

i2pd and i2psam are already bundled with the code as submodules and can be built into static libraries. However, neither is currently being utilized due to a lack of API documentation and understanding of the i2p network ☹️ .

Update: As of https://github.com/layters/testshop/pull/270 , the entire i2pd router has been embedded within the neroshop daemon so now there is no need to download, install or run an external router.

i2pd vs i2psam

1. libi2pd allows us to embed a router in an application (in this case, the neroshop daemon) so an external one is not required and it provides the SAMv3 API server.

2. i2psam gives us socket-like abstractions of I2P connections, using the API server provided by an external router

Either library can be used, though i2pd is preferred.

Additional Information

The neroshop DHT node uses two separate UDP sockets for communication - one for listening to and responding to requests via the Node::run() function and the other is a temporary socket that is used for sending queries to other nodes in the network via the Node::send_query() function. I want to know how I can route both the inbound and outbound traffic of the Node using i2p.

• You will most likely be using i2p's SAMv3 API
• You may rewrite node.cpp or create a "node2.cpp" if you have to!
• The neroshop daemon should start the i2pd router the moment it starts up or detect whether the Java i2p or i2pd is already running in the background.
• node IDs (i2p address + port) can be hashed with sha3_256.
• Change any public IP address to an i2p address
• Datagrams containing requests (query) should be "Repliable" while datagrams containing responses (response) and errors (error) can be "Raw"
• Sam sessions can be observed at http://127.0.0.1:7070/?page=sam_sessions when testing while i2pd is active and running.
• Prioritize permanent b32.i2p addresses over transient ones as it makes it easier to find certain peers in case they temporarily go offline.

Related links

neroshop networking code: https://github.com/larteyoh/testshop/blob/main/src/core/protocol/p2p/node.cpp https://github.com/larteyoh/testshop/blob/main/src/daemon/main.cpp https://github.com/layters/testshop/blob/main/src/core/network/i2p.cpp

libi2pd: https://github.com/PurpleI2P/i2pd

i2psam: https://github.com/i2p/i2psam

Official i2p docs: https://geti2p.net/en/docs/applications/embedding https://geti2p.net/en/docs/api/samv3

Related projects https://github.com/monero-project/monero-gui/pull/4263

Examples

https://github.com/i2p/i2psam?tab=readme-ov-file#example

Related issues

https://github.com/larteyoh/testshop/issues/124 https://github.com/larteyoh/testshop/issues/228

Bounty reward 

$2500 USD (via crypto)

[preland]

I can work on this- I think this will be a good way for me to get more familiar with how SAM works before I begin implementing it in monerod/monero-gui

[layters]

Thanks for being the first person to volunteer to work on this issue! I appreciate it. The orignal i2pd developer was suggesting here that I should "Create destinations and send datagrams directly from your code" rather than use the SAM API since I link i2pd libs directly to the app. I'm not sure which approach would be the best though.

If you do manage to compile neroshop, you can test/play around with the network on localhost just to see how messages are sent, what kind of messages are sent, and how nodes communicate with their peers. I have written some instructions here.

Anyways, If you have any questions, let me know.

[preland]

The question of yes SAM or no SAM really comes down to one question: should neroshop support using an external instance of i2p? (As in if someone is already running i2pd or another router)

If no, then using SAM wouldn’t really be necessary, as you wouldn’t have to worry about protocol portability.

If yes, then SAM would be the best option (for why, you can see idk’s CCS proposal for what I’m working on, where he describes the benefits of SAM: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/454)

[preland]

You mentioned directly linking i2pd libs inside the app; that would likely make SAM unnecessary

[layters]

Currently, the neroshop daemon checks whether an external i2pd router is already running in the background and uses that one otherwise it starts its own internal i2pd router. This would make SAM necessary.

So what do you think, should we go with SAM?

[layters]

Honestly, I only care that users won't have to manually install or run i2pd. I want them connected to i2p as soon as they start the neroshop client. Not using SAM/Creating destinations and sending datagrams directly from the code seems more reasonable but at the same time, I also want to support users running an external i2p or i2pd router. Plus, you mentioned that you want to get more familiar with how SAM works so that you could implement it in monero. With that saying, I think we have already come to a conclusion. SAM it is.

[preland]

Ok, I think I understand it better now.

It should be noted that i2pd is not the only router used, so just checking for i2pd wouldn’t be enough.

That in my opinion would be the best argument for using SAM: it doesn’t matter what router is used, it would be able to see and connect to it all the same.