[anilgulecha]

I'd like to point Simon and others to 2 more things possible in the browser:

1) webcontainer allows nodejs frontend and backend apps to be run in the browser. this is readily demonstrated to (now sadly unmaintained) bolt.diy project.

2) jslinux and x86 linux examples allow running of complete linux env in wasm, and 2 way communication. A thin extension adds networking support to Linux.

so technically it's theoretically possible to run a pretty full fledged agentic system with the simple UX of visiting a URL.

[simonw]

I have a very minimal v86 experiment here: https://tools.simonwillison.net/v86

My eventual goal with that is to expand it so an LLM can treat it like a filesystem and execution environment and do Claude Code style tricks with it, but it's not particularly easy to programmatically run shell commands via v86 - it seems to be designed more for presenting a Linux environment in an interactive UI in a browser.

It's likely I've not found the right way to run it yet though.

[anilgulecha]

On the second tab (which is a text/browser interface to the VM) here: https://copy.sh/v86/?profile=buildroot , you can start sh shell, and run arbitrary commands, and see output. making a programmatic i/o stream is left as an exercise (to claude perhaps :).

[Lerc]

One of the very first experiments I did with AI was trying to build a browser based filesystem interface and general API provider. I think the first attempts were with ChatGPT 3.5 . I pretty quickly hit a wall, but Gpt4 got me quite a lot further.

I see the datestamp on this early test https://fingswotidun.com/tests/messageAPI/ is 2023-03-22 Thinking about the progress since then I'm amazed I got as far as I did. (To get the second window to run its test you need to enter aWorker.postMessage("go") in the console)

The design was using IndexedDB to make a very simple filesystem, and a transmittable API

The source of the worker shows the simplicity of it once set up. https://fingswotidun.com/tests/messageAPI/testWorker.js in total is just

    importScripts("MessageTunnel.js"); // the only dependency of the worker
  
    onmessage = function(e) {
     console.log(`Worker: Message  received from main script`,e.data);
     if (e.data.apiDefinition) {
       installRemoteAPI(e.data.apiDefinition,e.ports[0])    
     }
     if (e.data=="go") {
       go();
       return;
     } 
  }
  
  async function go() {
      const thing = await testAPI.echo("hello world")
      console.log("got a thing back ",thing)
  
      //fs is provided by installRemoteAPI  
      const rootInfo = await fs.stat("/");
      console.log(`stat("/") returned `,rootInfo)
    
      // fs.readDir returns an async iterator that awaits on an iterator on the host side 
      const dir = await fs.readDir("/")
      for await (const f of dir) {
        const stats = await fs.stat("/"+f.name);
        console.log("file  " +f,stats)
      }
    
  }

I distinctly remember adding a Serviceworker so you could fetch URLs from inside the filesystem, so I must have a more recent version sitting around somewhere.

It wouldn't take too much to have a $PATH analog and a command executor that launched a worker from a file on the system if it found a match existed on the $PATH. Then a LLM would be able to make its own scripts from there.

It might be time to revisit this. Polishing everything up would probably be a piece of cake for Claude.

[curtisblaine]

> 1) webcontainer

Isn't webcontainers.io a proprietary, non-open source solution with paid plans? Mentioning it at the same level of open source, auditable platforms seems really strange to me.

[anilgulecha]

Technically, it runs on Chrome, so making an open source version is viable. then bolt.diy project was giving opencontainers a shot, which is a partial implementation of the same. But broadly, if this method works, then FOSS equivalent is not a worry, should come soon enough.