toxcore
toxcore copied to clipboard
irungentoo
Add I2P backend support
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.
But there would not be a connection to "clearnet" tox.
Yes, but there will be a tox network inside I2P. It might be useful.
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.
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).
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
There's Garlicat which provides a wrapper, it emulates a network card where I2P addresses are mapped to IP addresses.
While I2P had its anonymonity broken open, Tox has worked through I2P for a year.
Since when did I2P get broken open? Are you talking about the Tails & I2P XSS flaw?
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.
@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.
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?
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"
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.
any reason you couldn't just plug tox into an I2P proxy like this https://geti2p.net/en/about/browser-config ?
@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).
@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?
@GrayHatter I don't believe so. Unlike Tor, these nodes don't have IPv4/IPv6 addresses which they could insert into the DHT.
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 [email protected] 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.
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 [email protected] 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.
The new tor hs will also not fit into ipv6 anymore
Jacob Henner [email protected] 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.
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/
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.