From: David Stainton <dstainton415@gmail.com>
Date: Fri, 5 Sep 2014 17:30:39 +0000 (+0000)
Subject: Removed I2P ticket info because it belongs in a trac ticket
X-Git-Url: https://git.rkrishnan.org/pf/status?a=commitdiff_plain;h=197310ac437a66fbbfced9ac4f92046c3a5ff248;p=tahoe-lafs%2Ftahoe-lafs.git

Removed I2P ticket info because it belongs in a trac ticket
---

diff --git a/docs/anonymity-configuration.rst b/docs/anonymity-configuration.rst
index e5a113b8..dddfe02f 100644
--- a/docs/anonymity-configuration.rst
+++ b/docs/anonymity-configuration.rst
@@ -233,7 +233,10 @@ I2p software deps here
 Configuration
 =============
 
-informative configuration info for i2p users
+informative configuration info for i2p users goes here
+
+link to tahoe trac ticket regarding client endpoint string
+parameter concatenation
 
 
 Performance and security issues of I2p (if applicable)
diff --git a/docs/anonymity-roadmap.rst b/docs/anonymity-roadmap.rst
index 2e2a7866..f99033d5 100644
--- a/docs/anonymity-roadmap.rst
+++ b/docs/anonymity-roadmap.rst
@@ -8,7 +8,7 @@ Anonymity Development Roadmap
 Development phases
 ==================
 
-1. Use Tor for network connectivity and protect identity of client
+1. Use Tor for network connectivity and to protect identity of client
 
 **note:** Client side is endpoint agnostic and server side has TCP endpoint support.
 
@@ -19,29 +19,11 @@ Development phases
  * #517
 
 
-2. Use I2p for network connectivity and protect identity of client
-
-* txi2p
-* Add "endpoint parameters" to Tahoe
-    * Servers provide the minimum client endpoint string required to connect to them:
-        * ``tcp:example.org:1337``
-        * ``ssl:example.org:443``
-        * ``i2p:longstring.b32.i2p``
-    * Clients may need to extend the strings with client-specific per-type parameters in order to successfully connect:
-        * ``tcp:example.org:1337:timeout=60``
-        * ``ssl:example.org:443:caCertsDir=/etc/ssl/certs``
-        * ``i2p:longstring.b32.i2p:tunnelNick=tahoe:inport=10000``
-    * These should be set in ``tahoe.cfg``:
-        * ``[node]clientEndpointParams = tcp:timeout=60,ssl:caCertsDir=/etc/ssl/certs,i2p:tunnelNick=tahoe:inport=10000``
-    * Tahoe parses, keeps an internal map, applies the relevant params to a client endpoint string before connecting
-* Client endpoint string whitelisting
-    * Server publishes an endpoint string for a client to connect to
-    * A malicious server could publish strings containing client-specific parameters that compromise the user
-        * Unsure what parameters could actually be used maliciously on their own, but definitely possible in concert with other attacks.
-    * The client should not accept strings that contain client-specific parameters
-        * How to tell the difference? Tahoe can't keep a list of everything that is safe.
-        * Maybe an endpoint API method that takes a client endpoint string and returns a safe one.
+2. Use I2p for network connectivity and to protect identity of client
 
+**Dependencies** ::
+ * new Tahoe-LAFS trac ticket regarding client endpoint string parameter concatenation
+ * txi2p
 
 3. endpoint-agnostic Foolscap server side