mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-12-01 08:03:31 +01:00
48 lines
1.6 KiB
Plaintext
48 lines
1.6 KiB
Plaintext
Filename: 128-bridge-families.txt
|
|
Title: Families of private bridges
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Roger Dingledine
|
|
Created: 2007-12-xx
|
|
Status: Draft
|
|
|
|
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.
|
|
|
|
|