On 26/11/2018 21:46, Nick Mathewson wrote:
On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers michael@briarproject.org wrote:
On 20/11/2018 19:28, Nick Mathewson wrote:
Hi! I don't know if this will be useful or not, but I'm wondering if you've seen this ticket: https://trac.torproject.org/projects/tor/ticket/28335
The goal of this branch is to create a "dormant mode" where Tor does not run any but the most delay- and rescheduling-tolerant of its periodic events. Tor enters this mode if a controller tells it to, or if (as a client) it passes long enough without user activity. When in dormant mode, it doesn't disconnect from the network, and it will wake up again if the controller tells it to, or it receives a new client connection.
Would this be at all helpful for any of this?
This looks really useful for mobile clients, thank you!
Glad to hear it -- it's now merged into Tor's master branch.
Fantastic.
The comments on the pull request (https://github.com/torproject/tor/pull/502) suggest that Tor won't enter dormant mode if it's running a hidden service. Are there any plans to support that in future?
I want to support this for hidden services. Here's the ticket to track that: https://trac.torproject.org/projects/tor/ticket/28424
This is going to be harder than the other cases, though, so we decided to defer it for now and see if we have time later.
Makes sense. I added some simulation results to the ticket that support dgoulet's assessment that the descriptor may become unreachable within a few hours if not republished, due to HSDir churn.
However, even one hour in dormant mode would be a huge improvement over what we can do now. What are the other blockers for running a hidden service in dormant mode?
Would it be possible/easier to keep an ordinary client circuit alive in dormant mode? That would allow us to keep a connection to a mailbox* while dormant.
Cheers, Michael
* Briar term for a device connected to power and internet that runs a hidden service on behalf of the owner's main device.