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

I2P Natively Supported #240

Closed
mandamu5 opened this Issue Feb 27, 2016 · 12 comments

Comments

Projects
None yet
8 participants
@mandamu5

mandamu5 commented Feb 27, 2016

Brief Description: Support for I2P natively

Operating System (OS and version): Linux / Windows / OS X / *nix
OpenBazaar version: -current

Due to the limitations of Tor, and its (let's be honest) being a haven of malfeasance, the alternative of I2P (which robustly supports UDP and addresses DHT limitations by design -- one of its intended use cases to support pseudonymous Bittorrent clients) should be explored.

More than a cursory glance at I2P will reveal a small but significant skilled and motivated base of programmers in the I2P community who have provided many working implementations of software (as a thread on the Subreddit at /I2P/ mentioned recently, on the topic of OpenBazaar, that I2P devs have themselves built many working implementations of software like Zeronet, Bittorrent, Vuze, et cetera. The common thread, for all, has been that the I2P development community is so niche that these programs often become stale and lose development interest because the end up as a "proof of concept" and the initial project creators don't put forth any substantial efforts to supporting the community.

For those concerned about exposing their IP addresses, and simply having a rather MINIMAL expectation of some privacy, have you thought about supporting I2P? I understand the mantra "just use a VPN," but VPNs fail open, thus revealing the user's IP adress, without her taking great strides to ensure they close their internet connection if the VPN connection hiccups.

Moreover, many would prefer to run OpenBazaar-Server on their own hardware as opposed to trusting a VPS to manage it. This is just obviously overhead for many who want (such as myself, and I KNOW others) a rather straightforward use case to do three things simultaneously:
(i) provide my own resources to the OB community (not those from a "cloud provider" or a VPS)
(ii) Not risk exposing my IP address to the world
(iii) Be treated as the LAW-ABIDING merchant that I am

OpenBazaar is not, by design, a good fit for Tor. I2P solves all the problems inherent to the OB design and I think that by OB supporting it natively, the problem that's been seen in other projects where I2P developers have had to take the reigns out of the gates, it's been shown that support wanes and then just dies as the native projects themselves continue unabated. Please show some regard for those who don't want their IP exposed to the world and value their privacy to do so.

@cpacia

This comment has been minimized.

Show comment
Hide comment
@cpacia

cpacia Feb 27, 2016

Member

I would be OK with using I2P though I have very little experience with it. I'd welcome contributions from people who know what they're doing in that regard.

Member

cpacia commented Feb 27, 2016

I would be OK with using I2P though I have very little experience with it. I'd welcome contributions from people who know what they're doing in that regard.

@drwasho

This comment has been minimized.

Show comment
Hide comment
@drwasho

drwasho Feb 28, 2016

Member

Would definitely welcome and consider PRs that would integrate I2P into OpenBazaar.

Member

drwasho commented Feb 28, 2016

Would definitely welcome and consider PRs that would integrate I2P into OpenBazaar.

@leethax666

This comment has been minimized.

Show comment
Hide comment
@leethax666

leethax666 Feb 28, 2016

Contributor

I2P doesn't use outproxies, so the network would have to be separate. That might actually be safer in the long run. Just have a "private browsing" switch in the client.

Contributor

leethax666 commented Feb 28, 2016

I2P doesn't use outproxies, so the network would have to be separate. That might actually be safer in the long run. Just have a "private browsing" switch in the client.

@hoffmabc

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Feb 28, 2016

Member

Yes both i2p and Tor would be separate networks. A hybrid approach would not work.

Member

hoffmabc commented Feb 28, 2016

Yes both i2p and Tor would be separate networks. A hybrid approach would not work.

@drwasho drwasho added the suggestion label Mar 1, 2016

@drwasho drwasho added this to the Future version milestone Mar 1, 2016

This was referenced Mar 1, 2016

@papermate

This comment has been minimized.

Show comment
Hide comment
@papermate

papermate Mar 1, 2016

I was working in this days on outproxying the OB connection through I2P.
It is not that easy, at least for me, while the communication between client and server pass without too many troubles through I2P tunnels.

The change could be made without too much of an effort if using onioncat on top of it, so that instead of a b32 (the basic identity used in I2P) you may have a ipv6 to identify the node, which of course would not be the real one.
The seeder and all the rest of the network must be on the network overlay too to use this solution.

I don't see any reason not to set it as default and only network. Right now OB does not protect the less tech-savy, and is forcing anyone to buy a VPN or looking for other means of protection by design, which adds a layer of complexity for the end user.
I2P not only protects the identity but also adds layers of encryption to the communication. If you think SSL/TLS is good, this is better.

There are ways to do it, and while still in testing it won't take too long, but the more the network grows the more difficult it will be to implement such an upgrade in a flawless and simple way.

A couple of weeks of delay in the project looks like a good tradeoff for really coming out with a full working, protected and "battery included" software.
Separating the users from the start in more subnetwork seems to me like a godd way to kill the usability of OB.

If I can be of some help in testing or anything please let me know, I'm not a programmer but I'd be glad to help.

papermate commented Mar 1, 2016

I was working in this days on outproxying the OB connection through I2P.
It is not that easy, at least for me, while the communication between client and server pass without too many troubles through I2P tunnels.

The change could be made without too much of an effort if using onioncat on top of it, so that instead of a b32 (the basic identity used in I2P) you may have a ipv6 to identify the node, which of course would not be the real one.
The seeder and all the rest of the network must be on the network overlay too to use this solution.

I don't see any reason not to set it as default and only network. Right now OB does not protect the less tech-savy, and is forcing anyone to buy a VPN or looking for other means of protection by design, which adds a layer of complexity for the end user.
I2P not only protects the identity but also adds layers of encryption to the communication. If you think SSL/TLS is good, this is better.

There are ways to do it, and while still in testing it won't take too long, but the more the network grows the more difficult it will be to implement such an upgrade in a flawless and simple way.

A couple of weeks of delay in the project looks like a good tradeoff for really coming out with a full working, protected and "battery included" software.
Separating the users from the start in more subnetwork seems to me like a godd way to kill the usability of OB.

If I can be of some help in testing or anything please let me know, I'm not a programmer but I'd be glad to help.

@hoffmabc

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Mar 1, 2016

Member

If not already can you please visit the Slack so we can discuss this further in more detail.

Member

hoffmabc commented Mar 1, 2016

If not already can you please visit the Slack so we can discuss this further in more detail.

@papermate

This comment has been minimized.

Show comment
Hide comment
@papermate

papermate Mar 1, 2016

I joined the slack and:

  • Slackbot keeps disagreeing with Pidgin on IRC saying I didn't give him a password. I'll side with Pidgin though, password is there. It succeded in making me lose 40 minutes looking for problems though.
  • Been in Welcome-room since 3 hours and well, no answers about anything
  • It uses a huge mass of client side scripts, it managed to freak out my browser again and again
  • Why not here?
  • Why closed source/proprietary?

papermate commented Mar 1, 2016

I joined the slack and:

  • Slackbot keeps disagreeing with Pidgin on IRC saying I didn't give him a password. I'll side with Pidgin though, password is there. It succeded in making me lose 40 minutes looking for problems though.
  • Been in Welcome-room since 3 hours and well, no answers about anything
  • It uses a huge mass of client side scripts, it managed to freak out my browser again and again
  • Why not here?
  • Why closed source/proprietary?
@str4d

This comment has been minimized.

Show comment
Hide comment
@str4d

str4d Mar 1, 2016

Hi! I'm one of the developers of I2P. I agree with the OP that having something like OpenBazaar get I2P support would be really neat! I'm posting here so you know I am happy to answer questions :)

I haven't yet grepped the source and don't know anything about how your existing backend works, but in case it is useful, there are currently two Python libraries for I2P (both backed by the SAMv3 API):

  • txi2p: provides Twisted endpoints (only supports TCP because that is all Twisted supports).
  • i2p.socket: a drop-in replacement for the regular socket that adds AF_I2P for trivial I2P support.

str4d commented Mar 1, 2016

Hi! I'm one of the developers of I2P. I agree with the OP that having something like OpenBazaar get I2P support would be really neat! I'm posting here so you know I am happy to answer questions :)

