some very early notes on bridge families

svn:r12645

1 files changed, 47 insertions, 0 deletions

diff --git a/proposals/128-bridge-families.txt b/proposals/128-bridge-families.txt
new file mode 100644
index 0000000..a602644
--- /dev/null
+++ b/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.
+
+