readme stuff

README.md

@@ -1,6 +1,62 @@
 # eeProxy
 Yet another standalone, contextual-identity aware proxy for i2p. This time
-better organized and smaller.
+better organized and smaller. It is unfinished. An accounting of the extant
+issues follows.
 
-Hey I wrote that in like, a night. Probably expose some bugs in tunconf in the
-morning, but way quicker than last time, huh.
+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.