[or-cvs] some more thoughts on scope; probably should not get into t...

[arma@xxxxxxxx (Roger Dingledine)]

Update of /home2/or/cvsroot/tor/doc/design-paper
In directory moria.mit.edu:/home2/arma/work/onion/cvs/tor/doc/design-paper

Modified Files:
	challenges.tex 
Log Message:
some more thoughts on scope; probably should not get into the final
paper as-is. ok, i'm done for now.


Index: challenges.tex
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/design-paper/challenges.tex,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- challenges.tex	26 Jan 2005 11:09:57 -0000	1.10
+++ challenges.tex	26 Jan 2005 12:49:34 -0000	1.11
@@ -273,7 +273,16 @@
 \subsection{Other}
 
 Tor's scope: How much should Tor aim to do? Applications that leak
-data. We can say they're not our problem, but they're somebody's problem.
+data: we can say they're not our problem, but they're somebody's problem.
+Also, the more widely deployed Tor becomes, the more people who need a
+deployed overlay network tell us they'd like to use us if only we added
+the following more features. For example, Blossom \cite{blossom} and
+random community wireless projects both want source-routable overlay
+networks for their own purposes. Fortunately, our modular design separates
+routing from node discovery; so we could implement Morphmix in Tor just
+by implementing the Morphmix-specific node discovery and path selection
+pieces. On the other hand, we could easily get distracted building a
+general-purpose overlay library, and we're only a few developers.
 
 Should we allow revocation of anonymity if a threshold of
 servers want to?