u/Far_Cartographer_924

This version fixes five major issues with i2pbox, significantly improving reliability. I originally planned to rewrite it in Rust, but it's clear that some protocols would need to be reimplemented (the Rust version of the i2p router is still incomplete), which is risky. Therefore, I've decided to continue writing it in C++. Thanks to llm for his help. The code is open source, and issues and pull requests are welcome.

Based on the recommendations of i2pd developers and my own understanding of the source code, i2p outproxies are insecure; the connections used to access the clearnet via an outproxy are fundamentally different from those used to access internal i2p services.

i2pbox is a lightweight command-line toolbox for working with I2P identities, destinations, RouterInfo files, router families, and related network utilities.

It combines common I2P maintenance tasks into a single portable binary, including key generation and inspection, Base64 destination conversion,address registration, router family signing and verification, vanity address generation, and offline key handling.

The project is intended for I2P users, router operators, and developers who need practical command-line tools without installing a large application stack.

Source code and releases:

https://github.com/iasds/i2pbox

Current development progress / not indicative of final status

Hi everyone, I’m working on BlueI2P.

Java I2P is friendly for new users and has a complete web console, but it can feel slow and heavy. i2pd is fast, lightweight, and powerful, but its configuration can be harder for new users.

BlueI2P tries to bring these two worlds closer together: an i2pd-based I2P router with a new Java I2P-style web dashboard.

The goal is to make i2pd easier to configure, monitor, and use, while keeping the router lightweight and performant.

The dashboard includes router status, services, tunnels, peers, NetDB, logs, configuration pages, and safer management APIs.

It is still early, but I’ll share more as it becomes usable.

https://preview.redd.it/hednbwu891bh1.png?width=690&format=png&auto=webp&s=2f2f47654083dff87308c9fede07f5a1b966fbbb

Over June 29–July 1, 2026, I ran five i2pd floodfill instances from three vantage points (Poland, China Unicom ×2) and passively scanned the I2P DHT. Found 20,701 unique routers globally. Among them, 58 routers from mainland China stood out in ways that don't look random.

What makes this cluster unusual:

43× enrichment on version 0.9.66 — 79.3% of the CN cluster runs this exact version, vs. only 1.8% globally. A single version shouldn't dominate any organic router population this heavily.

Floodfill flags everywhere, zero participation — 27–36% declare floodfill capability (vs. 14–20% global baseline), yet none were ever observed functioning as floodfills by our instances. The flags are declared, not honored.

82.8% share a near-identical RouterCaps template (XfR/XRG pattern) — looks like copy-paste provisioning.

- 46.2% hosted on Alibaba Cloud (AS37963). No knownRouters entries, no family declarations, ongoing IP rotation.

Four routers are China-vantage-only — reachable from inside the GFW, but unreachable from Singapore and Tor exit nodes. TCP RST/timeout behavior consistent with selective path filtering. These nodes simply don't exist from outside China.

We're careful with language: we describe this as consistent with coordinated, template-based provisioning — not as attribution to any specific actor. We don't know who runs these, or why. But the data is the data.

Methodological note — we parse the binary RouterInfo at two distinct caps layers (AddressCaps per transport vs. global RouterCaps). Prior I2P measurement papers didn't disentangle this, and it matters when you're trying to distinguish what a router says it can do from what it actually does.

Preprint (open access): 10.5281/zenodo.21169969 (https://doi.org/10.5281/zenodo.21169969)

Scanner source (MIT): github.com/iasds/i2p-network-scanner

Independent researcher working on an I2P censorship measurement paper (English). Have some preliminary findings and an analysis framework in place. Looking to go deeper before submitting to arXiv.

Seeking collaborators for:

- Longitudinal tracking — baseline data collected, need ongoing observation for trend analysis

- Node reverse engineering — behavioral patterns identified, want to confirm technical details

- Protocol verification — TCP-level results done, want to add deeper handshake validation

Non-profit project, no funding. Co-authorship (2nd/3rd) based on contribution.

Interested? Reach me via PGP-encrypted email with your GitHub profile and a brief intro:

iasds.github.io

PGP: 1A60 9235 A475 39DF 6C4C C09B 822A 6DA9 E3BD 0612

Hey everyone,

I packaged all i2pd-tools (https://github.com/PurpleI2P/i2pd-tools) into a single binary. Instead of building and managing 14 separate executables, you get one:

All original tools work as subcommands: keygen, keyinfo, vain, famtool, su3tool, i2pconv, regaddr, etc.

BSD 3-Clause licensed, builds from source with a single make. The original i2pd-tools repo is included as a submodule — all credit goes to the PurpleI2P team.

GitHub: https://github.com/iasds/i2pbox

This post contains content not supported on old Reddit. Click here to view the full post