Add I2P backend support

[suhr]

So you could make tox both secure and anonymous.

[ameenross]

I2P is far from anonymous

[suhr]

I2P is far from anonymous

Why do you think so?

[ameenross]

Sorry, must have mixed it up with freenet. In any case I2P was designed for P2P so it definitely has merit. But there would not be a connection to "clearnet" tox.

[suhr]

But there would not be a connection to "clearnet" tox.

Yes, but there will be a tox network inside I2P. It might be useful.

[ameenross]

Yes certainly

[iShift]

You can use that lib - https://github.com/orignal/i2pd/ i2p on C++

[fcore117]

Let I2P be I2P and Tox should work in own ways. I2P itself should make some general network driver interface where it is possible to connect.

[suhr]

I2P itself should make some general network driver interface where it is possible to connect.

I doubt if it's possible due to I2P have much longer addresses than even IPv6 (and linux/windows networking is not like Plan 9 one).

[iShift]

I2P itself should make some general network driver interface where it is possible to connect.

I2P work on high OSI level, is is not possible to make driver

[Natanael90]

There's Garlicat which provides a wrapper, it emulates a network card where I2P addresses are mapped to IP addresses.

[stqism]

While I2P had its anonymonity broken open, Tox has worked through I2P for a year.

[Natanael90]

Since when did I2P get broken open? Are you talking about the Tails & I2P XSS flaw?

[aaannndddyyy]

i2pd is far from stable, so using sam would be the way to do it. tox dht would have to store key hashes instead of ip:port. Then the client connects to localhost and instructs sam to open up a tunnel to the bootstrap nodes first, and later to any key hash it wants to connect to.

[suhr]

@GrayHatter Reopen please, this is still an issue.

[TheNain38]

@GrayHatter Yes, reopen please it didn't get solved

[ProMcTagonist]

Would be very cool to have Tox over I2P.

[JacobHenner]

I'd be interested in investigating this some more.

[aaannndddyyy]

@JacobHenner Do not bundle i2p, just require it as a dependency. The dht would need tweaking (dests instead of ip:port). use one of these api's: https://geti2p.net/en/docs/api/samv3 https://geti2p.net/en/docs/api/bob

I2P is a closed network, like tor hidden services, but you could allow nodes to act as bridges just like tcp node now. Would then need a bridge flag so you can find those in the DHT

Tunnels should be ephemeral. To fully make use of it, use different tunnels (that means different addresses) for DHT communication, 1:1 messenger and groupchat.

[JacobHenner]

So would it make more sense to modify toxcore, or implement this in a specific client? Also, if the user is connecting over I2P, will they also be connecting regularly, or is it expected that they will only use one or the other at a time?

[aaannndddyyy]

I don't think you could implement a new way of transport in a client. So it'd need to be in core. But changes should remain minimal and as generic as possible, so to allow easy adaption for tor and not to bloat core. As I said, the hidden services (i2p and tor) are conceived as separate networks.

So if a regular user (non hidden services) were to find his friend on an address such as jf2g5hus6gp2jfgk7zgc2cxtzeedxbstr3ju374amtoaq6p2ax6a.b32.i2p he would not know how to connect to it.

So basically, two networks. those with i2p otion enabled, send this address to the router and it connects them to their peer.

But for interconnectivity of regular users and hidden service users I suggested the "bridges"

[aaannndddyyy]

Right now, users who cannot connect via udp find a tcp relay which relays their traffic. In a similar way, a non-i2p user could find a relay node that is connected to both i2p and regular tox network and thus allow inter-network communication. But this would be the icing on the cake, in order to prevent fragmentation. For basic functionality this is not needed, only for inter-network connectivity.

[GrayHatter]

any reason you couldn't just plug tox into an I2P proxy like this https://geti2p.net/en/about/browser-config ?

[JacobHenner]

@GrayHatter I2P doesn't do "exits" like Tor does. It supports "outproxies" for HTTP sites, but only when the operators are able to do so (and unlike Tor, these proxies typically block non-get requests).

You can essentially think of I2P as only implementing Tor's "hidden services" (with some major implementation differences).

[GrayHatter]

