From: Steven Murdoch Date: Mon, 15 Mar 2010 17:50:50 +0000 (+0000) Subject: Integrate more feedback from IRC X-Git-Tag: tor-0.2.3.1-alpha~340 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ac552473501c8c56f0b6a653528ca0879bb20bdd;p=thirdparty%2Ftor.git Integrate more feedback from IRC - For now we are only talking about moving clients to be bridges - Some questions on how we should inform users --- diff --git a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt index 05d65ce156..8563b47547 100644 --- a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt +++ b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt @@ -14,6 +14,11 @@ Target: preferences. The proposal also defines the new controller messages and options which will control this process. + Note that for the moment, only transitions between client and + bridge are being considered. Transitions to public relay will + be considered at a future date, but will use the same + infrastructure for measuring capacity and reliability. + 2. Motivation and history Tor has a growing user-base and one of the major impediments to the @@ -108,3 +113,11 @@ Target: - Perhaps the bridge authority should tell potential bridges whether to enable themselves, by taking into account whether their IP address is blocked + + - How do we explain the possible risks of running a bridge/relay + * Use of bandwidth/congestion + * Publication of IP address + * Blocking from IRC (even for non-exit relays) + + - What feedback should we give to bridge relays, to encourage then + e.g. number of recent users (what about reserve bridges)?