Comment by syrusakbary

Comment by syrusakbary 2 days ago

8 replies

This is great!

While I think that with their current choice for the runtime will hit some limitations (aka: not really full Python support, partial JS support), I strongly believe using Wasm for sandboxing is the way for the future of containers.

At Wasmer we are working hard to make this model work. I'm incredibly happy to see more people joining on the quest!

apignotti 2 days ago

Hi, if you like the idea of Wasm sandboxing you might be interested in what we are working on: BrowserPod :-)

https://labs.leaningtech.com/blog/browserpod-beta-announceme...

https://browserpod.io

  • syrusakbary 2 days ago

    Browserpod is great, been following it for a bit. Keep the good work up!

    The main issue that I see with Browserpod is very similar to Emscripten: it's designed to work mainly in the browser, and not outside.

    In my view, where Wasm really shines, is for enabling containers that work seamlessly in any of this environments: browsers, servers, or even embedded in apps :)

    • apignotti 2 days ago

      It is true that BrowserPod is currently focused on browsers environment, but there is nothing preventing the technology from running on native as well. It would requite some work, but nothing truly challenging :-)

souvik1997 2 days ago

Appreciate your support! We deliberately chose a limited runtime (quickjs + some shell applets). The tool parameter constraint enforcement was more important to us than language completeness. For agent tool calling, you don't really need NumPy and Pandas.

Wasmer is doing great work—we're using wasmtime on the host side currently but have been following your progress. Excited to see WASM sandboxing become more mainstream for this use case.

  • syrusakbary 2 days ago

    > For agent tool calling, you don't really need NumPy and Pandas.

    That's true, but you'll likely need sockets, pydantic or SQLAlchemy (all of of them require heavy support on the Wasm layer!)

    • souvik1997 2 days ago

      Fair point. We get around this by "yielding" back from the Wasm runtime (in a coroutine style) so that the "host" can do network calls or other IO on behalf of the Wasm runtime. But it would be great to do this natively within Wasm!

      • syrusakbary 2 days ago

        Might be worth taking a look at WASIX [1]

        We implemented all the system calls necessary to make networking work (within Wasm), and dynamic linking (so you could import and run pydantic, numpy, gevent and more!)

        [1] https://wasix.org/

        • souvik1997 2 days ago

          We will take a look! Thanks for sharing. Dynamic linking to run pydantic/numpy/etc. would be huge!