On Tue, Jan 9, 2024 at 12:58 PM Micah Elizabeth Scott beth@torproject.org wrote:
Ah. If you want to run an onion service you'll need to keep at least a couple circuits open continuously for the introduction points. I'm not sure where you would meaningfully find time to deep sleep in that scenario. There will be ongoing obligations from the wifi/wan and tcp stacks. You need a continuous TCP connection to the guard, and multiple circuits that are not discarded as idle. Incoming traffic on those circuits need to be addressed quickly or clients won't be able to connect.
If we were really optimizing for a low power mobile onion service platform we'd have a different way to facilitate introductions without a continuously open set of circuits, but that would also be much more abuse-prone.
-beth
Hm. Do you know, is it possible to make network-driven wakeup events relatively prompt? (Like, within a second or so if a TCP stream we're waiting on wakes up). If so, then onion services have a decent chance of being made to work.
As for the original question about timers, it would be good to know if the variance between scheduled wakeup and actual wakeup can be bounded, or if there's any way to mark a timer as high-priority vs low-priority or something.