docs(tor): describe the macOS App Nap exemption and its gating

This commit is contained in:
Taksh 2026-08-11 15:39:09 +05:30
parent 2f685bc8ec
commit 9be1b305f1

View File

@ -40,6 +40,14 @@ Private messages target the built-in relay set plus any relays added by hand (`N
- The xcframework must include iOS device, iOS simulator, and macOS arm64 slices.
- Any refresh reviews the Rust source, `Cargo.lock`, generated header, build script, and new hashes together. A binary-only update is not acceptable.
## macOS: stay alive while minimized
On iOS, `AppRuntime` puts Tor dormant when the scene enters the background — the OS will suspend the process anyway. macOS has no equivalent scene-phase dormancy path: Tor is meant to keep running so a docked install can still bridge Nostr for nearby mesh peers.
macOS App Nap can still freeze that work when the window is minimized or fully occluded by another app. `MacRelayActivityController` therefore holds a `ProcessInfo` activity (`.userInitiatedAllowingIdleSystemSleep`) while a transport is actually relaying — Tor switched on (including bootstrap) or Bluetooth powered on. With Tor off and Bluetooth unavailable there is nothing to relay, so the assertion is released rather than costing battery for an idle process.
Closing the last window still quits the app, so stopping bitchat still stops the radios. See #1593.
## Known gap: no bridges or pluggable transports
`arti-client` is built with `default-features = false` and features `["tokio", "rustls"]` only — no `pt-client`, no `bridge-client` — and `arti-bitchat/src/lib.rs` bootstraps from stock configuration with no bridge lines and no configurable directory authorities.