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
+Why this is/will be better than si-i2p-plugin
-morning, but way quicker than last time, huh.
+=============================================
+
+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.

main.go

@@ -9,7 +9,8 @@ import (
 )
 
 import (
-	"github.com/eyedeekay/eeproxy/socks"
+	//"github.com/eyedeekay/eeproxy/socks"
+    "./socks"
 	"github.com/eyedeekay/sam-forwarder/config"
 )
 

socks/manager.go

@@ -21,7 +21,7 @@ type Manager struct {
 	*sam3.SAM
 	listen  net.Listener
 	server  *socks5.Server
-	conns   []*conn.Conn
+	conns   []conn.Conn
 	datadir string
 	host    string
 	port    string
@@ -47,6 +47,17 @@ func (m Manager) Serve() error {
 	return nil
 }
 
+func (m *Manager) generateConnection(addr string) error {
+    log.Println("Creating a new connection in connection tree.", m.datadir)
+	newconn, err := conn.NewConn(*m.SAM, addr, m.datadir, m.samopts)
+	if err != nil {
+		return err
+	}
+	m.conns = append(m.conns, newconn)
+    log.Println("Connection created.")
+    return nil
+}
+
 func (m *Manager) DialI2P(ctx context.Context, addr string) (*sam3.SAMConn, error) {
 	i2paddr, err := sam3.NewI2PAddrFromString(addr)
 	if err != nil {
@@ -58,12 +69,10 @@ func (m *Manager) DialI2P(ctx context.Context, addr string) (*sam3.SAMConn, erro
 			return c.SAMConn, nil
 		}
 	}
-	log.Println("Creating a new connection in connection tree.", m.datadir)
+    err = m.generateConnection(addr)
-	newconn, err := conn.NewConn(*m.SAM, addr, m.datadir, m.samopts)
+    if err != nil {
-	if err != nil {
 		return nil, err
 	}
-	m.conns = append(m.conns, &newconn)
 	log.Println("Generated destination for address:", i2paddr.Base32(), "at position", len(m.conns)-1)
 	return m.conns[len(m.conns)-1].SAMConn, nil
 }