some very early notes on bridge families

svn:r12645

doc/spec/proposals/000-index.txt

@@ -48,8 +48,9 @@ Proposals by number:
 123  Naming authorities automatically create bindings [OPEN]
 124  Blocking resistant TLS certificate usage [ACCEPTED]
 125  Behavior for bridge users, bridge relays, and bridge authorities [OPEN]
-126  Getting GeoIP data and publishing usage summaries [NEEDS-RESEARCH]
+126  Getting GeoIP data and publishing usage summaries [OPEN]
 127  Relaying dirport requests to Tor download site [NEEDS-RESEARCH]
+128  Families of private bridges [NEEDS-RESEARCH]
 
 
 Proposals by status:
@@ -65,13 +66,14 @@ Proposals by status:
    121  Hidden Service Authentication
    123  Naming authorities automatically create bindings
    125  Behavior for bridge users, bridge relays, and bridge authorities
+   126  Getting GeoIP data and publishing usage summaries
  ACCEPTED:
    105  Version negotiation for the Tor protocol
    124  Blocking resistant TLS certificate usage
  NEEDS-RESEARCH:
    118  Advertising multiple ORPorts at once
-   126  Getting GeoIP data and publishing usage summaries
    127  Relaying dirport requests to Tor download site
+   128  Families of private bridges
  META:
    000  Index of Tor Proposals
    001  The Tor Proposal Process

doc/spec/proposals/126-geoip-reporting.txt

@@ -64,7 +64,7 @@ Status: Open
   http://www.maxmind.com/app/geolitecountry
 
   The maxmind GeoLite City database gives more finegrained detail like
-  as geo coordinates and city name. Vidalia currently makes use of this
+  geo coordinates and city name. Vidalia currently makes use of this
   information. On the other hand it's 16MB compressed. A typical line is:
     206.124.149.146,Bellevue,WA,US,47.6051,-122.1134
   http://www.maxmind.com/app/geolitecity
@@ -225,6 +225,7 @@ Status: Open
 6.1. Other interfaces
 
   Robert Hogan has also suggested a
+
     GETINFO relays-by-country/cn
 
   as well as torrc options for ExitCountryCodes, EntryCountryCodes,

doc/spec/proposals/128-bridge-families.txt

@@ -0,0 +1,47 @@
+Filename: 128-bridge-families.txt
+Title: Families of private bridges
+Version: $Revision$
+Last-Modified: $Date$
+Author: Roger Dingledine
+Created: 2007-12-xx
+Status: Needs-Research
+
+1. Overview
+
+  Proposal 125 introduced the basic notion of how bridge authorities,
+  bridge relays, and bridge users should behave. But it doesn't get into
+  the various mechanisms of how to distribute bridge relay addresses to
+  bridge users.
+
+  One of the mechanisms we have in mind is called 'families of bridges'.
+  If a bridge user knows about only one private bridge, and that bridge
+  shuts off for the night or gets a new dynamic IP address, the bridge
+  user is out of luck and needs to re-bootstrap manually or wait and
+  hope it comes back. On the other hand, if the bridge user knows about
+  a family of bridges, then as long as one of those bridges is still
+  reachable his Tor client can automatically  learn about where the
+  other bridges have gone.
+
+  So in this design, a single volunteer could run multiple coordinated
+  bridges, or a group of volunteers could each run a bridge. We abstract
+  out the details of how these volunteers find each other and decide to
+  set up a family.
+
+
+somebody needs to run a bridge authority
+
+it needs to have a torrc option to publish networkstatuses of its bridges
+
+it should also do reachability testing just of those bridges
+
+people ask for the bridge networkstatus by asking for a url that
+contains a password. (it's safe to do this because of begin_dir.)
+
+so the bridge users need to know a) a password, and b) a bridge
+authority line.
+
+the bridge users need to know the bridge authority line.
+
+the bridge authority needs to know the password.
+
+