I2P Support Meta-issue

[ignopeverell]

A close integration between Grin and I2P is desirable for the following reasons:

1. It supports NAT traversal allowing nodes behind a router to participate in the network as much as a one on the public internet (related: NAT traversal support #1205).
2. Generally improves privacy with garlic routing.
3. Provides a network address that can be used to reach a wallet. Corresponding communication is encrypted and signed (related: #2523).
4. For donations and wanted known endpoints, provides DNS-like aliasing.

To support I2P in Grin several things need to happen:

• Dust off i2p-rs.
• Add support in i2p-rs for server socket accept and reusable addresses (keys).
• Initial I2P setup support in Grin (config, creating and saving keys, etc).
• Support for I2P in our p2p crate: server listen, client connect, i2p network addresses.
• Support for I2P in the wallet: listener and HTTP tunneling to exchange slates.
• (Optional) I2P embedded distribution if deemed desirable.

[ignopeverell]

i2p-rs fork with the fixes and improvements is here: https://github.com/ignopeverell/i2p-rs

[DavidBurkett]

It looks like i2p-rs is just a client for interacting with the i2p router. Are we planning on requiring users to manually connect to i2p? Or are we going to take on the challenge of embedding the router, too?

[ignopeverell]

See my last bullet point :-) I still prefer interactions with i2p with a client API and leaving it in its own process for security reasons.

[DavidBurkett]

Yep, I'm not so good with the words, and the reading 😆. Btw, I'm making changes to i2pd to make it easier to embed into Grin++. By the time i2p-rs is ready, it'll hopefully be trivial to optionally include my i2pd library, if desired.

[lehnberg]

Very very nice.

Provides a network address that can be used to reach a wallet. Corresponding communication is encrypted and signed

This requires both wallets to be online synchronously, correct?

[DavidBurkett]

Yes, that's correct. It's similar to using an IP address or domain name, only you're using it on a fancier network.

[ignopeverell]

Correct, I2P doesn't change any of that. And people could still host a grinbox behind I2P as an encrypted file store reusing your destination pubkey so it's all nicely wrapped up.

[lehnberg]

Yup, at a quick glance it seems well suited for support on the base protocol layer. And could kill a lot of birds in one stone. I've never used i2p and only briefly researched it prior. I'm curious about reliability/performance. Going to try to play around with it.

[0xmichalis]

I still prefer interactions with i2p with a client API and leaving it in its own process for security reasons.

+1

@ignopeverell do you have any thoughts on packaging? Are you going to include an i2p router as part of the grin release process?

[0xb100d]

saw this not too long ago, i2p in rust
https://github.com/str4d/ire

[garyyu]

@ignopeverell
to avoid pollute your "progress update thread", I prefer to discuss here :-)

About:

you get a network address for free out of it something like cuss2sgthm5wfipnnztrjdvtaczb22hnmr2ohnaqqqz3jf6ubf3a.b32.i2p but you can go vanity as well). So you become reachable from any other node, and that should include your wallet. So if all goes well, Grin could have addresses. Not addresses on the blockchain, but addresses to receive coins in a secure and private way.

Q1: Is cuss2sgthm5wfipnnztrjdvtaczb22hnmr2ohnaqqqz3jf6ubf3a.b32.i2p accessible from outside (none i2p client)?

Q2: About "and that should include your wallet. " but @yeastplume split out the wallet from v1.1.0, then, do we need keep wallet in the grin repo? or copy the same i2p code into splited wallet?

[DavidBurkett]

Q1: Is cuss2sgthm5wfipnnztrjdvtaczb22hnmr2ohnaqqqz3jf6ubf3a.b32.i2p accessible from outside (none i2p client)?

No, not directly. It's possible for folks to set up some kind of forwarding service, but if enough of these go down, the network fragments. I assume the goal will be to actually require the entire p2p network to move to i2p. I'm very interested to hear Igno's plan for transitioning (maybe during hardfork?).

Q2: About "and that should include your wallet. " but @yeastplume split out the wallet from v1.1.0, then, do we need keep wallet in the grin repo? or copy the same i2p code into splited wallet?

The i2p code is in a separate repo (https://github.com/ignopeverell/i2p-rs). Both grin and grin-wallet can just consume the APIs from that. If done correctly, very little of the i2p implementation should leak into either of the grin projects.

[Giszmo]

What are the advantages of I2P over TOR? Reading the above, it looks to me as if TOR would fit equally well for all the points made.

[chisa0a]

@ignopeverell I updated, and opened a new PR for your initial I2P work. Removed the rebase onto 1.1.0, and completed a large amount of the remaining work for connections over I2P.

Please review the changes when you have a moment.

[chisa0a]

@Giszmo Tor and I2P have a number of design differences, and privacy trade-offs. Tor is exclusively over TCP, I2P has support for TCP- and UDP-based transports. Tor has a centralized set of routing servers (directory servers), I2P uses a fully decentralized DHT (NetDB) for routing lookups.

Tor is an excellent overlay network, and a critical piece of privacy infrastructure. I2P happens to shine in a number of places where Tor falls short / makes different design choices.