I definitely don't think that ordinary things would be too CPU-hungry on the main thread, but given how awkward it _can_ be to use the worker APIs, it would be a lovely abstraction to be able to treat workers as pods. I would love to run a CPU-hungry or WASM service on a worker as a pod and communicate with it over your take on CNI!
Similarly, when you move on to doing Volumes support, the browser's OPFS APIs can be synchronous from workers and only async from the main thread, so there are interesting possibilities around buffering/caching/using SharedArrayBuffer to accept-and-write extents that could be nice with workers. :)
If I get a spare moment, I'll absolutely take a look at PR-ing a runtime!
I’m 100% confident it would be possible to do a worker-per-pod runtime. If you’re serious about trying to make it then slide into my DMs, would love to talk about it. I also think a CRI that supports WASM would be fairly easy.
Volumes are one of those things that I’m quite sure won’t be that difficult to implement but I don’t have a need for them in the near future, so likely won’t support them for a good while.