Removed I2P ticket info because it belongs in a trac ticket

diff --git a/docs/anonymity-configuration.rst b/docs/anonymity-configuration.rst
index e5a113b842e37142082d0c2c7d2e9100864e0c0c..dddfe02f8ccb5c4232ca90c3eb7309cbcb86383c 100644 (file)
--- 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 2e2a78667f6deb940dd046cc47fb82e3ea89badc..f99033d5b411cf6deea85cfa2c04d01cb0f7bfe4 100644 (file)
--- 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