Start idea xxx-automatic-node-promotion

- Initial draft of overview and motivation
- Start of design

1 files changed, 96 insertions, 0 deletions

diff --git a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt
new file mode 100644
index 0000000000..2af1df62dc
--- /dev/null
+++ b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt
@@ -0,0 +1,96 @@
+Filename: xxx-automatic-node-promotion.txt
+Title: Automatically promoting Tor clients to nodes
+Author: Steven Murdoch
+Created: 12-Mar-2010
+Status: Draft
+Target:
+
+1. Overview
+
+   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
+   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.
+
+2. Motivation and history
+
+   Tor has a growing user-base and one of the major impediments to the
+   quality of service offered is the lack of network capacity. This is
+   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
+   these problems.
+ 
+   Only Tor clients which are sufficiently useful should be promoted,
+   and the process of determining usefulness should be performed
+   without reporting the existence of the client to the central
+   authorities. The criteria used for determining usefulness will be
+   in terms of bandwidth capacity and uptime, but parameters should be
+   specified in the directory consensus. State stored at the client
+   should be in no more detail than necessary, to prevent sensitive
+   information being recorded.
+
+3. Design
+
+3.x Opt-in state model
+
+   Tor can be in one of five node-promotion states:
+
+   - off (O): Currently a client, and will stay as such
+   - 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
+
+   The state can be fully controlled from the configuration file or
+   controller, but the normal state transitions are as follows:
+
+   Any state -> off: User has opted out of node promotion
+   Off -> any state: Only permitted with user consent
+
+   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*
+
+   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
+   bridge.
+
+3.x User interaction policy
+
+   There are a variety of options in how to involve the user into the
+   decision as to whether and when to perform node promotion. The
+   choice also may be different when Tor is running from Vidalia (and
+   thus can readily prompt the user for information), and standalone
+   (where Tor can only log messages, which may or may not be read).
+
+   The option requiring minimal user interaction is to automatically
+   promote nodes according to reliability, and allow the user to opt
+   out, by changing settings in the configuration file or Vidalia user
+   interface.
+
+   Alternatively, if a user interface is available, Tor could prompt
+   the user when it detects that a transition is available, and allow
+   the user to choose which of the available options to select.
+
+   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.
+
+3.x New options
+
+3.x New controller message
+
+4. Related proposals
+
+5. Open questions: