diff options
| author | Steven Murdoch <Steven.Murdoch@cl.cam.ac.uk> | 2010-03-15 00:14:41 +0000 |
|---|---|---|
| committer | Roger Dingledine <arma@torproject.org> | 2010-09-30 22:04:51 -0400 |
| commit | b112ecbcd96064ed2c4b5104e80cca0235eff876 (patch) | |
| tree | f1e97175b7cdc5fd68263be48221a2c0a9f23413 | |
| parent | 6008fcf863b253306cb59a0e169408a1028e47f3 (diff) | |
| download | tor-b112ecbcd96064ed2c4b5104e80cca0235eff876.tar.gz tor-b112ecbcd96064ed2c4b5104e80cca0235eff876.zip | |
Change "server" to "relay", so as to match existing terminology
| -rw-r--r-- | doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt index 2af1df62dc..d96861d8e2 100644 --- a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt +++ b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt @@ -9,7 +9,7 @@ Target: This proposal describes how Tor clients could determine when they have sufficient bandwidth capacity and are sufficiently reliable to - become either bridges are Tor servers. When they meet this + become either bridges or Tor relays. When they meet this criteria, they will automatically promote themselves, based on user preferences. The proposal also defines the new controller messages and options which will control this process. @@ -21,7 +21,7 @@ Target: particularly the case for bridges, because these are gradually being blocked, and thus no longer of use to people within some countries. By automatically promoting Tor clients to bridges, and - perhaps also to full public servers, this proposal aims to solve + perhaps also to full public relays, this proposal aims to solve these problems. Only Tor clients which are sufficiently useful should be promoted, @@ -43,7 +43,7 @@ Target: - auto (A): Currently a client, but will consider promotion - bridge (B): Currently a bridge, and will stay as such - auto-bridge (AB): Currently a bridge, but will consider promotion - - server (S): Currently a public server, and will stay as such + - relay (R): Currently a public relay, and will stay as such The state can be fully controlled from the configuration file or controller, but the normal state transitions are as follows: @@ -54,16 +54,16 @@ Target: Auto -> auto-bridge: Tor has detected that it is sufficiently reliable to be a *bridge* Auto -> bridge: Tor has detected that it is sufficiently reliable - to be a *server*, but the user has chosen to remain a *bridge* - Auto -> server: Tor has detected that it is sufficiently reliable - to be *server*, and will skip being a *bridge* - Auto-bridge -> server: Tor has detected that it is sufficiently - reliable to be a *server* + to be a *relay*, but the user has chosen to remain a *bridge* + Auto -> relay: Tor has detected that it is sufficiently reliable + to be *relay*, and will skip being a *bridge* + Auto-bridge -> relay: Tor has detected that it is sufficiently + reliable to be a *relay* Note that this model does not support demotion. If this is desirable, there should be some memory as to whether the previous - state was server, bridge, or auto-bridge. Otherwise the user may be - prompted to become a server, although he has opted to only be a + state was relay, bridge, or auto-bridge. Otherwise the user may be + prompted to become a relay, although he has opted to only be a bridge. 3.x User interaction policy @@ -85,7 +85,7 @@ Target: Finally, Tor could by default not make any transition, and the user would need to opt in by stating the maximum level (bridge or - server) to which the node may automatically promote itself. + relay) to which the node may automatically promote itself. 3.x New options |