Fit Launcher Contributions

Fit Launcher is a community launcher around FitGirl Repacks. Contribution work there is currently on hiatus while my own projects take priority, but the main work so far sits under the visible UI: debrid support, installer automation, IPC, and cleanup work that made the project easier to maintain.

The interesting work was not adding another button. It was getting the launcher to coordinate downloads, installers, elevation, and frontend state without turning the whole app into an admin process.

Debrid Integration

Added TorBox and Real-Debrid support behind unified backend types, so the frontend does not need to understand every provider-specific API shape.

TorBox was straightforward because it has cache availability endpoints. Real-Debrid needed a workaround: add the torrent, poll briefly, treat a fast 100% completion as cached, and delete it again if it is not cached. Not elegant, but it matches the API reality.

Secrets are stored through Stronghold. The frontend mostly gets provider state and display hints, such as whether a download path is likely to be fast.

Installer Monitoring

Replaced 250ms installer polling with Windows SetWinEventHook monitoring scoped to the installer PID.

FitGirl installers expose useful state in the window title, including percentages and phase text. Instead of repeatedly asking the window what changed, Windows pushes title-change events. The remaining polling is limited to final verification when the installer reaches the end state.

This made the automation less timing-sensitive and stopped the old progress monitoring from wasting CPU.

Scoped Elevation + IPC

Moved installer automation into a small elevated controller process instead of running the full GUI as admin.

The GUI stays asInvoker. When automation needs elevation, it spawns a controller through UAC and talks to it over a local named pipe using length-prefixed JSON messages.

Protocol shape:

commands: start, cancel, shutdown, ping
events: ready, phase, progress, file, completion, error

The controller is intentionally narrow: one instance, queued install requests, explicit shutdown, and lifetime tied to the pipe. It uses very little memory and exits when idle or disconnected.

The threat model discussion was useful. We kept it realistic: protect against other local users, stale instances, predictable IPC endpoints, and accidental cross-talk. Malware already running as the same NT user, process injection, kernel exploits, and UAC bypass chains are out of scope.

Cleanup

Other PRs were less flashy but probably just as useful:

• Settings input fixes for broken SolidJS reactivity and path mismatches.
• Error reporting cleanup so failures stop showing up as [object Object].
• Cache bootstrap fixes and discovery refresh events.
• Stale aria2 WebSocket detection and reconnect handling.
• Dependency hygiene across Rust and frontend packages.
• Husky hooks, rustfmt, clippy, linting, and dead-code cleanup.