-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all,
the quoting approach doesn't work here any more, so that I try to address the main questions directly; if I should have overlooked something important, please let me know: One question was why we didn't announce the feature of configuring a node as v2 hidden service directories (HSDir in the folling) earlier: This feature was introduced in one of the alphas of the 0.2.0.x series. Back then I asked some people I knew to configure their node as HSDir to have a number of 3--6 HSDirs as a basis to get it running. Unfortunately, there was a major bug in one of the alphas (I don't recall if it was in the HSDir code or not, but anyway, it's fixed long ago, so no worries). The result was that the one of the more high-bandwidth nodes crashed and the node administrator downgraded to 0.1.2.x. At that time I refrained from asking more people to be beta testers before being more sure that it works more stable. Now that the HSDir code runs for quite some time without making trouble, I would say it is stable; which doesn't rule out the possibility of bugs completely, though. It was also on my TODO list to make an announcement, but not on top position, so that Scott got ahead of me with his announcement. It wasn't urgent, though, because the v0 directory is still running in parallel. Scott asked whether enough people turned on this option now: Not if we want the distributed directory be as stable and reliable as it was planned in its design. It is really awesome that so many people followed the announcement here, but we need as many HSDirs as possible. The concept depends on distributing descriptors among hundreds of nodes in the long term. This is required for higher reliability in face of single failing and corrupt nodes. Plus, it even gains more importance for hidden services with client authorization (see proposal 121) where you have separate hidden service descriptors for different clients that should not be linked together. With only a few HSDirs we need to rely on delaying descriptor publication for different descriptors from the same hidden service going to the same HSDir. With hundreds of HSDirs we can make this significantly faster. But this whole thing is not even completely implemented in trunk, so give us some time before announcing it here. (See proposal 121 for more details if you are interested in that.) Andrew found out that it is not required to open the DirPort in addition to setting the HSDir configuration. While this could on the one hand be considered a bug, it shows on the other hand that this requirement is really redundant and can be dropped. Originally, this requirement stems from a time when it was not clear that we can tunnel directory requests over the OR port. This works by extending a circuit to the OR port of a relay and sending a so-called BEGIN_DIR cell that contains a directory request and can be answered directly instead of a command to open a connection to another server or something like that. Then there was a question why nodes need to have an uptime of 24 hours or more: As was discussed earlier on this list, this is a means to ensure high availability of HSDirs. If one looks at the number of nodes over time and removes nodes with lower uptime than 24 hours, one gets a very smooth graph with low variations. Unfortunately this excludes people on daily disconnected DSL lines. Sorry for that, but if we want a reliable distributed hidden service directory, we really need reliable nodes that don't change their IP address. Hidden service clients shall be able to find a hidden service descriptor even when it was published a few hours ago. Finally, there were some questions about legal issues when configuring a relay as hidden service directory. I can't answer those, sorry. Please consult your lawyer, or turn off this option. We will add a remark in the sample torrc (and maybe other places) that this option can be turned off when 0.2.1.x goes stable (at the latest). - --Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIy6W70M+WPffBEmURAn6nAKDLAeBjtuGEFeE4erWE1Ce8CLYPPQCgl/km Adgs1qh0en59PyJ/caR1d8E= =Oz3x -----END PGP SIGNATURE-----