Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Add support to i2p so that Tox clients can run hidden within it like RetroShare #1621

Open
Nokia808 opened this issue May 31, 2020 · 10 comments
Labels
P3 Low priority
Milestone

Comments

@Nokia808
Copy link

Hi.
Please look for this discussions:

  1. with i2pd project:
    [Question] How to set a serverless messenger/chat on i2pd ? PurpleI2P/i2pd#1521
  2. with i2pd project also:
    [Question] How to use i2p to connect "clear net server dependent" chat/messenger to it's server? PurpleI2P/i2pd#1522
  3. with qTox project:
    [Feature request] improve design of proxy support qTox/qTox#6150

Is is possible to do some thing from your side (Tox protocol project), like creating I2P nodes available 24/7 and add them to bootstrap, so that Tox client can make themselves run completely hidden within i2p network as currently RetroShare able to do so - see:
https://retroshare.readthedocs.io/en/latest/tutorial/i2p-hidden-rs-node/

Please, feel free to close this request if it is technically relevant.

Thank you.

@aaannndddyyy
Copy link

Just creating tox bootstrap nodes in i2p will not suffice.
The problem is, there are no IP's to work with, and toxcore and hence the tox DHT do not support hidden service addresses, like b32 or .onion, but this would be needed.
That said, I thik it would be a very nie feature, to have the possiblity to run your own tox instance purely as a hidden service in i2p and/or tor

@settings settings bot removed the triage label Nov 25, 2021
@iphydf iphydf added the P3 Low priority label Feb 4, 2022
@iphydf iphydf added this to the v0.3.0 milestone Feb 5, 2022
@emdee-is
Copy link

emdee-is commented Feb 4, 2024

The problem is, there are no IP's to work with, and toxcore and hence the tox DHT do not support hidden service addresses, like b32 or .onion, but this would be needed.

This may not be true of i2p, and is not true of Tor; see https://git.plastiras.org/emdee/tox_profile/wiki/AddingAnOnionService

@iphydf Do you want to open a "Tox in Tor" issue so that we can track subtasks and blockers. I think if we solve that, it may be that we can modify that to solve this.

@emdee-is
Copy link

emdee-is commented Feb 4, 2024

Just creating tox bootstrap nodes in i2p will not suffice. The problem is, there are no IP's to work with, and toxcore and hence the tox DHT do not support hidden service addresses, like b32 or .onion, but this would be needed.

"The problem is, there are no IP's to work with" is not true in Tor, and may not be true in i2p: https://git.plastiras.org/emdee/tox_profile/wiki/AddingAnOnionService

If we solve "Tox in Tor" we may be able to morph the solution to "Tox in i2p".

@iphydf Do you want to open a "Tox in Tor" issue so we can track subtasks and blockers? For example #2467 may be a blocker for testing "Tox in i2p" and "Tox in Tor"

@Green-Sky
Copy link
Member

For i2p to make sense we need an ip replacement. As part of the longer library evolution and modularization plan, this will become possible.
But for now there is now easy way to do this.
Same with proper websocket/webrtc support.

@emdee-is
Copy link

emdee-is commented Feb 4, 2024

For i2p to make sense we need an ip replacement.

I don't know what you mean by "ip replacement"

i2p runs a socks proxy to go into it on 4444, which would be like a Tor SOCKS proxy on 9050, so there's no IP replacement needed that I know of.

I just don't know the procedure for getting an IP address for a service running in i2p the way you can with Tor but I expect it;s doable.

@Green-Sky
Copy link
Member

i2p is designed to have NO exit nodes, and special ids are used to identify other i2p nodes. -> "ip replacement" and its not just a socks proxy.
One would have to explicitly setup exitnodes to connect to the clearnet, something that's equally dangerous to running a tor exitnode.

@emdee-is
Copy link

emdee-is commented Feb 6, 2024

The "exit node" would be the BSnode that you're running on the same machine anyway, that you've wired up into i2p or tor. So "running an exit node" is no more dangerous than running a BSnode. And tor or i2p just provide an alternate pathway to connect to the Bsnodes without being on the clearnet.

We need to get a few BSnodes running a hidden service to get a testbed it's easy to do #2331 (comment). Plus solving the blockers to testing TCP #2584 (comment)

@emdee-is
Copy link

emdee-is commented Feb 6, 2024

@Green-Sky can you telnet to https://nodes.tox.chat/test port 33445 over clearnet?

Can it be used as a test to see if a BSnode is visible? #1338 (comment)

I tried but it doesn't work for me.

@nurupo is that something I can use for live testing of BSnodes?
I can simply do a POST to https://nodes.tox.chat/test as a test of a node?

I can use nmap but it requires root privs.

@fcore117
Copy link

First priority still is that Tox must replace Skype as solid simple p2p communicator. Hiding is more niche thing for some, but direct connections is still nr1 to get latency free and fast communication.

@Green-Sky
Copy link
Member

Green-Sky commented Oct 12, 2024

I thought about this more, and there are multiple ways to run tox over i2p, with increasing complexity:

Method A: proxy

While I said earlier that there are no exit nodes in i2p, there are some public outproxies. But I also read that they only support HTTP and tend to filter ads/malware/other badstuff.

I tested it and i2pd could not understand the HTTP proxy protocol format toxcore speaks. (bug?!)

edit: This should be reworked. Toxcore relies too strongly on IP:PORT for tcp connections and should just pass the address string to the proxy instead, that way i2p and tor hidden services would suddenly become available.

Method B: tunnels

One can run tox relays as hidden services. However, every user needs to manually specify each hidden service as a tunnel, so it becomes available on a local port. Annoying to setup, but should just work.

Did not test.

Method C: toxcore internal network object shim

Here we hook the low level network functions like bind(), listen(), send(), and getaddrinfo() to map i2p address to virtual local ports (or ip addresses), so basically a form of NAT. With getaddrinfo() hooked, the user can provide i2p addresses. This can also automate the manual process mentioned in B. A downside is that in udp mode, exchanged ip addresses will mean nothing to the other peers.

Currently refactoring/finishing the network object code, so this can work. #2773

Method D: toxcore refactor separating messenger from netcode

This is the long way and effectively the end goal, mentioned above.
This is a big task however and unlikely to happen before 0.3.x .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 Low priority
Projects
None yet
Development

No branches or pull requests

6 participants