On Tue, Sep 18, 2007 at 03:06:53AM -0500, Scott Bennett wrote: > Does anyone have a sense of the current processing delay in registering > a server? I ask only because I sent off the registration information to > [EMAIL PROTECTED] last Thursday evening, 13 Sept., and my server is still > showing up in the status documents without the "Named" flag in them. > It's not a big deal; I'm just curious. Processing of flight instructor > certificate renewals is now said to take more than six months, and the > certificates have to be renewed every 24 months. (Your tax dollars at work, > of course. :-)
Alas, we've pretty much stopped assigning the Named flag to servers. This is because it's a time-sink to manually go through and make sure the server is actually acting correctly, go put the keys in the right place, etc. There have been some proposals to make it easier, e.g. https://tor.eff.org/svn/trunk/doc/spec/proposals/113-fast-authority-interface.txt and at some point we should do one of them. See also the discussion under http://archives.seul.org/or/dev/Apr-2007/msg00040.html I'm a fan of solution #2 in the above url: there's no reason why a human needs to be in the loop, and if we don't know the operator on the other end, the "Named" flag doesn't mean what it meant in 2003 when we created it anyway. Once upon a time (2003 era), you needed to be manually approved or you wouldn't be able to join the network. The primary reason was that we needed to verify that your server was reachable, working, etc. Then we got more than a dozen servers, including servers run by people we didn't know, and we automated the process of testing reachability at the directory authorities. Then we started to allow unnamed servers to join the network and play pretty much the same role. The only main difference at this point is from the client perspective: if you manually specify a non-named server in your torrc or using the foo.exit syntax, your Tor will complain to you (well, to your logs) and suggest a hex digest that you should use instead. Now, there is an argument for letting people remember nicknames rather than hex digests. But I would eventually like to see some sort of graphical "server picking" interface that most users would use, and it would be smart enough to know the hex digest of the picked server. If, that is, we need any sort of server picking to be happening at all -- most users I hear from who need to specify a specific server rather than just let Tor pick for them seem to be doing it to get around crude access controls on websites or other services, and I'm not sure that's an arms race I want to get into. There are other problems that need to be solved from a usability angle. For example, if the nickname Alice picks is already registered, then when she tries to sign up her server, it will print a mysterious message in her logs ("there are logs? what's a log?") and her server won't be useful. We need to make that simpler somehow, and the simplest approach for now (by default) is to not have many Named servers. My preferred solution would be to add an "Unnamed" flag that servers get when they're using a nickname that is already registered -- the server will continue to be a fine server, but it will be invisible from the perspective of referring to servers by nickname. And lastly, one of the crucial reasons for maintaining contact with server operators is so they feel appreciated, and so we have an opportunity to answer their questions, address their concerns and problems, etc. Maintaining communication with the server community helps it to grow and be stable. We are doing a poor job at that currently. A few years ago I realized that I could choose between answering a whole lot more mail (and having the number of good Tor servers keep going up) and getting more development work done on Tor. Since Tor is nowhere close to done, the latter was the clear choice -- as long as there is *some* sort of Tor network, that's good enough for testing the new scalability/anonymity/performance features and bugfixes. Peter Palfrader then stepped up to answer mail for a while, but he soon found it to be a flood too. My fix at the time was to modify https://tor.eff.org/docs/tor-doc-server#email to make it clearer that we may not ever answer the mails. Maybe I should make the statement even stronger, or just erase 'step four' entirely, until somebody sorts out proposal 113 and implements and deploys a good solution. I don't think getting a pile of volunteers to answer the mails is the right answer -- we should instead a) work to take out the artificial bottleneck (help appreciated! :), and b) figure out better ways to build server operator community that don't involve as much manual attention from me (help appreciated! :). Thanks, --Roger