# 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.
