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.

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 ;)

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!

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!

Ha, history does rhyme ;) Happy if you reach out via mail!

In my approach, callbacks are first-class. The agent defines server-side functions and passes them to the UI:

  const onRefresh = async () => {
    data.loading = true;
    data.messages = await loadMessages();
    data.loading = false;
  };

  mount({
    data,
    callbacks: { onRefresh },
    ui: ({ data, callbacks }) => (
      <Button onClick={callbacks.onRefresh}>Refresh</Button>
    )
  });

When the user clicks the button, it invokes the server-side function. The callback fetches fresh data, updates state via reactive proxies, and the UI reflects it — all without triggering a new LLM turn.

So the UI is generated dynamically by the LLM, but the interactions are real server-side code, not just display. Forms work the same way — "await form.result" pauses execution until the user submits.

The article has a full walkthrough of the four data flow patterns (forms, live updates, streaming data, callbacks) with demos.

Markdown UI and my approach share the "markdown as the medium" insight, but they're fundamentally different bets:

Markdown UI is declarative — you embed predefined widget types in markdown. The LLM picks from a catalog. It's clean and safe, but limited to what the catalog supports.

My approach is code-based — the LLM writes executable TypeScript in markdown code fences, which runs on the server and can render any React UI. It also has server-side state, so the UI can do forms, callbacks, and streaming data — not just display widgets.

There's a lot of work happening around both generative UI and code execution for AI agents. I kept wondering: how do you bring them together into a fully featured architecture? I built a prototype:

- Markdown as protocol — one stream carrying text, executable code, and data - Streaming execution — code fences execute statement by statement as they stream in - A mount() primitive — the agent creates React UIs with full data flow between client, server, and LLM

Let me know what you think!

Have a look at my blog! Is linked in my profile :)

I would say so ;-) Right now AI is a powerful tool for me. It helps me express ingenuity on a more abstract level, e.g. conceptual or product thinking rather than implementation details. Some of my current projects I could have built without AI, but not in the time I had. AI moved them from unrealistic to actually doable.

This is super exciting. Emacs already treats UI as just more Elisp to eval. The AI could sculpt the entire editor to whatever you need in the moment. No plugin to install, no config to maintain. Just describe what you need and the editor becomes it.

For me AI unlocked building things I just couldn't before. My creativity and ingenuity now have an outlet that wasn't possible without agentic coding tools. That's genuinely exciting. But I also keep wondering: how long until the level of abstraction I'm working at now gets automated too?

I noticed Gemini in Gmail rendering a small interactive UI directly in chat. That made me wonder whether agents could build new interfaces on the fly.

I explored some ideas and built a small prototype around three principles: code first, Markdown as protocol (text, code, data in one stream), and agent-emitted UIs via a simple mount() primitive.

Thoughts welcome! Especially around security and sandboxing of agent-generated code.

Interesting read!

to be honest, this was just a very stupid joke. i guess there is no good reason to compare the two.

too little, too late! I am super happy with React+Js nowadays..

Very cool project! This looks like so much fun to build. Thank you for the great documentation of your endeavour!

Thank you for your kind words - they might very well ensure that I keep working on the project!

Hey! Thank you for your input :-). You might need to encode your videos to mp4 first - but then it should work!

Let me clarify how this technically works: Your browser creates a DIRECT connection to your friend's browser and streams DIRECTLY to your friend. I do not see any legal problems - but I am not a lawyer for sure!

Hey! Thank you for the feedback. I put it on my todo list :-)

Hey Hacker News!

Recently I wanted to watch a movie with a friend online. I had the movie locally on my computer and could not find an easy way to watch that movie together. So I built it myself :-).

This is still a prototype! It is functional - but you should be using Chrome and your desktop computer . But if people find this project useful, I'd be glad to support other platforms as well!

Technology: I am using a simple nodejs server in the backend and react in the frontend. The server is used shortly to create a WebRTC connection. From then on all communication is done using WebRTC only. Thankfully you can easily share the content of a HTML video component using captureStream/mozCaptureStream :-).

I would love to hear your feedback!