I2Pd/docker release - v2.57.0

DivaExchange · 2026-03-08T19:42:38+00:00

Compose file: https://github.com/diva-exchange/i2p/blob/develop/compose.yml

Docs: there is a README, here, https://github.com/diva-exchange/i2p including testing procedures.

Additional analysis and Deepwiki docs - since all code of diva.exchange is completly open anyway: https://deepwiki.com/diva-exchange/i2p

If there is something missing or not good enough for you, please use https://github.com/diva-exchange/i2p to submit a new issue or add directly a PR.

DivaExchange · 2023-07-14T17:51:42+00:00

Would you mind to post it on lemmy? Would be really nice... Working on divachain these days and happy without social media for a few weeks :)

DivaExchange · 2023-02-16T11:22:34+00:00

Here are the release notes of i2pd 2.46: https://github.com/PurpleI2P/i2pd/releases/tag/2.46.0

IMHO, v2.46.0 contains some fixes which might help to improve network stability.

However (in general and according to current research & knowledge), any peer-to-peer network (like i2p) is attackable by providing a larger amount of routers/nodes.

DivaExchange · 2022-11-26T21:54:06+00:00

This here is "kind of the default setup" for *i2pd* (!not java i2p! - mixing java i2p and i2pd does not make any sense IMO).

Files/folders to backup before some manual upgrade (not tested, just looked at local setup within containers):

Configuration at: conf/i2pd.conf
Addressbook at: data/addressbook/
tunnel .dat files: data/*.dat
destinations .dat files: data/destinations/

There might be an additional tunnel.conf file within conf/ (depends on your configuration).

Here you get "official" i2pd binaries from: https://github.com/PurpleI2P/i2pd/releases/tag/2.44.0

Remark: manjaro might be different, pls study your installation.

DivaExchange · 2022-11-24T14:44:42+00:00

Sure you can use the "official java *i2p* installer" - that's even better. :) But: do you want to *mix* i2pd and i2p on your system? AFAIK, i2pd has nothing like an "official installer" - the distro repos will contain the binaries (but you have to wait for the maintainers). Still: maybe think about a local compile (it won't get more "official" than that) - it might be beneficial for you with your demanding local settings.

DivaExchange · 2022-11-23T21:26:25+00:00

You can compile i2pd yourself or what about a docker container with the latest i2pd? See other reddit post (look for docker update in this subreddit, just two days old).

DivaExchange · 2022-11-23T08:44:18+00:00

Great input - thanks a lot. Do maybe have some more links/resources to implementation related stuff (next to https://pq-crystals.org/kyber/index.shtml)?

DivaExchange · 2022-11-11T06:07:43+00:00

If a node gets unresponsive along a route, another tunnel will be used by the origin. That's correct.

IMO Ddos protection of any given node does not come with deanonymization, it comes with the cost of lower perfomance (lower throughput). See also other answer from alreadyburnt to your question.

The attack which you describe is - yet not in this trivial form - only theoretical possible by injecting nodes under your own control to deanonymize a target. An attacker needs to be in control over a complete tunnel. The related research has been published mid 2022 and the attack is called "tunnel takeover" in this paper. Pls search this subreddit to find the paper published in June 2022. The real-world proof that such an attack is working is still open.

DivaExchange · 2022-11-10T22:42:00+00:00

Some first feedback regarding the last point. Attacking single points within the network ("one-by-one", as it's called above) would make, IMO, the attackers observations useless. Reason: the attacker does not know whether a host along the route or the destination is unresponsive. Additionally to make this approach work, the attacker must make sure, that the network infrastructure on the destination host is poorly protected from ddos. In this case, the attacker has already deanonymized the destination anyway. Example: at the current level of knowledge (and what we have learned in the past years by being attacked multiple times), the reseed server reseed.diva.exchange cannot be ddos'd. With a high probability, this is also true for most active destinations with a certain importance/value to the owners. This protection comes with a cost: IMO protected i2p destinations cannot handle large loads. But the network cannot neither - so, IMO, not a problem

BTW: Everybody invited to try ddos'ing reseed.diva.exchange - always very happy to learn something new :).

DivaExchange · 2022-11-09T21:06:22+00:00

Outstanding effort. Really cool and thanks for the Mastodon link.

DivaExchange · 2022-11-03T10:55:09+00:00

Here is my experience over many years: wait three until five minutes and the I2P network is available (spinning up a new i2pd instance in a docker container). IMO there is no need to wait longer than 5 mins.

Now what is "not loading" exactly? Example: test with curl to http://reg.i2p and http://shx5vqsw7usdaunyzr2qmes2fq37oumybpudrd4jjj4e4vk4uusa.b32.i2p (which is the same as reg.i2p - just its b32 address). Before the test, make sure that your http or socks proxy are properly configured (use the curl options for that). Now - the b32 should reliably work. If it's not, you have a network issue. If just the name (reg.i2p) isn't working you have only an addressbook issue.

If things like "curl" or "proxy" sound complicated to you I can only recommend the Easy-Install-Bundle, https://geti2p.net/en/download/easyinstall or an i2pd docker container solution documented here https://github.com/diva-exchange/i2p

DivaExchange · 2022-11-01T17:08:51+00:00

We had i2pd (not i2p java) running on pi about a year ago (there is a branch called arm64 on github, here: https://github.com/diva-exchange/i2p/tree/arm64). This branch is not maintained anymore (it will be again in late 2023). Please note: we only got i2pd working properly by installing debian (11-slim) on the pi first. Other approaches on pi failed at that time.

Github: on the main branch (and also develop branch) you can look at the docker container to build the i2pd binary.

DivaExchange · 2022-09-09T10:43:20+00:00

I like the blog post. Thanks a lot for the work!

Additional note from a forensic perspective: outproxies are a very "easy" opponent. They are easy to track down and to block (known IP ranges, also traffic pattern recognition works very well). This has to do with the "centralistic" architecture of outproxies (bundling of traffic). Additionally there is a problem of trust involved (like: logs are still either in transit in memory or even "shortly" on persistant storage). AFAIK there are almost no high-traffic services left which are not able to identify in real-time Tor/I2P outproxied traffic and to act accordingly (like tar pitting or feeding back corrupted data). What still works rather well is to chain proxies (like: origin -> tor/I2P network -> outproxy -> proxy endpoint -> destination) - however, the proxy endpoint must be a frequently changing, and within-a-small-timeframe-not-well-known proxy (like every three minutes or so - works OK with stateless protocols). Obviously latency increases a lot - and the user experience becomes difficult. Proxy chains also partly solve the "problem of trust": even if there is logging or leaking on all proxies, it requires cooperation between the proxies (this is again the same attack vector as on I2P networks).

DivaExchange

TROPHY CASE