@JacobHenner right, so if I used an I2P to bootstrap to a node, also on/in I2P. Wouldn't then I be able to connect to any other client who was also proxied'd and boot strapped to that node?

[JacobHenner]

@GrayHatter I don't believe so. Unlike Tor, these nodes don't have IPv4/IPv6 addresses which they could insert into the DHT.

[aaannndddyyy]

This is not viable for tox as it is p2p.  You could of course, proxy it, but then where do you connect to? Your router does not know your contacts' destinations. This is why sam or bob should be used. Bob is tcp-only, sam can do tcp and udp. 

Think of i2p like tor hidden services. If my tox runs on a tor hidden service but you have only my tox id not my hs address how would you connect to me ( dht part ). If you used the proxy you would still need to specify the contact's destination. 

GrayHatter notifications@github.com hat geschrieben:

any reason you couldn't just plug tox into an I2P proxy like this https://geti2p.net/en/about/browser-config ?

— Reply to this email directly or view it on GitHub.

[aaannndddyyy]

You must handle the addresses. Sam is the easiest way for this. Unless you want the user to manually set up a server tunnel under which he will be reachable.

GrayHatter notifications@github.com hat geschrieben:

@JacobHenner right, so if I used an I2P to bootstrap to a node, also on/in I2P. Wouldn't then I be able to connect to any other client who was also proxied'd and boot strapped to that node?

— Reply to this email directly or view it on GitHub.

[aaannndddyyy]

The new tor hs will also not fit into ipv6 anymore

Jacob Henner notifications@github.com hat geschrieben:

@GrayHatter I don't believe so. Unlike Tor, these nodes don't have IPv4/IPv6 addresses which they could insert into the DHT.

— Reply to this email directly or view it on GitHub.

[fcore117]

I agree that no extra bloat is needed and casual users do not use this, maybe those who want could make fork of Tox or use some workaround https://www.onioncat.org/about-onioncat/

[aaannndddyyy]

It would not have to be big changes. Garlicat is better for vpns. It is npt configuration-free. Imho it would be even more complicated if you consider user experience.  Since i2p would not be bundled it wouls be only minimal changes.

[TheNain38]

Yes, it would only support communicating to SAM using the IP and port you give (in the proxy configuration)

[aaannndddyyy]

@JacobHenner https://geti2p.net/en/get-involved/develop/applications

[JacobHenner]

@aaannndddyyy I'm on it, I'll give it a good look on Friday.

[aaannndddyyy]

@JacobHenner thank you. I hope you can come upo with a simple solution that will be robust and tiny, and will be accepted so that no fork is necesarry.

[TheNain38]

@JacobHenner thank you so much!

[JacobHenner]

Alright, so I definitely am interested in working on this. I'm going to make a branch for it, and experiment over the next few days. I'm thinking that I2P support should be enabled by a ./configure flag, linking to a C I2P library. Clients will have to add support (i.e. a config option somewhere) if they want to enable I2P use. Does this sound reasonable?

[aaannndddyyy]

@JacobHenner Why not in the settings? If you need to mod the dht for handling dests, then all clients should have that mod. If you use sam, then both, standard I2P and its imperfect C++ port can be used.

That way you are most flexible. Who has i2p already, simply ticks the "connect anonymously via i2p" setting, and others may as well created a configuration less package bundling an i2p router.

If you make a fork or only clients compiled with a certain flag have support, then there would be no interoperability between the two, as far as I can see.

[TheNain38]

It could be a new type of proxy: "I2P_PROXY" and the ip and port would be that SAM

[str4d]

Hi, (an) I2P developer here! I'm adding myself to the participant list so you all know I'm here listening, and am happy to answer questions.

@GrayHatter One reason for adding native I2P support rather than using one of the proxy tunnels is then you can use UDP directly over I2P (the SAM API supports it). Also, you get control over your own I2P Identity (Destination). Also, it's far easier for your users to set up :)

@JacobHenner There are two ways you could go about it:

