Re: invitation to directory server operators

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----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-----