publishing your eepsite
Why publish your content or services on the Invisible Internet Project (I2P) network? Doing so offers your users a strongly authenticated, private route to access your site.
Your users are guaranteed to either connect to your server or fail to connect at all. The benefits of I2P's addressing scheme, routing protocol, and avoidance of DNS means there are no man-in-the-middle (MITM) attacks, no DNS cache poisoning, no significant tracking of users, and no censorship.
general eepsite considerations
What type of site are you publishing? Sites with lots of dynamic services, or lots of external content are going to need careful planning and strategic alternatives. We'll discuss those a bit more later.
Javascript
A general rule of thumb that you should follow is to avoid, or at least minimize the use of JavaScript. AI is frequently used to create sites that are entirely dependent upon Javascript. If you have an existing site that can be described this way, it will require considerable re-architecting. Users might enable Javascript and use your site anyway, but many will wisely choose to go elsewhere.
optimized images, external content
A lesser talked about strategic imperative is to use optimized, self-hosted images throughout. Optimization is recomended to mitigate the additional network latency resulting from the additional "hops" that each packet takes to reach its destination; every extra hop takes time.
External analytics are not going to work either. Check your server logs if you care about traffic, or write your own parser to generate reports about it.
hyperlinks
Use relative links instead of absolute links. Users may access your site through proxies and have different base URLs. If you don't know the difference, it simply means using URLs like
<a href="/img/logo.png" ....> or
<a href="img/header.jpg" ....>
instead of using the full URLs of the form protocol://host/path/filename
i2p+ router
We will be using the i2pd router running on common linux distributions in our examples, but let's briefly talk about using the i2p+ router. The principle difference as relates to eepsite publishing is that i2p+ router comes bundled with a webserver called Jetty. This makes hosting static websites super easy. Without going into detail, here are the basic steps.
First, click on the "free website" icon and read the instruction page there. The process is a simple, form-driven process where you will paste in your base64 identifier and choose a shortname. For details, see the i2p project's guide to setting up an eepsite.
i2pd router
You'll need to use your preferred webserver as i2pd does not come with a bunch of applications bundled in. This makes it a better choice for most sites, since it is far less demanding in terms of resource requirements. It is written in C++ and is available in repositories for most distros.
For a dynamic website, you'll want to run it behind a reverse proxy using Nginx, Caddy, or similar. This setup also allows you to easily serve up multiple eepsites, alongside clearnet sites. But first, let's get the i2p daemon setup.
create http tunnel
To create a tunnel, you can simply add a section to your tunnels.conf configuration file, which is located either in /var/lib/i2pd/, or in /etc/i2pd/. However, best practise, especially for multiple sites, is to create individual files in the /var/lib/i2pd/tunnels.d/ directory - one per site, so you isolate the configuration for each eepsite.
Each section of a config file begins with the name for your eepsite in square brackets; here we are being unimaginative and calling our sites eepsite1 and eepsite2.
You will probably want to keep the next two lines as is, to indicate you're using HTTP protocol and localhost (127.0.0.1). The type line indicates protocol obviously, and the host, along with port indicates where to forward requests to. If you're running a dynamic website, you'll likely be using a port other than the default port 80, and you'll know this port number already.
The next line is important: keys = filename.dat points to a private key which is unique to your website, is created by the i2p router, and should be backed up. Since it is generated for you, it won't exist at this point, just use the same name as your site moniker so it's easy to remember. Note that you can use your own, for example if you generated a "vanity: base-32 domain using the vain program.
In our second example, we indicate the length, in hops, of our inbound and outbound tunnels. All traffic in and out of the router use tunnels, and 3 hops is the default. This offers the strongest security for the same reason Tor circuits use 3 hops; so that none of the nodes can know both the source and destination for a given request.
If you choose a tunnel length of 1 (default is 3) as in our example, you are weakening security in order to reduce network latency. Specifying only one hop means your server is easier to locate. This tradeoff might be worthwhile, depending on your situation. For example, if you are serving both a clearnet and I2P version of a website then you may care more about response times than keeping the server location anonymous.
webserver setup
Restart or reload i2pd so it will pick up your new tunnel configuration. In our example, our system uses systemd, so we can restart it with:
sudo systemctl restart i2pd.service
Navigate to your server control panel at http://127.0.0.1:7070. use lynx text browser so you can easily copy and paste. You want to navigate to the 'i2p tunnels' section and find your new http tunnel(s). That long string is your .b32.i2p address - copy it to the paste buffer.
In my case, I have these two:
http://qpjfzxjv3bkgbxoz4nr7kin6upjj6wqp226ivqr5ujb3hkoyuwza.b32.i2p
http://w7nrpgha4pkglddc47kinasepfd426u6ocg6av2t6tejy3ak4kuq.b32.i2p
Use whatever webserver you're comfortable with, we're going to use Caddy to demonstrate. In the Caddyfile, we want one of these blocks for each eepsite; do the same thing for Nginx but adjust the syntax.
Be sure you're mapping the domain to 127.0.0.1 and if needed, the appropriate port. Now restart your webserver and check the website(s) you just setup. You should be able to load your eepsite using it's .b32.i2p address:
registration
To make it easier for people to find your eepsite, consider registering a second-level domain (sitename.i2p) with the popular listing sites or "registries". These are not like ICANN registries in the DNS system, so we'll call them listing sites to avoid confusion.
These listing sites allow you add your site with a second level .i2p domain. Two popular sites are reg.i2p and stats.i2p, so let's discuss registering with them.
Using i2pd you'll need to use a utility like regaddr from https://github.com/PurpleI2P/i2pd-tools. i2pd-tools has a number of useful tools for eepsites, including regaddr, the one we'll use today which lets you register your shortname.i2p domain with the common sites like reg.i2p and stats.i2p. You might also be interested in regaddr_3ld, which lets you register a subdomain, and regaddralias which as the name suggests, lets you register an alias to an existing domain.
We need to use regaddr to generate a string to give reg.i2p and stats.i2p to "register" our short .i2p domain. The syntax is:
./regaddr domain.dat domain.i2p
where domain.dat is your private key and domain.i2p is the shortname you wish to register. You might want to look it up first to make sure it's not taken.
Go to the "add" page on reg.i2p or stats.i2p and paste this string in to the form. stats.i2p waits to review the site for compliance with their rules and to ensure its availability.
Meanwhile, check the "latest" page on reg.i2p to find your newly added domain. They are listed in chronological order. You should see several different links:
On the left is the link to your shortname, followed by A and B. "A" is an "addresshandler link", which will add the shortname to your addressbook. This is nice to use when linking to your site so people can find the site and also add the shortname. "B" is the base32 domain which goes directly to your site.
Also consider publishing your domain to I2P name registry. You'll need only the base64 string, and a working site that meets their requirements; read the FAQ.
tying up loose ends
Don't forget to add your new short domain to webserver config, in our case /etc/caddy/Caddyfile as a second name for that same item, so your webserver will respond to requests for the memorable name.
If you're running an application firewall (WAF) you need to ensure that it never blocks 127.0.0.1.
Back up your keys! The eepsite.dat file in /var/lib/i2pd is your website's private key. If you lose it, you lose your address. Copy it somewhere safe.
Finally, when linking to your eepsite, try to avoid using the shortname.i2p version because many users will not be able to use it. Instead, you can use the base32 link, knowing that it can be resolved. The downside is that the site does not get associated to your shortname, so you may choose instead to use
http://shortname.i2p?i2paddresshelper=base64
substituting your shortname and base-64 string.
optional bonus: using dynamic links
On more complex sites, you might want to use Javascript to rewrite your asset links if the user is accessing the site via I2P. Here is some pseudo-code to give you the idea:
function clearnetOrI2p() {
if (window.location.hostname.split(".").pop().toLowerCase() != "i2p"){
/* do the usual */
return;
}
// create I2P link/asset instead
s = document.createElement('script');
s.setAttribute('src', 'http://verylongbase32domain.b32.i2p/resource.js');
s.addEventListener('load',function(){ embedResource() });
document.body.appendChild(s);
}
===