FabianCarbonara

I've been circling the same exotic holes: I'm trying to sandbox LLM-written code in the browser - running it one layer deeper, in a worker spawned inside the sandboxed iframe.

The WebRTC hole actually goes away down there. RTCPeerConnection is Window-only, so it's just absent in a worker. But you're right not to trust CSP: I'm seeing worse. Under default-src/connect-src 'none' in a worker, Firefox still lets EventSource make the request (fetch/XHR/WebSocket/importScripts all block fine).

What I'm experimenting with right now is SES inside the worker: lockdown() + a Compartment. Still figuring out whether my framework stack survives lockdown().

For UI I'm using Shopify's remote-dom to mirror the UI to the trusted parent page.

(Thanks for vouching! I emailed the mods about my account. I think I tripped a filter with a clumsy submission start...)

About the sprites: loading them from Python at runtime actually works. Stage's Bank objects are plain Python bytes (2048 bytes = 16 tiles at 16x16, 4bpp) plus a palette; on first use, _snesstage.bank() converts them to SNES bitplane format and DMAs them into one of 8 VRAM slots.

On extension modules in general: MicroPython has compiled-in C "user modules" (that's what _snesfb/_snesstage are) and dynamically loadable native .mpy modules. But this needs per-architecture relocation support, and the 65816 isn't among the supported targets.

Python never touches the PPU: the memory-mapped registers live entirely behind a thin C layer (_snesfb / _snesstage modules). Sprite/tile bitmap data gets packed into VRAM tile banks once at startup; at runtime Python only mutates shadow state (hardware tilemaps, an OAM shadow, a framebuf for the GUI stuff) and once per frame the C side DMAs the dirty buffers across during vblank.

Yes, definitely: the GBA is a 32-bit ARM with 256 KB of RAM and mature GCC support, so it sidesteps everything that made this hard: the 16-bit size_t, the far pointers, the barely-stress-tested compiler. The SNES was the fun target though ;)

The bug count surprised me too. Calypsi is a great compiler, but MicroPython is likely the largest program anyone has pushed through it: a huge interpreter switch, packed structs, setjmp/longjmp exception handling, far pointers everywhere. Corners like that had simply never been compiled before.

Maybe I am a bit overdramatic ;) For me this is mostly about user experience. If the agent creates a complex mini app, the user might have to wait 30 seconds. That's 30 seconds without feedback. It's way nicer to already see information appearing - especially if that information is helpful. Also the UI can be functional already, even if it's not 100% complete!

A2UI is Google's take — declarative JSON, tool-calling based, predefined component catalog. Clean and safe but constrained.

My approach is the opposite bet: full code execution instead of tool calls. The agent can build any React UI from scratch with the full power of code — including client-server data flow, callbacks, streaming data.

Whoa, I hadn't seen channels yet — and you already got fenced working with Claude Code?! That's awesome. Would love to see what you built!

Interesting idea! The slots mechanism already handles some of this — you can mount a skeleton first and fill in named sections later as the LLM generates them. But true out-of-order transclusion could be useful for more complex layouts. Worth exploring!

and I meant to say: tinkerdown looks pretty cool!

The goal isn't really a better markdown format — it's bringing code execution and generative UI together. The code fences run on the server: calling APIs, processing data, doing agentic work. And they can also mount reactive UIs with full data flow between client, server, and LLM.

MDX is a compile-time format for static content. This is a runtime protocol where the LLM writes code that executes as it streams, and the UIs it creates stay connected to the server.

Exactly this!

Right now this uses React for Web but could also see it in the terminal via Ink.

And I love the "freeze" idea — maybe then you could even share the mini app.

Thanks! Really interesting to hear you're working on something similar.

You're right that the level of expressiveness is the key design decision. There's a real spectrum:

- pre-registered blocks (safe, predictable)

- code execution with a component library (middle ground)

- full arbitrary code (maximum flexibility).

My approach can slide along that spectrum: you could constrain the agent to only use a specific set of pre-imported components rather than writing arbitrary JSX. The mount() primitive and data flow patterns still work the same way, you just limit what the LLM is allowed to render.

Would love to hear what you learn if you explore it!