I2P Service is online.

Welcome to our site I2P protocol users.

In a similar vein to Tor; I2P (Invisible Internet Project) is another style of encrypted network designed to communicate between machines in a private and anonymous way. It was originally brought to our attention via the many sites within the webring folders that as many of them are running their webpage on raspberry pi's they too are also running their site with Tor and I2P protocols enabled. It was high time we got our shit together and did it too!

If you want to know more about I2P as a client you can always go to https://geti2p.net/ and go from there.

If interested in my own diatribes: Read on if you want to hear me ramble about our experiences with this.

Geez S, you already have Tor which is an anonymous way of accessing your site. Why do you need ANOTHER anonymous proxy service?!? - Anonymous

Reasoning.

If you type in my address into the clear-net https://www.s-config.com; It bounces off of ICANN to resolve the DNS (which we pay for) and then it gets certified by a Digi-cert (We know of certbot, but we pay for this too.) and finally, my web-hosting is all done through AnubianHost. Right, because all of these commercial systems that are absolutely required to make my website run are in a country run by a government. That particular government can completely fly off of its hinges and either shut me down. Or, blacklist my site altogether. One of the basic concepts of information technology one learns is not only backing up your data. But offer some level of redundancy in accessing your data. Because if your SSL expires or simply fucks off. if ICANN fails to do its job. You, a website owner are completely bitched at that level!

So, by offering alternative protocols. (First, it was Tor/Onion networks. Now I2P) it allows the end-user to try other channels to reach sites like ours so even if our government loses its shit. Or even a remote government decided to lose their shit and block all DNSs. Or, if we get incredibly drunk and forget to renew our SSL. People aren't completely shit out of luck.

What does it do and how well does it do it?

The mantra of everything we review on our site. We have to start off with probably the most annoying aspect of this software:

Usage:

From a client-side POV. Tor has gotten to the point where it has been integrated into browsers such as Brave. It didn't involve you really changing the core of your browser for anything crazy. In fact, in later browsers, Tor sits quietly in the background and you can use your clear-net browser like normal. Alternatively, you can turn on Tor and use its anonymizing powers to look at clear-net sites.

I2P doesn't roll like that.

This will probably be the number one reason why your average user won't be using the I2P protocol. Unless there's something we're missing in the instructions you have to dedicate a browser for I2P functionality. This is a major drawback of this service because once this is done and you type in a Clearnet address you can't really use I2P to mask yourself as one would do with Tor.

Now, we understand that I2P is still very beta. The people using the protocol are people who are aware of this. Unless your Grandma is a SecOp expert that attends Def-Con and has her custom Linux distro all prepped on her cyberdeck. there's a pretty good chance the average person on the internet like your grandparents will not be using this.

Client Installation.

From the client side, they've gotten better with the installation aspect by making i2p easy bundle on their website But the concept of using Java just to initiate a protocol is a little bit excessive.

One of the problems with IFP's Easy Bundle Installation for windows is that it puts the java application into your %userprofile%/appdata/local/i2p folder. Putting executables into your AppData folder is suspect as fuck.

 

So much in fact that if you have a virus checker then it's probably going to flag I2P.exe for its overall suspicious activities for playing with the network and for existing in such a bizarre folder.

Service/Nginx VPS Installation.

The service installation for our VPS however was REALLY annoying!

