eeProxy

Yet another standalone, contextual-identity aware proxy for i2p. This time better organized and smaller. It is unfinished. An accounting of the extant issues follows.

Why this is/will be better than si-i2p-plugin

Much, much smaller. I expect this will never rise to more than 2000 or so lines of code, and that's a pretty roomy estimate. Right now it can do everything si-i2p-plugin can(given a workaround due to an extant bug I'm going to fix after I write this), one additional thing(See below), and is just ~600 lines of code compared to ~7000 lines of code for si-i2p-plugin. A static executable is about ~5MB for eeProxy and takes seconds to build. A static executable of si-i2p-plugin is about ~9MB for si-i2p-plugin and takes a couple extra seconds to build.

Below: Persistent, per-site destinations are on-by default. This means that every site will see a different destination, but those sites will see the same destination(and thus the same identity for you) until the keys for that site are no longer present in the configuration directory. Don't just delete them though, handling that is a thing that's not quite ready yet. If you need a new identity for an eepSite, then stop eeProxy, delete the associated config file, and restart eeProxy. The reason this works is because of the next thing.

Per-site tunnel prebuilding: Tunnel building is expensive, and the overhead of si-i2p-plugin is largely down to this. My laptop is from 2006 and it seems acceptable, but no reason not to try something that might be better. So the persistent per-site destinations obviously have to store the keys across site visits, that's one middlingly expensive bit that only has to be done once per identity. The other thing it does is pre-builds tunnels for the identities that you've already generated. That makes subsequent uses of eeProxy with the same identities slightly faster. But in order to do all this properly it needs to do at least two other things:

Tor-like isolation and a control interface. Applications should be able to tell it to create a new identity tree for them, at this creation time, they will optionally be allowed to use other's shared tunnels, but not by default and only if they have chosen to share them, which is also not the default. The use of this feature isn't going to be encouraged, but it might be convenient for some highly planned setups.

Sane defaults, but offer optimization via post-configuration. si-i2p-plugin took a brute-force approach, which isolated all tunnels and tore them down forever after a short inactivity period. With eeProxy, the sites start out with a very conservative set of proxy settings, but can be configured after the fact so that they use new settings during the next pre-build. This makes it possible to optimize tunnels generated by eeProxy but makes the configuration files very sensitive information. Frankly they were already though.

And lastly, it will also need to be hooked up to a slightly more complicated http proxy than I had originally thought. When you visit a new site you'll be presented with probably 2-4 options before proceeding:

    New Site Configuration Page:
    [*] - Pre-Build tunnels for this eePite(Default on)
    *[] - Use shared tunnels for this eepSite if available*
    *[] - Accept address helper from $site*
        (Proceed) (Generate new ID and proceed to destination)
    [ ] - Show/Hide Advanced Client Tunnel Options

All of this ranges from 0-75% done at this point.