nilslice

its basically an iframe embedding doom on a remote webpage

agreed. no one needs the component model, and it's just a attempt for people to create work for themselves.

especially now with coding agents, the DX they think they are bringing to the table is completely irrelevant.

yes, you must save it to a laserdisc, and then observe it though a highly magnified digital microscope looking for a specific frame.

providing <script type="module" src="component.wasm"></script>

and the import loader to just put .wasm in an import and get to call functions are the actual useful things in this post

component model is trash

I worked at one of the quantum computing co's on their compiler stack (so pretty much pure classical compute stuff), but in order to have even a baseline understanding of the computations and programming using qubits, I had to first get a better intuition for the underlying quantum mechanics at play. This was a great introduction to the physics underpinning the computations:

https://www.youtube.com/watch?v=lZ3bPUKo5zc&list=PLUl4u3cNGP...

It's long, and the subject matter is intimidating at times, but watch, re-watch, then go deep by finding papers on subjects like superposition and entanglement, which are the key quantum phenomena that unlock quantum computing.

It also helps to understand a bit about how various qubit modalities are physically operated and affected by the control systems (e.g. how does a program turn into qubit rotations, readouts, and other instruction executions). Some are superconducting chips using electromagnetic wave impulses, some are suspending an ion/atom and using lasers to mutate states, or photonic chips moving light through gates - among a handful of other modalities in the industry and academia.

IBM's Qiskit platform may still have tooling, simulators, and visualizers that help you write a program and step through the operations on the qubit(s) managed by the program:

https://www.ibm.com/quantum/qiskit

It's good of you not to jump to any conclusions!

Idk what you think you have to gain with your stance lol

No one looks at MCP and sees "magic", they just see "finished integration". Something you can pretty much use straight away. That's the point.

What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use?

https://github.com/ahujasid/ableton-mcp

https://github.com/ahujasid/blender-mcp

https://github.com/CoplayDev/unity-mcp

https://github.com/mikechambers/adb-mcp

Very cool.

If anyone's curious to see what's packed in here at a glance: https://modsurfer.dylibso.com/module?hash=3fa6b28252b0d72c82...

Dynamic on-device code compilation from WebAssembly bytecode to Android (ART) native.

i get it... i find the productivity is extremely addictive

pls don't put an api key in a prompt

should kill off sdk generators too

you should check out the Extism[0] project and the Elixir SDK[1]. This would allow you to write the core services, routing, message passing, etc in Elixir, and leverage all the BEAM/OTP have to offer, and then embed "agents" written in other languages which are small Wasm modules that act like in-process plugins.

[0] https://github.com/extism/extism [1]: https://github.com/extism/elixir-sdk

Check out our MCP SSO solution!

https://docs.mcp.run/blog/2025/05/14/mcp-sso/

Each MCP server still needs to handle auth differently depending on what it's connecting to.

Setting aside expected criticism about this being some middleware layer, but we’ve launched a solution to this problem:

An MCP “SSO”, where you install and auth your MCP servers into profiles (collections of servers), which we virtualize into a single MCP server with only a single OAuth flow — simplifying the experience substantially for both the user of the MCP servers and the clients connecting to them.

https://docs.mcp.run/blog/2025/05/14/mcp-sso/

all of the servers deployed to mcp.run[0] are Wasm modules, and can run client side. they run in our cloud too, but you could use mcpx to pull them locally instead.

you can also get the raw wasm via our API and run them anywhere you can run Extism[1], the open source wasm runtime & framework that underpins it all. (Including this hyper-mcp project!)

[0] https://mcp.run [1]: https://github.com/extism/extism

Others should consider Chicory, enabling JVM apps to run wasm code (compiled from Rust or many other languages) at high speed, securely in-process.

JNI introduces a lot of other challenges and sacrifice in terms of portability, memory and retaining observability and control within the JVM.

Chicory even supports AOT compilation to translate wasm bytecode to JVM bytecode for native performance.

https://github.com/dylibso/chicory

lol yea, can't do much about it now!

Apple Wallet transformed how we manage our digital assets—creating a unified hub for cards, tickets, and passes that work seamlessly across services.

Today, we're bringing that same paradigm shift to software integration with mcp.run's SSO for MCP.

This new infrastructure lets users centrally manage authenticated connections to your tools (GitHub, Google, Figma, WordPress, etc.), and grant AI applications permission to use these tools on a users' behalf with a single authentication flow.

that's what this does :)

you bundle mcp servers into a profile, which acts as a single virtual mcp server and can be dynamically updated without re-configuring your mcp client (e.g. claude)

you might like mcp.run, a tool management platform we're working on... totally agree running a process per tool, with all kinds of permissions is nonsensical - and the move to "remote MCP" is a good one!

but, we're taking it a step (or two) further, enabling you to dynamically build up a MCP server from other servers managed in your account with us.

try it out, or let me get you a demo! this goes for any casual comment readers too ;)

https://cal.com/team/dylibso/mcp.run-demo

ah the classic "guy who depends on people viewing webpages doesn't like tech that obviates need to view webpages" response!

we just had a minor outage — sorry about that. It should be fully back online.

we’ve been building most of what OP has written about with https://mcp.run

We started doing this the day Anthropic released MCP in November last year. Our company has always been devoted to secure plug-in system technology having built Extism, a WebAssembly plugin framework.

We immediately saw MCP as the plugin system for AI and knew it would be significant, but were concerned about the security implications of running MCP servers from untrusted parties and using the STDIO transport which makes user systems vulnerable in ways we weren’t ok with.

So we built mcp.run which is a secure implementation of the protocol, running servers in fully isolated & portable wasm modules. They must be allow-listed to access files & network hosts, and cannot access any part of your system without your explicit permission.

They also run everywhere. Each server (we call them servlets) on mcp.run is automatically available via SSE (soon HTTP streaming) as well as STDIO, but can also be embedded directly into your AI apps, no transport needed, and can run natively on mobile!

We are excited about MCP and glad so many are too - but we really need more security-oriented implementations before it’s too late and someone suffers a seriously bad exploit - which could tarnish the ecosystem for everyone.

sounds like someone hasn’t actually tried or benchmarked this :)

The differential revolutionized transportation by solving a mechanical impedance mismatch. MCP is poised to do the same for software integration by solving the API impedance mismatch that has plagued systems for decades.

The future of integration isn't more rigid contracts – it's more flexible, intent-based communication between systems that can adapt as technology evolves.

We launched mcp.run in December ‘24 with that prediction (err, gamble ;) )

I wouldn’t say incentivized, but temptation would lead to that. We are not tempted though. We build new things on the same open, simple interfaces we want to support long term.

For example, https://mcp.run is one such business we are very excited about — and it is Extism at the core. No modifications to the runtime, just the same Extism we all know and love.

And we want way more than our own team to help maintain the open source project, no doubt about that! So simplicity and transparency are the name of the game.

One of the maintainers of Extism here! Thank you for the kind words.

As you know, we're all about delivering value with the actual standards today. This means using truly portable, w3c Wasm core modules. Not some "maybe in the future" standard a la Components.

If you realistically want to use Wasm everywhere, in practically every language, Extism is the way to go and we're in it for the long haul.

For those who appreciate the WIT IDL being worked on (now for way too long), we support a far simpler, more familiar OpenAPI based version to eliminate the boilerplate of type conversion & serialization across the guest-host boundary, worth checking out: https://github.com/dylibso/xtp-bindgen