Run the environment in a WASM browser tab

[greenphire-cilie]

Very cool project. Feel free to close this issue as it’s probably not in scope of the project and would be better off as a chat in discord.

I’m looking for a way to integrate a sandbox environment like this in a corporate tool used by devs to interact with the environment, and would want to give them a way to run a sandbox LLM agent in an app tab that has a minimal set of access right to interact with their env ( think read only eks role to connect to kubernetes or AWS, plus a JWT token to call the app endpoints to do stuff but scopes to the task at play). I think discobot would be great at this, but as most are windows guys it’s hard for me to get them to setup their systems to interact with it. It’s why I’ve been looking at https://github.com/tractordev/apptron as a low friction way to get people access to it as everyone has a browser.

So my point is if you can support https://github.com/tractordev/wanix as a backend it would be very cool and it could be a great way to leverage this project in the corporate world.

[ibuildthecloud]

I'm interested in this. The first step is trying to see if you can get the coding agent itself to run in wanix. If not then that would require me to develop a custom coding agent which I'm not really willing to do atm. So I'd try to see if you can get OpenCode to run in wanix.

[progrium]

Just briefly looking at the opencode stack, I think it's bun's fault. IIRC, I tried getting bun working once (I don't love it) and ran into the issue there are no 32-bit builds. Same for Deno.

oven-sh/bun#5060

If somebody wants to help add a 64-bit x86 (or arm) emulator to Apptron, we could run it. It will be even slower. But 100% it will run.

I miss when opencode was Go.

[progrium]

Since Apptron is a more complete and usable environment built around Wanix, getting stuff to work in Apptron first is easier.

Also, just to clarify mental models, and why I'm talking about 32-bit and 64-bit x86 when talking about Wasm: Wanix/Apptron can run Wasm, but Wasm is a difficult target the more complex a stack is. Bun and Deno do not support 32-bit likely because of some dependency not supporting it, and the reason is likely to be that it would be non-trivial for that upstream project. That same dynamic applies to Wasm itself. So for any software, if we can't get or easily produce a 32-bit build, it's likely we can't get a Wasm build either.

We use v86 to JIT x86 to Wasm, which widens what can run by a lot. However, v86 is 32-bit x86 only. Other emulators like Bochs that can run 64-bit and can be compiled to Wasm will run much slower because a) wasm is still pretty 32-bit biased, b) Bochs is not a JIT.

[progrium]

One last thing. Adding 64-bit support to v86 really seems like something one could throw coding agents at:
copy/v86#133

[cosminilie]

I really think there is a big gap on windows right now and WSL is still problematic with some companies and their security teams, so it would be really nice to have something working for them. People are caught between increasing adoption of AI and no way to do it.

[ibuildthecloud]

In a decision I'm not sure anyone would like, I'm dropping the multi-agent support, and I just wrote my own agent. I'll have it done shortly. It's written in Go, so it should be compatible with this. I can definitely give a shot at adding x86-64 support to copy/v86. I can't imagine I would be able to create an actual PR, because it might be above my pay grade. It might just be AI slop, but I'll give it a shot.

[paralin]

@ibuildthecloud If you looked into this yet I am working on it now, I have already ported v86 to typescript to make things easier, at https://github.com/aperturerobotics/v86

[progrium]

@paralin I have mixed feelings about this v86 fork, but it's mostly positive I think. Are you in contact with upstream and/or interested in upstreaming? Or do you have a plan for downstreaming changes? (I ask as a potential downstream user)

[paralin]

@progrium copy has added my skiffos project as one of the demos a long time back, but other than that I haven't discussed this with them. I'll be syncing any changes made upstream into my fork and keeping it up to date. It's a major overhaul - and from the GitHub org you can see that I do this a lot (fork and overhaul projects) - to typescript. I'm also implementing a kernel module for dynamic memory scaling as well as a filesystem module. Would be happy to upstream - but I'm not sure if there's interest or not. Could open an issue and ask!