Should we remember dormant state on restart?
One of the core ideas of legacy/trac#2149 (moved) was for Tor to remember its dormancy across restarts. As of the finishing of legacy/trac#2149 (moved), Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 hours again. So people who restart their computers, or their Tor-including apps, will continue putting load on the Tor network.
So I am opening this ticket to not forget that second piece of it.
The first question is around the engineering side: when we go dormant, do we write that fact into our state file? And when we change our mind, I guess we clear it? Do we also write it when the controller commands us to go dormant? I guess yes.
The second question is about how thorough we want to be. Specifically, if we're expecting that people will restart their Tor, what about people who never leave their Tor going for a full 24 hours? Those people will never switch to a dormant state. Is that ok? The fix would be to record "partial progress towards going dormant" in the state file, which is kind of ugly but also doable.
The third question is around how to handle it when we start up and the state file says we were dormant. Continuing to stay dormant seems like the clear right behavior -- because after all, we can wake up and start bootstrapping if we actually get an application level request. But I guess that means we don't even try to bootstrap? Are there controller apps like Tor Launcher and Nyx that wait for the 100% bootstrap message and tell you that your Tor is broken if it doesn't happen? Is there something we can give those apps instead that will satisfy them that Tor is "acting as intended"? Is there some simple "connect to a relay and do a handshake with it once" thing that we can do instead on startup, to satisfy ourselves that Tor could work if we wanted it to? Or should we stay totally isolated from the network when we start up in dormant state?
I think some of these are ux questions, and answering them might be easier if we pick a couple of specific use cases for dormant mode. Here are two:
(1) What if some linux distro includes a Tor client package by default, and users can configure their apps to use it but many users don't. In that case we'd have thousands or millions of Tor clients installed but not usefully using the Tor network. And our primary goal there would be to make those Tors go totally quiet after a while. This was the original motivation for legacy/trac#2149 (moved).
(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.
So I think use case (1) is the one to focus on, and that also simplifies the ux questions.