When we were looking for instructions to set up I2P (specifically i2pd which is a C++ build of i2p so we don't have to load 250+MB of java) we encountered a lot of instructions that were highly distro dependent and based on the usage of a user on a shell instead of legit running I2P as an active service so web admins such as us can "fire and forget" the service as it were.

for example, one site just says:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install i2pd

No, not really. This is bad.

The Debian repo doesn't even point to the certs for i2pd to startup properly.

I had to do this.

sudo wget -q -O - https://repo.i2pd.xyz/.help/add_repo | sudo bash -s -
sudo apt-get update 
sudo apt-get upgrade
sudo apt-get install apt-transport-https
sudo apt-get install i2pd

The certs to at the very least launch the program.

Now that it's installed another site said to simply do this to get i2pd.

useradd -m i2p -s /bin/bash
su -l i2p
mkdir ~/.i2pd
cd ~/.i2pd

This was completely wrong for a VPS service Debian environment. Great if your end-user is on someone else's VPS or you wish to isolate it down to an individual user. But not really what we were going for here.

There's no need to make an i2p user. Because during installation it makes a user i2pd and then links all of its core data to /var/lib/i2pd/ as between that directory and /etc/i2pd this is what /etc/init.d/i2pd uses.

Next was the tunnels.conf file in the /etc/i2pd/ folder.

[website]
type = http
host = 127.0.0.1
port = 8080
keys = website.dat

This part is perfectly fine. because you're routing traffic from I2P to go to an internalized port on Nginx to port 8080.

The problem is if you had tunnels.conf AND tunnels.conf.d the init service only wants to use the tunnels.conf.d directory and that it!

So we had to modify my service /etc/init.d/i2pd:

 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --chuid "$USER" -- \
--service --daemon --log=file --logfile=$LOGFILE --conf=$I2PCONF --tunconf=$TUNCONF \

removing any mention of the tunnels.conf.d

Now, instead of launching an IRC proxy and whatever other bullshit i2pd was doing. When we lynx 127.0.0.1:7070 to check my I2P tunnels it's finally following my tunnels.conf file in /etc/i2pd instead of some random shit that was added automatically in the tunnels.conf.d folder.

finally adding a new site to Nginx which is in /etc/nginx/sites-available/i2p:

server {
     listen 127.0.0.1:8080 ;
     root /var/www/example ;
     index index.html ;
}

Because you are telling the I2P service what to do with incoming tunnel traffic and to route it to port 8080 earlier you just have to map port 8080 in Nginx's folder. Now, my Nginx configuration is sadly not as simple as the example above. Because we have the WordPress CMS and an extensive blocklist for Tor and I2P preventing accessing things like admin tools and in general trying to be cute. Also for those browsers interested to listen cache controls are setup in my Nginx profile too.

We suppose the real thing about this is the daemon routes the port locally. While our firewall blocks port 8080 externally. The downside to this is because we have WordPress we had to deploy a lot of hooks to re-route traffic as we would be unable to tell the difference between a base32 I2P address or a vanity I2P address coming into our VPS.

always check your Nginx before restarting the service.

Nginx -t

Saved me a lot of down time doing this simple command.

Tuning.

For the next section, we want to make things transparent about our settings.

in our i2pd.conf file:

bandwidth = X
share = 100
floodfill = true

Bandwidth = X means instead of the default parameter of "L" that limits to 32KB/sec that "X" means unlimited (Other documentation talked about it being 10MB/sec) As this is a VPS we're using we have all the speed in the world with gigabit fiber going to the box. So it's a giant whatever to me. If it were our home connection we might set it to "P" at 2MB/sec. but whatever.

 

The same goes for the client side of my firefox browser. As mentioned before. There are a lot of settings about I2P is built where the average user will not set. the reason why I2P has a router menu, to begin with, is you can do more than just HTTP over it and it allows you to tunnel said protocols across this network. But right now we're just using plain-ole HTTP surfing on this bad boy.

Finally, in response to some things we read on forums; We let the I2P daemon run for 24 hours prior to this test just to make things fair and to allow the system to replicate itself throughout the network properly to get a fair speed assessment.

Speed-Test

Please note that this is not in any way a scientific speed test review. These are just observations.

 

Starting off with Google Chrome Canary we load our site because it's a beta edition of the site that loads JXL images for the entire server. The total download is around 724Kb and the transfer is completed in just over half a second. No there is no way a distributed network can achieve this as this was a point-to-point connection. But just wanted to serve as a reference for all of this.

Next up, we turned on Tor onion addressing and looking at our site. despite Jquery not being rolled into our auto-optimize script resulting in higher requests. only 372Kb were transferred because of the AVIF encoding Brave chose as its default imaging. with a finish time of about 8 seconds.

Tor for Firefox was roughly the same. Even though the payload was higher the browser (rightfully) rejected a bunch of scripts as a result came out to around 8-9 seconds too. Slow, but then again these are a bunch of small files. When running some of the videos on my site Tor can 'Barely' keep up.

Wow, okay. Firefox preloaded with I2P had a different payload because it grabbed the WebP images of my website resulting in a 579Kb payload but it took a whopping 32.21 seconds to load each time! I even disabled the cache and reloaded it a few times just to make sure that it was not a glitch in the distributed network. But no. This is very normal for I2Ps. I've even visited other I2P sites out there and experienced similar times. The payload-to-time ratio is that of a 56k baud modem of the dial-up years.

Unless we have grossly misconfigured something on our VPS (or the I2P client. Hey! This is all new to us.)  I2P would not be able to do some of the more complex things on our site like video blogging and it almost took a solid minute with NoScript turned off to get audio testing to play. They'd have to right-click and download the video and wait a really long time to receive said video before the end-user could even watch it. Now, if you're hosting a minimalist website the load times aren't really going to be a big issue. but for someone like us who has a fair amount of background graphics(eye-candy bloat to some.), this could be a problem.

Trying it yourself.

Now, for those who do not believe me (and you REALLY shouldn't), you can try it out for yourself.

https://geti2p.net/en/download - You can download the standalone version of this software for windows if you guys want to dive right on in and not have to set up gateways on your browser. And also find out more about the I2P project.

HTTP://atlkfvuwwpgvnw24dkwyyxf5psrueozxb3i6zgebymjuquuquvqq.b32.i2p

Similar to Tor. This is the base32 code of my site within the cool vanity IP address. We tend to prefer base32 addresses more with I2P because every time we typed in an actual website we were greeted with another page that the site was not in our address book and we had to reference one of these sites to pull it into our personal address book.

http://reg.i2p/hosts.txt
http://identiguy.i2p/hosts.txt
http://stats.i2p/cgi-bin/newhosts.txt
http://i2p-projekt.i2p/hosts.txt

It's understood that DNS over a private network is a new thing. So these annoyances are bound to happen. If you however prefer to use our vanity I2P address then it is as follows:

HTTP://s-config.i2p

 

Final thoughts.

Like Tor, there's really nothing stopping someone from building a bunch of random ass base32 I2P addresses or cybersquatting a shit-ton of DNS names on the current listing of servers and effectively running some bitcoin marketing Ponzi scheme or promoting CP like what happened in the article in the past. But from the very notion of this protocol where they wish to be privacy free, that's sort of the risk you take when joining networks such as these. That is unlike the ICANN/Digi-Cert world where a spammer isn't very likely to pay for a Digi-cert to a bogus website just for them to make a few dollars in bitcoin. But instead, would prefer things like Tor/I2P where they can batch script several thousand sites together to only sit back and take everyone's donation money.

It's good that other protocols are being made in the event of a collapse of Tor and we recognize that the I2P protocol is a bit of the new kid on the block. At least it isn't based around some shitty cryptocurrency-like forever domains.

Also, for those who are running a website with zero dollars. and are rocking some university PC or even a Raspberry Pi that runs in some closet. adding I2P as a way of reaching out to new readers is certainly a viable alternative to Tor. As the mainstream internet constricts and becomes more censorship oriented it's almost necessary for protocols like this to exist.

Until next time. That's what the server said.

END OF LINE+++