I haven't yet grepped the source and don't know anything about how your existing backend works, but in case it is useful, there are currently two Python libraries for I2P (both backed by the SAMv3 API):

  • txi2p: provides Twisted endpoints (only supports TCP because that is all Twisted supports).
  • i2p.socket: a drop-in replacement for the regular socket that adds AF_I2P for trivial I2P support.
@cpacia

This comment has been minimized.

Show comment
Hide comment
@cpacia

cpacia Mar 1, 2016

Member

The txi2p looks interesting. Doesn't look too difficult to use.

Member

cpacia commented Mar 1, 2016

The txi2p looks interesting. Doesn't look too difficult to use.

@ABISprotocol

This comment has been minimized.

Show comment
Hide comment
@ABISprotocol

ABISprotocol Mar 5, 2016

Technical question, I'm assuming this is a "just I2P" natively supported approach, but if someone was running I2P with Foxyproxy, like this, (and assuming you had txi2p integrated into OB) this would work also to connect to OB?

ABISprotocol commented Mar 5, 2016

Technical question, I'm assuming this is a "just I2P" natively supported approach, but if someone was running I2P with Foxyproxy, like this, (and assuming you had txi2p integrated into OB) this would work also to connect to OB?

@papermate

This comment has been minimized.

Show comment
Hide comment
@papermate

papermate Mar 6, 2016

What use case do you mean?
Like, you are on OB and someone else is on the I2P network you want OB to opportunistically switch to a I2P connection?
In that case I think the best solution would be to integrate in the client interface a PAC, so you don't need any plugin or stuff. Still, the best solution would be to integrate everything into I2P, so let's hope it will not be needed ;)

papermate commented Mar 6, 2016

What use case do you mean?
Like, you are on OB and someone else is on the I2P network you want OB to opportunistically switch to a I2P connection?
In that case I think the best solution would be to integrate in the client interface a PAC, so you don't need any plugin or stuff. Still, the best solution would be to integrate everything into I2P, so let's hope it will not be needed ;)

@drwasho drwasho removed the suggestion label Apr 20, 2016

@drwasho drwasho removed this from the Future version milestone Apr 20, 2016

@drwasho

This comment has been minimized.

Show comment
Hide comment
@drwasho

drwasho Apr 20, 2016

Member

Issue closed and merged into #362

Member

drwasho commented Apr 20, 2016

Issue closed and merged into #362

@drwasho drwasho closed this Apr 20, 2016

@DonaldTsang DonaldTsang referenced this issue Jun 24, 2018

Open

TOR/I2P support #127

0 of 7 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment