mavdol04

It doesn't have browser support yet because it's WASI-based, so there are a few more steps compared to Emscripten (two different ways to build for WebAssembly). But networking is supposed to work, did you have trouble with it?

With RISC‑V emulation we get the virtual hardware components we need to boot Linux like MMU, registers etc. So a GCC WASM backend could definitely help, but I'm not sure it could replace the whole emulation layer.

It's a bit of a cheat, but you can hit 0.00% every time. Just measure the bar length, then cross-multiply. :)

Example: bar is 1250px, max is 2100, number is 376 → (1250 × 376) / 2100 ≈ 223.8px from the start, that's the 0.00%.

Working on a RISC-V emulator targeting Wasm. Is RVV 1.0 stable enough to be worth implementing, or would Zve32f/Zve64d already cover most use cases ?

That's cool, i did exactly the same few years ago

Nice, what are you building exactly ?

I am in the EU timezone and had some minor issues recently with GitHub as well, but it never lasts very long.

The worst that could happen is having your credentials stolen. It’s an LLM architectural flaw, so it has to be at the tools level so the only way to prevent it is still sandboxing in my opinion. Or at least sandboxing the tools themselves

I think a shared array just avoids the copy, not the serialization which is the main problem as they showed with serde-wasm-bindgen test

Wait, you just invented a reverse CAPTCHA for AI agent

That’s great, but it can’t be used in production because it’s not available for Linux (so no AWS, no GCP, etc.) and requires Docker Desktop. Still nice for experimenting, though.

I mean standardizing on an x86 subset would replace wasm's native portability with a kind of 'emulated' compatibility, and this is one of wasm's strengths. If we do that, non-x86 hardware(mobile etc.) will pay the translation tax. So, keeping Wasm agnostic makes more sense anyway.

It actually works a bit differently. The eval is executed by the interpreter running inside the isolated wasm sandbox (StarlingMonkey). You can think of it as each sandbox having its own dedicated JavaScript engine.

Thanks! Not yet, but that's a great idea. I could definitely add it to the roadmap.

yeah, the previous example was quite basic. I will write a complete example for that, but here is how you can run dynamic code:

   import { task } from "@capsule-run/sdk";

   export default task({
     name: "main",
     compute: "HIGH",
   }, async () => {
     const untrustedCode = "const x = 10; x * 2 + 5;";
     const result = eval(untrustedCode);
     return result;
   });

I would love for the component model tooling to reach that level of maturity.

Since the runtime uses standard WASI and not Emscripten, we don't have that seamless dynamic linking yet. It will be interesting to see how the WASI path eventually converges with what Pyodide can do today regarding C-extensions.

Thanks for the feedback! What do you think about running the separate file directly from the decorator?

Thanks! Got it, I will add more examples for that. Currently you can do both: run dynamically untrusted code with eval, or run fully encapsulated logic (like in the existing examples).

I made a small example that might give you a better idea (it's not eval, but shows how to isolate a specific data processing task): https://github.com/mavdol/capsule/tree/main/examples/javascr...

And yes, you are spot on regarding LeetCode platforms. The resource limits are also designed for that kind of usage.

I understand your point. I added native Python support because C extensions will eventually become compatible. Also, we might see more libraries built with Rust extensions appearing, which will be much easier to port to Wasm.

I recreated many Node.js built-ins so compatibility is actually quite extended.

For Python, the main limitation is indeed C extensions. I'm looking for solutions. the move to WASI 0.3 will certainly help with that.

Yep, exactly.

We stick to JSON to make sure we pass data, not behavior. It avoids all that complexity.

I see what you mean, but i think there is room for both approaches.

If we want to isolate untrusted code at a very fine-grained level (like just a specific function), VMs can feel a bit heavy due to the overhead, complexity etc

Actually, since it runs inside a WASM sandbox, even if the untrusted code overwrites built-ins like map or modifies globals(), it only affects its own isolated memory space. It cannot escape the WASM container or affect the host system

yep, and to be specific, it leverages the WASM Component Model and uses componentize-py to bundle the user's script

You're right, Docker isn't a sandbox for untrusted code. I mentioned it because I've seen teams default to using it for isolating their agents on larger servers. So I made sure to clarify in the article that it's not secure for that purpose.

Hi there, Author here!

I started building Capsule because I hit a wall with existing Python agent frameworks (fragile loops, lost state, no sandboxing). I felt we needed a proper infrastructure layer for this.

This is an RFC / Architecture Preview. I'm currently implementing the core engine in Rust (publicly), but I wanted to share the design philosophy first.

GitHub (API Specs & Roadmap):https://github.com/mavdol/capsule

Deep Dive: https://capsuleruntime.substack.com/p/fine-grained-isolation

I'd love to hear your thoughts on the Python API design (@task decorators) or the Wasm isolation approach!

Thank you! Yes, I use Docker to get ONNX DLLs and cross-compile the main DLL using the MSVC toolchain (which is required for game engines)

That's super interesting. Yeah, the 2D model has limitations for sure. Actually, we have a memory decay system with time, but nothing as elaborate as what you're describing. I'm curious to know more about your idea. Theoretically, how would you imagine separating memories? Would you use memories clusters with different weight for example ?

Thank you! Yeah, there are many use cases. The goal is really to expand what's possible with NPC interactions and emergent behaviors

Good question! Actually, it complements manual settings. There are many use cases but for example, in some games with multiple followers. You sometimes get bugs where they fight each other randomly for some reason. With this system, you could check their emotional state toward each other before triggering combat, and if they're actually friendly, you prevent the unintended fight