62 lines
3.5 KiB
Markdown
62 lines
3.5 KiB
Markdown
# 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.
|