ArchivedWiki/roadmaps-to-be-moved-to-archived-roadmaps/Tor/HiddenServices.md

+These are some ideas for improving Tor Hidden Services:
+
+**Tor Hidden Service Circuit timeout**
+
+It is common to contact frequently a certain set of Tor Hidden Services while you may contact very sporadically others. This is particularly important in the tor2web use case.
+
+Currently Tor circuits have a timeout of 10 minutes. It would be nice to be able to set a timeout setting for tearing down a particular circuit towards a certain hidden service.
+
+There are a few ways of achieving:
+
+1) Having this feature built into Tor Tor will learn what are the most visited tor hidden services and sets a particular keep alive based on statistics collected. This factor would change over time and be always more precise (?) This is probably a bad idea as it requires having a specific purpose use feature into Tor proper (Q: Would this feature be of benefit to regular users?)
+
+2) Having this feature built into TorCtl Currently it is not possible to set the timeout of a particular circuit to a specific time. It would be nice to specify via TorCtl that a certain circuit should live for a certain amount of time. This might not be good because it requires changes to Tor, although just the TorCtl part.
+
+3) Hacking our way into making it work with current Tor It is possible to set a very big timeout (5 years?) through TorCtl for *all* circuits. You can then cycle through the circuits and understand which ones have been alive for your established timeout and kill them. This is cheap to implement and doesn't require modification of current Tor.
+
+**Multiple circuit building optimization**
+
+This mostly applies to a usecase such as tor2web where you have a lot of requests in a certain time frame. It might be a good idea to have more than one active circuit towards a certain hidden service (the top 10).
+
+By building more than one circuit towards a hidden service you are then able to collect some benchmark data with all your active circuits and determine which are the fastest ones and which are the slowest.
+
+The benchmark collection and optimization of circuits by speed could be useful also for the normal user of Tor HS, however it might have some bad anonymity consequences.
+
+Q: Is it a bad idea to discard slow circuits towards Tor HS and keep only fast ones?
+
+notes: Keep in mind that you have no control over the circuit on the Hidden Service side and that building a new circuit takes quite a lot of time.
+
+Q: What privacy implications does such a feature have?
\ No newline at end of file