Polaris / host reliability
Make start, stop, recovery, capture, input, logging, virtual displays, and cleanup predictable across supported Linux hosts. Improve diagnostics so the web console explains the path that actually ran.
Polaris is the Linux streaming host. Nova is the Android client built alongside it. Both are usable today, and both still have plenty of sharp edges worth removing before the fanciest research becomes product work.
Polaris / host reliability
Make start, stop, recovery, capture, input, logging, virtual displays, and cleanup predictable across supported Linux hosts. Improve diagnostics so the web console explains the path that actually ran.
Nova / client reliability
Make pairing, launch, controller input, reconnect, resume, stop, decoder behavior, and handheld navigation predictable on real Android devices.
Compatibility stays visible
Keep standard Moonlight-compatible clients working with Polaris, and keep Nova useful with standard Moonlight-compatible hosts. Richer Polaris integration must not turn compatibility into a guessing game.
Proof before performance claims
Establish a trustworthy baseline and change one behavior at a time. A faster run does not win if visual quality, cleanup, input, audio, fallback, or repeatability gets worse.
The next performance work stays deliberately boring in the best possible way: measure one thing, change one thing, and keep the rollback obvious.
When current work already touches capture, encode, media, decoder output, session lifecycle, device capabilities, or host/client contracts, a small protocol-neutral boundary may land first. That boundary must improve or preserve the current Moonlight-compatible path on its own. It is not permission to build a replacement transport through a side door wearing a fake mustache.
The current Moonlight-compatible path remains the production and fallback path. A native Polaris/Nova streaming path is a research option, not a promised rewrite. It moves forward only if measured work shows that the remaining limitation truly belongs to the transport—and only if pairing, security, input, audio, codecs, resume, browser behavior, diagnostics, rollback, and compatibility remain credible.
Nobody should need to migrate just because a prototype exists.
Proper HDR10+
The goal is real end-to-end dynamic metadata attached to the intended frames from source through capture, encode, transport, decode, and display, with honest HDR10 and SDR fallback. A capability flag or generic tone mapping does not count.
True 240 fps
The goal is 240 unique frames per second through render, capture, encode, transport, decode, and physical presentation on validated hardware. A 240 Hz mode, duplicated frames, or frame generation does not count.
More client surfaces
Android is the only shipping Nova client today. Steam Deck and Linux handheld work remains a development preview; iOS is planned without a release date.
Browser and Linux media research
Browser Stream, Vulkan Video, Linux 4:4:4, honest HDR headless operation, and other hardware-specific work stay behind their own usefulness and compatibility gates.
Passing each goal separately does not prove a combined HDR10+ at 240 fps profile. That combination would need one exact hardware, codec, color, bitrate, quality, latency, thermal, fallback, and rollback contract of its own.