New v3 problem: Web workers do not seem to be available inside the ServiceWorker that's now responsible for the background_script. Right now, I run the WebAssembly instance inside a Worker to stay able to respond to things like translation and model list requests. (WebAssembly calls are blocking, calls to the Worker are through message passing.)

Or TranslateLocally would have to do some tmux-like magic where it can spawn its own daemon and connect to it somehow but don't even think about going down that route.

This actually seems like desirable functionality in the long term, if complicated to implement. Desktop application, browser, word all contacting a shared translation model process. Might also tie in with OS sandboxing. In Linux, I'd just send the stdin/stdout file descriptors as ancillary data over UNIX socket to the master daemon process then close the wrapper process. In windows, this is apparently not possible: https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

Windows equivalent to move file descriptors: https://lackingrhoticity.blogspot.com/2015/05/passing-fds-handles-between-processes.html

Current plan for Chrome support:

• Rewrite state management to use chrome.storage.session storage in Chrome and some shim for it (using message passing + stateful background script) in Firefox. Change events of this storage replaces the UpdateRequest and Update messages. Slightly annoying because it is a key-value store, not full-on objects with nested change listening.
• Popup doesn't need to communicate with background script, can use state management directly to communicate progress
• background script basically does nothing more than noticing tab unload to clean up state
• Run WASM translation in the main tab, like the Mozilla extension. Let other frames communicate with it through message passing. (But we should still run it in background script on Firefox?)
• Run lang-id in main tab using i18n.detectLanguage (as is done now, but loading fasttext on every page load would be much)