1. Use one of the SAM client libraries; that gets you I2P support with minimal bundled code and it works with all I2P implementations, but it requires users to run their router themselves (not a bad thing, I2P routers do better with longer uptime).
2. Bundle i2pd and run the router yourself, which is better for usability for non-I2P-aware users but runs the risk of running two routers on one machine, and also i2pd is much newer and less mature than Java I2P.
3. You do both, and have a config option "Run router myself" which toggles between the internal router and an externally-configured one.

[aaannndddyyy]

From the perspective of a (potential) i2p user you'd ideally opt for number 3, but would start with 1. But from the perspective of the large number of users that will never use i2p, 2 and 3 might not be desired, but only 1.

In any case, I assume, that doing number one would, IMHO, be the best at this point.

@str4d If you use a proxy tunnel, the user would have to manually copy this tunnel's dest and enter it into tox so that tox can report this as its address, I guess. Am I wrong ?

[str4d]

@aaannndddyyy Yes that is the case. If you require users to use I2PTunnel manually, then you also require them to copy across the tunnel's Destination (either the full Destination or the B32) to report to others. You also can run into problems if the I2P router changes, because I2PTunnel is the place where the keys are stored, and the new I2P router wouldn't have them without getting the user to transfer across the tunnel keys.

With the SAM API (via the C library), Tox can create the Destination itself and obtain the private key (as a Base64 string), which it can then use later to create its tunnels with whatever I2P router it happens to be connected to at the time. All the user has to do is configure Tox to know where the SAM API is, and even this can be abstracted away if the router is on the same machine, because the default local ports (7656 for SAM itself, 7655 for sending UDP) are rarely changed.

[JacobHenner]

I am going to go with option one for now. I've made some changes to configure.ac to allow the (optional) inclusion of libsam3 when building toxcore, and it seems to work. I'll be examining how to go about adding I2P peers to the Tox DHT this week.

[JacobHenner]

Do Tox, i2p and Tor provide different anonymization mechanisms?

Yes. Tox is not anonymous between contacts. When communicating with another Tox user, your IP is revealed. As for Tor, Tor uses a network of relays and exit nodes, so your connection to Tox appears to be coming from the exit node. With I2P, there are no "exits". Instead, there are tunnels with destination addresses.

What about the advantages and disadvantages between Tor and i2p? What's the protocol overhead if combining Tox with one of them?

Tox can already be used with Tor. See this for instructions. To use I2P, with Tox, it's my understanding that the Tox DHT would have to be modified to support storing I2P dest addresses.

[JacobHenner]

Related: @str4d It's my current understanding that the best way to proceed would be modifying the Tox DHT so it could store I2P destination addresses generated by using SAMv3, and then using the libsam3 library to pass messages between users. Does that sound correct?

[str4d]

@JacobHenner essentially yes. You would need space to store 387+ bytes, or 516+ in B64 as-returned by SAM (see spec for details and explanation of the "+").

If you want to store them in a smaller form, you could use the B32 instead, which "looks" like a hostname (52characters.b32.i2p), so may be easier to wedge in. It is essentially the SHA-256 of the Destination. This would mean that you would first need to look up the corresponding Destination via sam3NameLookup() before connecting with sam3StreamConnect() (adding an extra delay to the connection process), and the lookup will only succeed if the remote peer is online.

So it's a tradeoff between DHT size/convenience (B32s are always 60 characters vs. Destinations potentially longer than ~530 bytes depending on signing or crypto algorithm) vs. implementation ease (no naming lookup required if Destinations are stored) and security (B32 risks a collision, although the risk is currently miniscule).

[JacobHenner]

Would it be acceptable to add another flag to the Tox DHT, to represent I2P peers? If so, I'll move forward with that plan.

[aaannndddyyy]

Wouldn't the different address scheme be indicator enough that you are dealing with an i2p peer? A flag, however, could be useful in order to mark those nodes that are reachable via both i2p and public internet, so that those could act as gateways/bridges/relays and allow cross-network communication.

[JacobHenner]

@aaannndddyyy It would, but in the DHT packets described here, it appears as if it'd be proper to assign them their own ID, rather than parse them to determine they're not actually the type of address they claim to be.

[GrayHatter]

You'd have to do both. But either way, you'd break the packed node format uses if you don't create an extra type.

[JacobHenner]

@GrayHatter Do you think it'd be acceptable to create an extra type?