aboutsummaryrefslogtreecommitdiff
path: root/doc/spec/proposals/128-bridge-families.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/spec/proposals/128-bridge-families.txt')
-rw-r--r--doc/spec/proposals/128-bridge-families.txt64
1 files changed, 0 insertions, 64 deletions
diff --git a/doc/spec/proposals/128-bridge-families.txt b/doc/spec/proposals/128-bridge-families.txt
deleted file mode 100644
index e5bdcf95c..000000000
--- a/doc/spec/proposals/128-bridge-families.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-Filename: 128-bridge-families.txt
-Title: Families of private bridges
-Author: Roger Dingledine
-Created: 2007-12-xx
-Status: Dead
-
-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.
-
-2. Other notes.
-
- 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.
-
-3. Current state
-
- I implemented a BridgePassword config option. Bridge authorities
- should set it, and users who want to use those bridge authorities
- should set it.
-
- Now there is a new directory URL "/tor/networkstatus-bridges" that
- directory mirrors serve if BridgeAuthoritativeDir is set and it's a
- begin_dir connection. It looks for the header
- Authorization: Basic %s
- where %s is the base-64 bridge password.
-
- I never got around to teaching clients how to set the header though,
- so it may or may not, and may or may not do what we ultimate want.
-
- I've marked this proposal dead; it really never should have left the
- ideas/ directory. Somebody should pick it up sometime and finish the
- design and implementation.
-