[tor-project] Intent to Minimise Effort: Fallback Directory Mirrors
teor2345 at gmail.com
Fri Aug 25 02:27:35 UTC 2017
Fallback directory mirrors help Tor clients find the tor network, and
take load off Tor directory authorities. 
Since Tor 0.2.8, I've generated a fallback directory mirror list
every 6 months or so. I'd like to minimise the amount of effort I put
into this in future. (But I think it's valuable, so I won't abandon it.)
I'm happy to spend half a day every 6 months to update the input lists
and run automated checks on a bunch of relays . But contacting relay
operators to agree to go on the list (opt-in), or check their relay
details, is a time-consuming process.
Here's what you can do to help:
* We ask relay operators to opt-in. We could ask them to opt-out (contact
us to be taken off the list) instead. The opt-in list hasn't been updated
for about a year, so we will have to switch to opt-outs soon to get
enough good fallbacks.
- If we do opt-ins, who is going to contact relay operators?
- If we do opt-outs, how do we make sure operators know they can opt-out?
- (And how do we make sure we get stable relays?)
* I wrote down the opt-in process in . Maybe it's too complicated.
- Can you design a better process?
* If you're good at mail merges or scripting mail, that's one way we could
contact a bunch of relay operators without it being time-consuming and
- Can you do mail merges? (I can't!)
* We can improve the fallback script to make it easier to use.
(See  and .)
- Can you write python?
If anyone wants to help out with any of these things, let me know.
I'm going to do a fallback directory mirror refresh some time in the
next few weeks. About 12% of fallbacks have failed, and it looks like
this is placing extra load on the directory authorities. 
There's already a ticket for it , and I'm happy to do a minimal refresh.
If we don't get 150 fallbacks from a minimal refresh, I'll switch to opt-out
and see how that goes.
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP
More information about the tor-project