This is so cool! I'm having trouble thinking of all the different use cases and potential issues with this, but I don't think anyone has done something like this before. Great work

I had the idea of achieving build isolation by codemodding the Rust implementations of bash and the GNU coreutils (brush+uutils) to use a VFS (wasmtime's cap-std) backed by the real FS and then disabling anything that remained problematic. It kind of works but I'm still not particularly confident in it and I think this is probably the better approach.

The some points of trouble I ran into were dead symlinks left behind on the FS pointing to real files and escape codes interacting with the terminal (e.g. escape codes reading from the clipboard).

The build isolation approach sounds interesting, but I'm not sure I understand.

Do you mean isolating build scripts by using a VFS mapped to the real FS and masking away everything the build script should not have access to?

The some points of trouble I ran into were dead symlinks left behind on the FS pointing to real files

Symlinks make this space trickier for sure.

escape codes interacting with the terminal (e.g. escape codes reading from the clipboard).

Woah. TIL this was possible.

Do you mean isolating build scripts by using a VFS mapped to the real FS and masking away everything the build script should not have access to?

Yes. Essentially the idea was to find the source control root (or something configurable) and mount the real subtree into a VFS where everything interacts with the filesystem through the VFS. I can run wasm compiled versions of apps I don't really trust or run native patched versions that I do.

For background, I'm writing a UI platform in Roc [1] and using just [2] in order to script things. I had extra tokens so I decided to do an LLM port of just over to Roc to exercise the compiler (it's pre-0.1, pushing the compiler leads to crashes) and people won't have to install Rust to write apps. Like wasm, Roc code can't access the outside world without the host providing the access to the outside world so in the process of the port I thought "I don't have to make posix calls, I can put it in sandbox and lie about it" so that's how I got here. I'm fairly close to being able to do hermetic builds so that's a possibility but this is mostly an exploration of whether the idea works or not.

[1] https://roc-lang.org/ [2] https://github.com/casey/just

I really like this. I think the possibilities are multiple. I will try it to test the generic POSIX compliance of my main hobby project.

What is the main plus you have over other similar projects or tools like JSLinux?

Which preprocessor directives can I expect to have if I need to write custom code when my executable is compiled for Kandelo?

What is the reason for choosing GPL instead of MIT or similar?

How easy would it be to integrate this into something like this?

https://lerc.neocities.org (first page load initialized the filesystem in indexeddb, reload the page to boot off it). I really should automate that.

If there is enough of an API to the processes being run by kandelo, I could even build a full /proc interface for them.

I feel like I'm not properly appreciating what that site does. Would you be up for explaining a bit? It fun to interact with the shell and fun to see JS implementations of core utils. How would you imagine Kandelo might integrate with it? Would it be another way to run programs in addition to the JS utils?

There is already a way to list processes that the Kandelo web app uses. To see the info, you can click the Internals button in the dock and click on the Procs tab. I'll try to follow up later with more details.

Would you be up for explaining a bit?

The way this system runs is it installs a simple filesystem using IndexedDB (with a serviceworker so that files can have urls if necessary) then the JavaScript executable are run by launching a worker. The worker asks the host page for an API and gets sent a list of function calls it can use. It uses a MessagePort to the host to perform actions, so it is a little analogous to a process doing syscalls. All of the calls are passed though to the host (with theoretical auditng by the host (in practice nothing is prevented at the moment)). So when you do a chain of piped commands from the command line, it is actually launching a worker for each and passing the output along to the next (nothing fancy, could be a lot faster). The stdin and stdout that the commands use actually have multiple channels, with html, json, and raw output possible. Commands can provide different output to each channel or just one. The contents are auto downgraded to whatever the reader can handle. So a program can actually output an <img> tag but if it is piped to something that can't handle html input it will receive it as text of the html source. The sender has the option of providing text as well so it could just send the altText on the text channel if it wanted to not be displayed as html source.

Would it be another way to run programs in addition to the JS utils?

That's what I was thinking. While it's reasonable to re-implement a lot of basic commands, once you get to large pre-existing software, having a way to run them from the same environment is what's needed.

The main integration point start wold be that my environment would need to have a way to point at some data filename/url and identify that it is a thing that can be run by Kandelo. Then it would pass it to Kandelo, If it had hooks for allowing the host environment to manage operations for some file descriptors then my environment would be able to assemble something that looked like stdin and stdout to the running process.

There's obviously a lot more going on for things that do graphics. Something that hid KMS stuff inside an iframe doesn't seem like it would be impossible though.