The idea is to offer extensibility points in software by embedding their runtime into your current software. Say you have a database and instead of a DLS for querying, allow someone to upload a WebAssembly binary that has access to APIs you'd expose (`filter`, `map`, ...). I'm guessing they ease some of the complexity in moving data back and forth, their runtime is supported on N languages, and they use wasm's sandboxing properties.
The problem, for me, is even though the runtime supports many languages, the languages the plugins can be written in is limited. Rust and Go support wasm well, but AssemblyScript* is not JavaScript / TypeScript. If the idea is to extend software and make it more accessible, they need better support for interpreted languages: JS, Python, Ruby, ...
There will be ways to handle this problem in the future with the Component Model spec. I've seen it working but it's not easy to do yet. As of today though, yes bringing your own runtime is costly.
No, it took me a bit to understand as well. It looks like a set of host SDKs and a sandboxed runtime (guessing this is why they're using wasm) you can drop into your own software and expose some hooks that would allow your users to write their own plugins for your app in a variety of languages.
Extism is a plug-in system. Plug-in systems make your software programmable by end users (such as your customers or your open source community). Currently plug-in systems are quite difficult to build and limited to certain host and guest languages. Extism makes this easier regardless of your language or domain knowledge.
> Plug-in systems make your software programmable by end users (such as your customers or your open source community)
I am confused. Who is the "end user" or the "customer?
It seems like "developer" who is writing software for a customer is your end user or may be not. Who will actually use this is not clear from the website.
From couple of examples I think this comes close to something like a SQL CLR integration, where for example you can call a C# routine from SQL query.
Your end user would be a user of your application, e.g. a customer. But it could also be a marketplace like situation where people are developing plugins for your customers. Examples of plugin systems are things like VS-Code Extensions, Figma plugins, firefox extensions, etc.
I think it would be better described as a 'universal framework for incorporating plugins into your application'.
If I am right about these aspirations, they are quite grandiose. Shiver Shades of COM or corba reborn?
If I understand it, this is more about the plumbing of calling the Rust wasm execution engine from various languages. And probably the secondary problem of how do you package wasm-hosted code such that it can interface with multiple calling languages. Rust can build a shared object with C linkage. All the languages have ways to call "native" code (code with C linkage). This is the sauce to connect those dots in a multi-language, batteries-included way. Hopefully I got that right.
It's all in-process so not more like OLE than Corba ;)
Another marketing related comment: Extism is not a very nice name. It sounds like exorcism, which apart from being a rather unsympathetic concept, is more about ridding yourself of foreign stuff that’s controlling you rather than the other way round. If anyone has any suggestions, drop them here.
Hey folks, one of the authors here. Extism is a plug-in system. If you aren't familiar with this terminology, plug-in systems make your software programmable by end users such as your customers or your open source community (e.g. VS-Code Extensions). Currently plug-in systems are quite difficult to build and limited to certain host and guest languages. Extism makes this easier regardless of your language or domain knowledge.
Thank you - I think the intro page could help make this clearer. I’m not super familiar with the programmable nature of things beyond something like an Arduino, so I was very confused what “programmable software” meant in this context, and the landing page still isn’t super clear in that regard.
Your comment helps - would make sense to recalibrate on the shared page.
There are some examples, but the announcement is focused on the project itself - we will follow up over the next week+ with some end-to-end examples. Stay tuned!
We also have some example projects in the GitHub org, pointing out this one specifically, to create a UDF engine in sqlite3: https://github.com/extism/extism-sqlite3
Currently it is not, but we are closely tracking the Component Model to see how we can best utilize it. There are a few places we know we can leverage it, namely in the HTTP interfaces and other imports we provide to plug-ins. But, we also want to contribute to the language support on the codegen side. In order to get the language support we have already, we couldn't invest the time up front to build all the codegen in wit that would have been necessary. Over time want to get there though!
Authors are here to answer questions! To add a little bit of detail:
Extism is an open-source universal plug-in system with the goal of making all software programmable. Easily embed Extism into 13 popular programming languages (server or browser) and safely run high-performance WebAssembly plug-ins inside your code.
What does it mean to "make software programmable"? Simply put, you can give end-users the ability to extend your software with their code.
Plug-in systems are usually implemented in 3 ways:
1. execute a binary that is external to your process (like protoc)
2. re-compile a program with an implementation of some interface
3. dynamically link to native code / dlls
All 3 have major trade-offs on the performance-to-security ratio. Extism provides a way to "have your cake and eat it too" in a sense, that it doesn't compromise security for performance. True, executing WebAssembly as we do here is not running at fully native speed, but it's darn close. And its sandboxed architecture offers the security you want if you're considering an alternative to dll/dlopen.
We're only getting started here, and welcome feedback good and bad. Please join our Discord[0] if you want to chat, or open issues on GitHub[1].
There's at least one more approach to program extensibility that you should probably address: interpreted languages, especially Lua. Many games and utilities today use Lua or JS as an extension language. They have battle-tested runtimes, come with high-performance JITs, and provide the potential for rich interactive debugging and incremental development options that are not free with a WASM-based statically-compiled approach.
There are even entire applications written this way - Adobe Lightroom was originally built from some core C++ imaging code lifted from Photoshop but with all of the UI built in Lua. The dev builds of Lightroom have an entire integrated Lua dev environment in them.
If that is something you need come join the discord and let's work on it! I've been experimenting with higher level languages, specifically quickjs (js) and c#. Python should work from what I know, but I can't speak intelligently to how well it would work.
This is really interesting to me. I used to run a team that owned a software library (that you've probably heard of) that runs on Mac, Windows, iOS, Android, and embedded Linux. The product is over a decade old, so it's in C++ because that was the only real choice back then. We bolted on static analysis yet still had senior engineers working full time to iron out stability issues (deadlocks and other race conditions). I've been thinking about alternatives for a while now; Rust naturally, but also C# with Native AOT in .NET 7 (only supports Windows and Linux so far, but maybe in the future). It got me thinking though, why have to choose? There are a good number of languages that can compile to WASM, so maybe just bridge the platform-native presentation layer to WASM and put all the core logic in WASM. It "should" provide near-native performance and open up many other languages, and provide a nice migration path to run the existing C++ and new code in another language side-by-side. I know it's not explicitly the goal, but Extism seems like it could provide that functionality. I'll be following this project!
Very interesting, would love to know more about the library ;)
It does sound like you have found a _great_ use case for WebAssembly, and yes, Extism could provide similar functionality! We call it a "plug-in system" because that's a fairly concrete thing to say, but there are many other ways to use it.
Awesome. Now I just need a way to define a cross-language contract and this would be very helpful for my uses.
Ignoring performance for a second, one wonders if you could take proto and use that as the data in/out _and_ the API/RPC definition. Like many others, I've been wanting to add plugin support to my software, but I want a well-defined contract usable from others w/ complex types and known RPC calls. I think code-gen from proto for all supported client/host languages could get you there (at a perf cost compared to flat buffers or capn proto).
I've had great success with a fourth way: my project language compiles to C, which is loaded at runtime with libtcc (specifically: git://repo.or.cz/tinycc). I've gone down the .so/.dll route a few times in the past, but I can safely say: never again. libtcc has the advantages of a jit (native C speed), but with an elegant API and laudable portability.
Interesting (I think), but the page lacks a problem statement that the project seeks to solve.
As others have noted, "make all software programmable" seems a bit vague. And it's vague because there's no problem in there. When is software not programmable?
I think the idea is to make application extensions easier to integrate (like photoshop plugins), but I'm not sure.
Start with the problem statement, and everything else will fall into place. Leave out the problem statement, and leave your readers mystified.
Point taken. We've been focused on talking to people who have built, or tried to build, plug-in systems. But it's still a confusing concept to the general public without enumerating some examples.
Looks interesting. Based on prior experience, here are some concerns people will bring up with this approach:
1. Spectre. You may have to assume the plugin code can read anything in the address space including any secrets like passwords, keys, file contents etc. If the plugin can't communicate with the outside world this may not be a problem.
2. When you say WASM has a "sandboxing architecture", this is only partially true. It's quite easy to define a simple language that doesn't provide any useful IO APIs and then claim it's sandboxed - that's practically the default state of a new language that's being interpreted. The problems start when you begin offering actual features exposed to the sandboxed code. The app will have to offer APIs to the code being run by the WASM engine and those APIs can/will contain holes through which sandboxed code can escape. If you look at the history of sandboxing, most sandbox escapes were due to bugs in the higher privileged code exposed to sandboxed code so it could be useful, but you can't help devs with that.
3. WASM is mostly meant for low level languages (C, C++, Rust etc). Not many devs want to write plugins in such low level languages these days, they will often want to be using high level languages. Even game engines are like that: "plugin" code is often written in C#, Lua, Blueprint, etc. This is especially true because WASM doesn't try to solve the API typing/object interop problem (as far as I know?), which is why your example APIs are all C ABI style APIs - the world moved on from those a long time ago. You'll probably end up needing something like COM as otherwise the APIs the host app can expose will be so limited and require so much boilerplate that the plugin extension points will just be kind of trivial.
Lots of good points here. I'll try my best to address them. But you are right, There aren't really complete answers to each of these problems.
Regarding #1, it's good to point out that spectre is still an ongoing problem. wasmtime, the runtime we use, has mitigations for spectre but things will likely come up. I think we need more time and tools to work on things like detecting attacks and mitigating future problems. Fortunately there are some big companies working on it. Our team cannot solve that problem.
Regarding #2, sandboxing here refers to the memory access model and fault isolation. For each capability you give the plugin you may introduce risk. We don't claim to address this problem but I think education and mitigation are good goals for us.
Regarding #3, I think there has been some good progress here. I have an experimental C# plugin PDK and a JS one based on quickjs. We also support Haskell. I think there will be improvement here. And regarding the ABI comment, there are going to be layers on top of this to make it more ergonomic.
I've been saying it for years, but I think finally 2023 has the chance of being the year in which Wasm GC ships and managed languages start targeting Wasm more widely. We've made a lot of progress with the design, and V8 has a basically complete implementation. Google is targeting some internal apps to Wasm GC and seeing perf improvements over compile-to-JS, so I think this will likely be a success.
There's no such thing as one-size-fits-all GC. Wasm GC will probably be just as successful as other attempts at generic "managed" runtimes, which is to say, not very.
One is the implementation, e.g. the GC algorithm. They vary widely in their performance characteristics. For the most part, they are semantically invisible. I fully expect many different engines to have different algorithms, and ultimately you can choose and tune the GC algorithm to your application's needs.
Two is the semantics. We're aware of many failed attempts to make generic runtimes, and a critical factor is how universal the object model is. Of the many over the years, most have originated for a single language or paradigm of languages and have, in some sense, too high a level of abstraction. Wasm GC is a lower level of abstraction (think: typed structs), from which higher level constructs are implemented (like vtables, objects, classes, etc). Being lower level is a tradeoff towards universality that we have consciously made. That said, there are downsides, such as more casts, because it gets increasingly harder to safely encode invariants of source languages to avoid such casts at the lower level. We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these.
> We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these.
You could encode arbitrary invariants by implementing verifiable proof-carrying code within Wasm. Then a wasm-to-native compiler could be designed to take advantage of such invariants in order to dispense with these overheads.
That's a legitimately neat idea. There are couple of projects to improve safety of Wasm code using linear memory (such as RichWasm by Amal Ahmed and MSWasm by a number of folks at Stanford, UCSD, and CMU). Obviously unrestricted aliasing of the giant byte array that is memory makes this more difficult. I hope that Wasm GC can offer an abstraction base to express even more invariants. In some sense that will be a study in adding more powerful types and more powerful proof constructs that are either on the side or embedded in the code. So, exciting future directions!
There are, Go can also be compiled to WASM, but it has to carry the whole Go runtime with it (including but not limited to the GC), so the WASM files are a bit fat. You can however use TinyGo, a "Go compiler for small places" (https://tinygo.org/).
Yeah, I get the runtime can be big, but letting gc cross module boundaries seems really bad for sandboxing. I also kind of wonder why we'd want to use those languages in wasm other than their libraries and runtimes. If all you want is gc and performance why not use JavaScript or typescript? C# or go after a ~20% wasm penalty isn't going to be that much faster than js right? Or use something like nim that compiles to js and get libraries as well. The case for wasm always seemed to be absolute max performance in a safer package, which would send you towards languages that support manual memory management anyway.
One of the improvements that you get from the coming Wasm GC proposal is an object model that is inherently more space-efficient than JavaScript. While a lot of speculative optimizations can make JITed JS (of the right form) run fast with few checks, the object model inherently requires boxing or tagging and is not as memory-efficient as what Wasm GC structs give.
That would be cool but I wonder how much difference it will make. Most managed languages share at least two attributes:
1. Large runtimes and std libs. Python's "batteries included" is the epitome of this but even just java.base is large. This doesn't play well at all with browser cache segmentation.
2. You need a JIT for performance.
A good test of whether WASM is really heading towards generality is whether you could implement V8 as https://www.google.com/v8-js.wasm and just auto-include it into HTML pages for backwards compatibility. I know you have unusual experience and expertise in meta-circular VMs - is WASM really heading in this direction? The two obvious sticking points today are: V8 would get downloaded fresh on each origin, and JITd fresh on each page load, and what does such a runtime emit as compiled code?. Is your JITC being JITCd by a JITC and if so is the JITCd output then being JITCd a second time? If so, how on earth does this make sense?
An alternative would be to explore whether the process level sandboxes are now good enough to just allow native code to run inside them and let people use their existing managed language VMs. Google thought that was close to plausible many years ago with NaCL, and kernel sandboxes got a lot stronger since then. It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.
Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime at a standard URL. That works, modulo the security features today that cache Wasm modules per-origin to avoid an engine JIT bug creating a cross-origin vulnerability. GC helps a bit with that in the sense that the GC algorithm itself moves down into the engine.
> 2. You need a JIT for performance.
I worked a bit on a prototype JVM on Wasm that used the Wasm bytecode format to encode Java constructs. That helps because then you don't have another bytecode interpreter running on level up, but ultimately you want somewhat more control over the JIT and the code it generates. Wasm engines supporting dynamic code generation at all (any finer-grained than a module) would help a lot there.
Compiling V8 whole-hog seems like it would take a lot of doing. In particular, it has JITs and an interpreter that want to spit out machine code. That'd have to be replaced with Wasm backends.
> It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.
The politics were...complicated. I'd tell my side but it's probably best I don't.
Hmm interesting. I thought the cache segmentation was to block timing attacks by the web server (measure time between first page send and js execution to figure out what files are cached i.e. your browser history). I didn't realize it was due to lack of confidence in the JIT. Isn't a WASM JITC a fairly straightforward thing?
Re JVM on wasm with gc: it might be simpler at first to build a Graal/native-image backend for wasm+gc. No runtime JIT needed. Happy to join in on the fun.
> 1. Large runtimes and std libs. Python's "batteries included" is the epitome of this but even just java.base is large. This doesn't play well at all with browser cache segmentation.
Right but that's only one, niche use case (why you'd want plugins in a web page ?).
Even if you are web app with plugins
* that is not a problem for first load, user adds plugins later once they get familiar with the app
* you can still (I assume) just download it in the background and shove it into local storage
The whole use case seems to be "there is an app that would benefit from plugins and we don't want someone to learn the language just to write that plugin" and the idea is pretty sound - WASM embeds well and is fast enough.
A one size fits all GC is never going to be a great solution though, is it?
Different languages have different GCs that are designed to work with their semantics. Some languages use a flag bit to tell the runtime if a value is stack or heap (Go, Ocaml), some languages allocate almost everything and assume a lot of short lived objects (Java)...
But the competition is compile-to-javascript, which has exactly the same problem. With WASM, you get to choose between using a generic, potentially sub-optimal GC, or having a larger payload and including a GC bundled with the application.
I think there’s somewhat of a disconnect between the original idea of WASM (in browser) versus headless. In the browser folks get JavaScript for free which collects its own garbage. WASM is there to supplement higher level language for performance-intensive tasks and as such, “lower level” languages make more sense for these code paths.
I’d like to point out also that providing users a million languages to write plugins in for a product could create a lot of bloat. Imagine an image editor with 5 plugins, each written in its own language running in WASM sandboxes: golang, C#, assemblyscript, ruby, python. That’s 5 runtimes each running it’s own garbage collection logic.
I can see the value for compute hosts because the very nature of the provided service is allowing users to write sandboxed apps. But I think for stand-alone applications it’s best to support one or two simple targets, whether sandboxed or otherwise.
There are languages (Lua for example) optimized for this already.
I suppose the benefit is that each application which uses the WASM backend can decide on their “official” language and provide a decent built-in IDE experience.
I don't think WASM should/would unify the GC across memory models, that could be extremely problematic.
The gist of the idea is polyglot languages can leverage libraries across many languages. The fastest code is the code that was already built (that you didn't need to write).
It's unlikely applications would actually implement libraries from 5 different runtimes (they could, but shouldn't), and if they use RUST libraries, there definitely wouldn't be any GC anyway.
The benefit of this tech is it allows a new language to leverage historical codebases quickly without needing to re-invent every common utility library.
This will inevitably speed adoption of newer languages, zero code tools, etc .. and is the epitome of Proebstings law, which could also accelerate Proebstings (which is every decade) to being to approach Moores law (but I'm not specifically saying that will happen, only that it could).
> I don't think WASM should/would unify the GC across memory models
WASM already has a GC proposal[0] which is already at the "Implementation stage"[1] so it looks like this IS going to happen, although it's uncertain if language runtimes like Go will actually make use of the feature, or what.
A glance of the overview and spec seems to indicate that WASM will provide some primitive data types, and any GC language can build their implementation on top of it. As I understand it, it's heavily based on Reference Types[3], which allows acting on host-provided types, and is already considered part of the spec [4]. It doesn't remove the need for the 5 different runtimes to have their own GC, but it lowers the bulk that the runtimes need to carry around, and offloads some of that onto the WASM runtime instead.
At least the common plugin language lua runs in wasm, and micropython is less than a megabyte in wasm, so that point is a bit weak. (having an extra level of abstraction may make the plugins minimally slower, but running lua in wasm adds an extra level of security)
Congrats on the launch! Just yesterday I was pondering if I could do something like this for a saas I’m working on: I’d like to offer users the ability to extend their dashboard in certain ways (a la WP/Shopify plugins), but those ways require extending the ui AND the server code.
Extism seems like a great fit for this, I’ll definitely be checking it out :)
Thanks! I want to highlight that Extism supports both server-side AND browser environments, running the same plug-ins. So SaaS is a great example of a place where end-users may want to extend functionality that runs on the client, server, or both. Feel free to reach out if you have any questions.
Sounds very cool and like it could be a good fit for our browser based runtime! There are still a few limits, but you can currently run the same plugins in your backend and frontend.
As others have said, the term "software" is confusing. Application or software product seem more apt.
The other small point I'd raise: there's mention that due to the sandboxing of WASM it's "safe" to run untrusted code. Maybe I've misunderstood. To me that seems true in so far as the untrusted code cannot break out and can only do actions the hosting app decides to allow, but this isn't much consolation if the app allows actions that can be subverted.
For instance, if the app allows control over saving a file, untrusted code only gets to handle that within the rails the app sets but that still means dodgy code could fill up a hard drive by saving over and over, or it could possibly save over important files.
> As others have said, the term "software" is confusing. Application or software product seem more apt.
That's a great suggestion thanks!
> To me that seems true in so far as the untrusted code cannot break out and can only do actions the hosting app decides to allow, but this isn't much consolation if the app allows actions that can be subverted.
Yes i think safe is a relative term here. Any user input is "unsafe" to some degree. Your example is a good one! I think we wrote this in the context of other relative ways to do this but will be discussing better ways to talk about security and what Extism protects and what it doesn't.
If I want to make all software programmable, I install Frida and easily hook into pretty much anything at the same privilege level.
Still, misleading headline aside, this sounds pretty cool as a reasonably well sandboxed plug-in architecture for software that chooses to use it.
Though if running in-process, it seems unlikely to be able to defend against hostile plugins that use e.g. speculative execution techniques to extract otherwise inaccessible data. But perhaps that's not the threat model here.
> Maybe a "max_MB" property might be more useful to plugin authors, and then just calculate the # of pages internally from that?
yeah, that's something to consider. You can only pass in parameters that are a multiple of the page size so that may not be an accurate representation. I do think we need to hint at the unit in the name though.
We're both all in on extensible software powered by WebAssembly, but the scope and domains differ.
Suborbital is more of a turnkey / batteries-included service that handles the full lifecycle of extending SaaS applications with user-defined plugins. So it includes a web-based editor widget, a module builder service, storage and compute, administrative dashboards, etc.
Extism, from my lay understanding, is more tightly scoped toward being a great library for running WebAssembly modules, in the same way you might embed a Lua runtime into an application for user scripting.
Another big difference is that you can use all of Extism right now. Suborbital's hosted platform is still in closed beta :) (Waitlist at https://form.typeform.com/to/DHxjRGKx)
yes, Wasmtime does use a JIT. We haven't tried on mobile yet, but I think I have some paths to make it work. If this is something you need come join our discord and we can experiment on it!
This looks fantastic! I'm working on a desktop app and I've been struggling with the extensibility story in the back of my mind for a couple of weeks now.
Thanks for building this!
edit: For what it's worth, the use case and value of something like this was immediately apparent to me.
Awesome! We'd love to see what you end up building, and if you use Extism please let us know what you find missing...
> For what it's worth, the use case and value of something like this was immediately apparent to me.
Thank you for saying so. Negative feedback doesn't bother me (I appreciate anyone taking time to speak up), but it's also usually the only kind you get on the Internet :) so we appreciate hearing that. Translating ideas into words is hard, especially in software.
I've built a plugin-system back in 2003 or so based on the JVM which can load/re-load bytecode relatively easily.
(the concept became popular in the JVM world and lead to abominations like OSGi)
The problems that arose quickly were:
- Executing order of plugins attaching to the same extension point.
- Third party library dependencies having different versions
- Traceability and debugging
- Thread-safety
OTOH, it gave our custom dev team to develop integrations and extensions that could be deployed and maintained independently of the main product.
So there's definitely a use-case in there, but it requires some coordination regardless.
Would love to hear more about your experience there.
> (the concept became popular in the JVM world and lead to abominations like OSGi)
I remember this, though it was a couple years before my time. Although some of the underlying technology has changed those problems you outlined have remained the same. These things are all relevant to our next steps. We've been thinking a lot about what developer experience problems need to be solved.
I'm trying to figure out what Extism is actually providing here.
The underlying runtime appears to be Wasmtime, an existing project that you can use separately.
For the system API, Extism supports WASI (a POSIX-like API for WASM) which is already supported by Wasmtime. However it sounds like it also has a different, non-WASI API that provides similar functionality. I'm curious to hear a compare/contrast between these two system APIs, or what motivated inventing a new non-WASI system API. It does appear that WASI is in its early days; WASI was announced in 2019 (https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...) but it appears that all of the specific proposals are still early stage and far from being standardized (https://github.com/WebAssembly/WASI/blob/main/Proposals.md).
For the API, Extism provides a C API/ABI that can be called through FFI, but AIUI Wasmtime already has such an API: https://docs.wasmtime.dev/c-api/
Basically I'm trying to understand the conceptual difference between this project and Wasmtime.
It's a good question. It's hard to understand what all is involved in building something like that until you have to get into the details. You can think of Extism as a layer around wasmtime. There is an ABI of sorts that helps you communicate with the plugin: Send data to it, invoke functions, and get data out. With our system, you don't need to enable WASI to use a plugin. You can invoke functions directly. However, you can use WASI for other purposes. And we are working on a way to do POSIX-like stuff (e.g. programs with a main function that use stdin and stdout).
Because we wrap wasmtime, we can also switch it out. That's how we are able to run the same plugins in the browser. There we use the browsers' implementation.
I think one day we will replace some internal pieces of Extism with pieces of the Component Model spec. As of today it's not in a state where we can do all of this in this many languages.
Hey! Super exciting to see your progress on Extism.
I'm Syrus, from Wasmer. I did a quick review of your plugin architecture and it looks great (tons of languages supported, congrats!). I think Wasmer might be able able to help you so you have the same implementation of the runtime inside and outside of the browser (something similar as we did in wasmer-js [1], where we reuse same WASI implementation, but using the native Wasm engine from the browser).
I'd love to see how we can integrate your plugins into Wasmer as well!
Syrus, thanks for the kind words! Would love to work with you on integration. I'll reach out & find some time to sync up on it. Or, feel free to join our Discord and we can loop in the team: https://discord.gg/cx3usBCWnc
Linking wasmtime with host functions through the c abi is a bit cumbersome so I believe (in theory) this product can serve a real need by making plug-in integration more streamlined. Wasm as new plugin target / intermediary is a nobrainer (unless your game is written in c# or you like lua)
That makes sense, thanks. It sounds like a key difference is that Extism is trying to be portable to both web and standalone WASM runtimes. And maybe part of the motivation for a new WASI-like API is that WASI doesn't aspire to be portable to the web, and Emscripten's standard library only works on the web, whereas your system API is designed to be portable to both.
Yes I think that's a good way of putting it. Extism's primary goal is universality. I think the idea of having a plug-in system that is truly universal is exciting. Now we can share and maybe even sell plugins into different ecosystems. No more silo'd environments. I hope to see a future where standards can be built on top of this and plug-ins can outlive the applications themselves. Think VSTs if you are into music software.
That's interesting, one of examples that is challenging is a universal html template plugin. I'd love to try if it's feasible. Basically it should be logic less like Liquid. The unsure part is the custom tag, can it be called by host or not.
for JS on the Web, yes - we ported our runtime specific APIs to TypeScript and expose them to the WebAssembly runtime in the browser
for JS in Node, we use wasmtime embedded within our runtime -- looking into what the tradeoffs are to re-implement the whole runtime in Node on its native WebAssembly runtime though. Feedback welcome & appreciated!
The plugins are, but not the host. You can create pools of plugin instances if you need concurrency. Threading inside a Wasm program is still a new concept but I think it will become more common.
Will WASM finally be the write once run everywhere system we've been promised for the past few decades?
I can imagine every language compiling to the common format that is WASM, so you can mix and match libraries from other languages as you please, as well as chip manufacturers adding hardware accelerated WASM processing units if it gets popular enough.
No. WASM will have the same problem that every "run everywhere" system ever had: what makes software hard to port is not the ability to execute it, it's the environment differences.
But it will be a powerful low trust portable VM, like none mainstream today. Odds are it kills Lua.
(And yeah, it removes the Javascript monopoly on the browser. At this point, it can't be killed, but it will shrink.)
Lua is more like a C library and less like a VM. (Similarly, LLVM isn't a VM, which is a common misunderstanding, given the name)
As far as I know, people don't ship code to remote Lua VMs and execute it. There is no compatibility guarantee across versions, and there are nontrivial compile-time options (like what the number type is).
That doesn't mean Lua isn't useful; it's just not designed for the same things that WASM is.
> Will WASM finally be the write once run everywhere system we've been promised for the past few decades?
I think it has a good shot! If I'm hedging my bets though I'd say there are some things it will just never be good at. That's okay though it's not a zero sum game.
> This really is the birth and death of Javascript.
One thing I will not bet on is the death of javascript!
Interesting. Just this week I've been building a little experiment in order to utilize WASM based plugins in a project I'm involved with. I'm using WasmEdge for the task and so far am having pretty good luck.
Questions:
1. Can WASM plugins with Extism easily call back into host provided APIs?
2. Complex types are supported?
WasmEdge is really cool -- I'm super impressed with the work they are doing and hope to eventually provide an alternative runtime backend to Extism using WasmEdge (maybe they'd like to help!)
To answer your questions:
1. Extism provides a specific set of host provided APIs, and currently we don't have support for user-supplied host functions beyond the ones we make available. This will change though, and we're looking for feedback. We held off because there wasn't a clear way to make it easy across ALL the languages we support.
2. Complex types are definitely supported, you need to encode the data into raw bytes and can use whichever format you want (only limited by which formats are available in host & plug-in languages..)
Eventually we will move towards the Component Model which will make the complex types story much simpler.
Thanks for the info! I'll be keeping an eye on this for sure. What I'm working on is a PoC and it's working well thus far. As Extism advances and supports some of these upcoming features, it may turn out to be "just right" for my needs.
* I am confused about why it's used for a project like this and not some kind of internal NSA project, or maybe a nu-witch house band logo, or something
I intended to invoke thoughts about how Extism enables one to "extend from within", thus the octopus crawling out from the skull. And also that the thing Extism should replace is rather cursed... loading DLLs / dlopen tons of plug-ins into your program to execute untrusted code is downright scary.
I'd love to see C# support for something like this as well. Would be nice if Unity games could start supporting wasm plugins. Not sure if something like that works for Ureal already.
Another question... Is something like this possible on iOS or will these kinds of runtimes be banned by Apple?
C# support on which side? The host or the plugin side? I've got an experimental C# plugin almost working. I think I can do it. A Host SDK library would be pretty easy since it's just FFI to the runtime.
> Would be nice if Unity games could start supporting wasm plugins
That would be pretty neat! I go back and forth over whether this kind of thing will happen or not. Extism's goal is to be very generic (universal). A game engine may have some competing goals like performance or predictability. Still, I wouldn't be surprised if some alternative engines didn't do this in the next few years.
> Another question... Is something like this possible on iOS or will these kinds of runtimes be banned by Apple?
Not today, but I think I know how to get there.
If you need this stuff for your project come join the discord and we can try to prioritize it!
169 comments
[ 3.2 ms ] story [ 227 ms ] threadWhat does it mean to "make all software programmable" -- meaning make Wasm work with all languages? Is this really feasible?
Maybe I'm simply getting old and don't understand recent jargon shifts.
The problem, for me, is even though the runtime supports many languages, the languages the plugins can be written in is limited. Rust and Go support wasm well, but AssemblyScript* is not JavaScript / TypeScript. If the idea is to extend software and make it more accessible, they need better support for interpreted languages: JS, Python, Ruby, ...
* - Closures are still not supported: https://github.com/AssemblyScript/assemblyscript/issues/798
I am confused. Who is the "end user" or the "customer? It seems like "developer" who is writing software for a customer is your end user or may be not. Who will actually use this is not clear from the website.
From couple of examples I think this comes close to something like a SQL CLR integration, where for example you can call a C# routine from SQL query.
https://learn.microsoft.com/en-us/dotnet/framework/data/adon...
Here is a good example of a wasm plugin system for an open source project: https://istio.io/latest/docs/reference/config/proxy_extensio...
It's all in-process so not more like OLE than Corba ;)
doesn't mean anything to me, and I doubt it means much to a lot of others either.
I'm just talking a basic marketing fail here. bhelx below made it make more sense that their whole intro page.
(:
Your comment helps - would make sense to recalibrate on the shared page.
https://github.com/bytecodealliance/wit-bindgen
Extism is an open-source universal plug-in system with the goal of making all software programmable. Easily embed Extism into 13 popular programming languages (server or browser) and safely run high-performance WebAssembly plug-ins inside your code.
What does it mean to "make software programmable"? Simply put, you can give end-users the ability to extend your software with their code.
Plug-in systems are usually implemented in 3 ways: 1. execute a binary that is external to your process (like protoc) 2. re-compile a program with an implementation of some interface 3. dynamically link to native code / dlls
All 3 have major trade-offs on the performance-to-security ratio. Extism provides a way to "have your cake and eat it too" in a sense, that it doesn't compromise security for performance. True, executing WebAssembly as we do here is not running at fully native speed, but it's darn close. And its sandboxed architecture offers the security you want if you're considering an alternative to dll/dlopen.
We're only getting started here, and welcome feedback good and bad. Please join our Discord[0] if you want to chat, or open issues on GitHub[1].
[0]: https://discord.gg/cx3usBCWnc [1]: https://github.com/extism/extism/issues
It does sound like you have found a _great_ use case for WebAssembly, and yes, Extism could provide similar functionality! We call it a "plug-in system" because that's a fairly concrete thing to say, but there are many other ways to use it.
Ignoring performance for a second, one wonders if you could take proto and use that as the data in/out _and_ the API/RPC definition. Like many others, I've been wanting to add plugin support to my software, but I want a well-defined contract usable from others w/ complex types and known RPC calls. I think code-gen from proto for all supported client/host languages could get you there (at a perf cost compared to flat buffers or capn proto).
As others have noted, "make all software programmable" seems a bit vague. And it's vague because there's no problem in there. When is software not programmable?
I think the idea is to make application extensions easier to integrate (like photoshop plugins), but I'm not sure.
Start with the problem statement, and everything else will fall into place. Leave out the problem statement, and leave your readers mystified.
You can also take a look at our binary releases to get an idea: https://github.com/extism/extism/releases/tag/v0.1.0
In terms of memory usage, as the host you can constrain the memory that your plugin can use. There is a minimum of one Wasm page (64KB in this case).
1. Spectre. You may have to assume the plugin code can read anything in the address space including any secrets like passwords, keys, file contents etc. If the plugin can't communicate with the outside world this may not be a problem.
2. When you say WASM has a "sandboxing architecture", this is only partially true. It's quite easy to define a simple language that doesn't provide any useful IO APIs and then claim it's sandboxed - that's practically the default state of a new language that's being interpreted. The problems start when you begin offering actual features exposed to the sandboxed code. The app will have to offer APIs to the code being run by the WASM engine and those APIs can/will contain holes through which sandboxed code can escape. If you look at the history of sandboxing, most sandbox escapes were due to bugs in the higher privileged code exposed to sandboxed code so it could be useful, but you can't help devs with that.
3. WASM is mostly meant for low level languages (C, C++, Rust etc). Not many devs want to write plugins in such low level languages these days, they will often want to be using high level languages. Even game engines are like that: "plugin" code is often written in C#, Lua, Blueprint, etc. This is especially true because WASM doesn't try to solve the API typing/object interop problem (as far as I know?), which is why your example APIs are all C ABI style APIs - the world moved on from those a long time ago. You'll probably end up needing something like COM as otherwise the APIs the host app can expose will be so limited and require so much boilerplate that the plugin extension points will just be kind of trivial.
There many initiative around wasm, one of them being WebAssembly interface types, aimed at that problem. This makes using wasm simple.
Regarding #1, it's good to point out that spectre is still an ongoing problem. wasmtime, the runtime we use, has mitigations for spectre but things will likely come up. I think we need more time and tools to work on things like detecting attacks and mitigating future problems. Fortunately there are some big companies working on it. Our team cannot solve that problem.
Regarding #2, sandboxing here refers to the memory access model and fault isolation. For each capability you give the plugin you may introduce risk. We don't claim to address this problem but I think education and mitigation are good goals for us.
Regarding #3, I think there has been some good progress here. I have an experimental C# plugin PDK and a JS one based on quickjs. We also support Haskell. I think there will be improvement here. And regarding the ABI comment, there are going to be layers on top of this to make it more ergonomic.
I've been saying it for years, but I think finally 2023 has the chance of being the year in which Wasm GC ships and managed languages start targeting Wasm more widely. We've made a lot of progress with the design, and V8 has a basically complete implementation. Google is targeting some internal apps to Wasm GC and seeing perf improvements over compile-to-JS, so I think this will likely be a success.
Two aspects to that.
One is the implementation, e.g. the GC algorithm. They vary widely in their performance characteristics. For the most part, they are semantically invisible. I fully expect many different engines to have different algorithms, and ultimately you can choose and tune the GC algorithm to your application's needs.
Two is the semantics. We're aware of many failed attempts to make generic runtimes, and a critical factor is how universal the object model is. Of the many over the years, most have originated for a single language or paradigm of languages and have, in some sense, too high a level of abstraction. Wasm GC is a lower level of abstraction (think: typed structs), from which higher level constructs are implemented (like vtables, objects, classes, etc). Being lower level is a tradeoff towards universality that we have consciously made. That said, there are downsides, such as more casts, because it gets increasingly harder to safely encode invariants of source languages to avoid such casts at the lower level. We're OK with the overheads we've measured so far but are always looking for mechanisms to reduce or eliminate these.
You could encode arbitrary invariants by implementing verifiable proof-carrying code within Wasm. Then a wasm-to-native compiler could be designed to take advantage of such invariants in order to dispense with these overheads.
That's a legitimately neat idea. There are couple of projects to improve safety of Wasm code using linear memory (such as RichWasm by Amal Ahmed and MSWasm by a number of folks at Stanford, UCSD, and CMU). Obviously unrestricted aliasing of the giant byte array that is memory makes this more difficult. I hope that Wasm GC can offer an abstraction base to express even more invariants. In some sense that will be a study in adding more powerful types and more powerful proof constructs that are either on the side or embedded in the code. So, exciting future directions!
1. Large runtimes and std libs. Python's "batteries included" is the epitome of this but even just java.base is large. This doesn't play well at all with browser cache segmentation.
2. You need a JIT for performance.
A good test of whether WASM is really heading towards generality is whether you could implement V8 as https://www.google.com/v8-js.wasm and just auto-include it into HTML pages for backwards compatibility. I know you have unusual experience and expertise in meta-circular VMs - is WASM really heading in this direction? The two obvious sticking points today are: V8 would get downloaded fresh on each origin, and JITd fresh on each page load, and what does such a runtime emit as compiled code?. Is your JITC being JITCd by a JITC and if so is the JITCd output then being JITCd a second time? If so, how on earth does this make sense?
An alternative would be to explore whether the process level sandboxes are now good enough to just allow native code to run inside them and let people use their existing managed language VMs. Google thought that was close to plausible many years ago with NaCL, and kernel sandboxes got a lot stronger since then. It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.
Indeed. With the web's model, it seems tempting to make the browser cache do the work for you by putting the language runtime at a standard URL. That works, modulo the security features today that cache Wasm modules per-origin to avoid an engine JIT bug creating a cross-origin vulnerability. GC helps a bit with that in the sense that the GC algorithm itself moves down into the engine.
> 2. You need a JIT for performance.
I worked a bit on a prototype JVM on Wasm that used the Wasm bytecode format to encode Java constructs. That helps because then you don't have another bytecode interpreter running on level up, but ultimately you want somewhat more control over the JIT and the code it generates. Wasm engines supporting dynamic code generation at all (any finer-grained than a module) would help a lot there.
Compiling V8 whole-hog seems like it would take a lot of doing. In particular, it has JITs and an interpreter that want to spit out machine code. That'd have to be replaced with Wasm backends.
> It seems we ended up with WASM more due to Mozilla politics than what makes sense technically.
The politics were...complicated. I'd tell my side but it's probably best I don't.
Sadly that wouldn't work with standard libraries that heavily use monomorphized generics, like Rust and C++
Right but that's only one, niche use case (why you'd want plugins in a web page ?).
Even if you are web app with plugins
* that is not a problem for first load, user adds plugins later once they get familiar with the app
* you can still (I assume) just download it in the background and shove it into local storage
The whole use case seems to be "there is an app that would benefit from plugins and we don't want someone to learn the language just to write that plugin" and the idea is pretty sound - WASM embeds well and is fast enough.
Different languages have different GCs that are designed to work with their semantics. Some languages use a flag bit to tell the runtime if a value is stack or heap (Go, Ocaml), some languages allocate almost everything and assume a lot of short lived objects (Java)...
How well will a generic WASM GC really work here?
I’d like to point out also that providing users a million languages to write plugins in for a product could create a lot of bloat. Imagine an image editor with 5 plugins, each written in its own language running in WASM sandboxes: golang, C#, assemblyscript, ruby, python. That’s 5 runtimes each running it’s own garbage collection logic.
I can see the value for compute hosts because the very nature of the provided service is allowing users to write sandboxed apps. But I think for stand-alone applications it’s best to support one or two simple targets, whether sandboxed or otherwise.
There are languages (Lua for example) optimized for this already.
I suppose the benefit is that each application which uses the WASM backend can decide on their “official” language and provide a decent built-in IDE experience.
If the WASM runtime provides a GC, then all of those languages can share a GC.
The gist of the idea is polyglot languages can leverage libraries across many languages. The fastest code is the code that was already built (that you didn't need to write).
It's unlikely applications would actually implement libraries from 5 different runtimes (they could, but shouldn't), and if they use RUST libraries, there definitely wouldn't be any GC anyway.
The benefit of this tech is it allows a new language to leverage historical codebases quickly without needing to re-invent every common utility library.
This will inevitably speed adoption of newer languages, zero code tools, etc .. and is the epitome of Proebstings law, which could also accelerate Proebstings (which is every decade) to being to approach Moores law (but I'm not specifically saying that will happen, only that it could).
WASM already has a GC proposal[0] which is already at the "Implementation stage"[1] so it looks like this IS going to happen, although it's uncertain if language runtimes like Go will actually make use of the feature, or what.
[0]: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
[1]: https://github.com/WebAssembly/proposals
A glance of the overview and spec seems to indicate that WASM will provide some primitive data types, and any GC language can build their implementation on top of it. As I understand it, it's heavily based on Reference Types[3], which allows acting on host-provided types, and is already considered part of the spec [4]. It doesn't remove the need for the 5 different runtimes to have their own GC, but it lowers the bulk that the runtimes need to carry around, and offloads some of that onto the WASM runtime instead.
[3]: https://github.com/WebAssembly/reference-types/blob/master/p...
[4]: https://github.com/WebAssembly/proposals/blob/main/finished-...
https://groups.google.com/g/cap-talk/c/NSDM-05fEuU/
Extism seems like a great fit for this, I’ll definitely be checking it out :)
The other small point I'd raise: there's mention that due to the sandboxing of WASM it's "safe" to run untrusted code. Maybe I've misunderstood. To me that seems true in so far as the untrusted code cannot break out and can only do actions the hosting app decides to allow, but this isn't much consolation if the app allows actions that can be subverted.
For instance, if the app allows control over saving a file, untrusted code only gets to handle that within the rails the app sets but that still means dodgy code could fill up a hard drive by saving over and over, or it could possibly save over important files.
That's a great suggestion thanks!
> To me that seems true in so far as the untrusted code cannot break out and can only do actions the hosting app decides to allow, but this isn't much consolation if the app allows actions that can be subverted.
Yes i think safe is a relative term here. Any user input is "unsafe" to some degree. Your example is a good one! I think we wrote this in the context of other relative ways to do this but will be discussing better ways to talk about security and what Extism protects and what it doesn't.
Still, misleading headline aside, this sounds pretty cool as a reasonably well sandboxed plug-in architecture for software that chooses to use it.
Though if running in-process, it seems unlikely to be able to defend against hostile plugins that use e.g. speculative execution techniques to extract otherwise inaccessible data. But perhaps that's not the threat model here.
I must say, this sentence from their docs describe it the best to me: Greasemonkey for native apps
It has little to do with Extism, but still is interesting.
Turns out it's measured in pages of 64k each: "The units here are pages where a page is 64Kib." [1]
So max==5 apparently means a hard upper limit of 320 kB. (For when you want to run a 1984 copy of WordPerfect as a plugin, of course.)
Maybe a "max_MB" property might be more useful to plugin authors, and then just calculate the # of pages internally from that?
[1] https://extism.org/docs/concepts/manifest#schema
it's still a work in progress. the point about units is a good one. Might be a way to make that more clear.
yeah, that's something to consider. You can only pass in parameters that are a multiple of the page size so that may not be an accurate representation. I do think we need to hint at the unit in the name though.
We're both all in on extensible software powered by WebAssembly, but the scope and domains differ.
Suborbital is more of a turnkey / batteries-included service that handles the full lifecycle of extending SaaS applications with user-defined plugins. So it includes a web-based editor widget, a module builder service, storage and compute, administrative dashboards, etc.
Extism, from my lay understanding, is more tightly scoped toward being a great library for running WebAssembly modules, in the same way you might embed a Lua runtime into an application for user scripting.
Another big difference is that you can use all of Extism right now. Suborbital's hosted platform is still in closed beta :) (Waitlist at https://form.typeform.com/to/DHxjRGKx)
I just signed up for the waitlist! Looking forward to learning more about it.
Thanks for building this!
edit: For what it's worth, the use case and value of something like this was immediately apparent to me.
> For what it's worth, the use case and value of something like this was immediately apparent to me.
Thank you for saying so. Negative feedback doesn't bother me (I appreciate anyone taking time to speak up), but it's also usually the only kind you get on the Internet :) so we appreciate hearing that. Translating ideas into words is hard, especially in software.
(the concept became popular in the JVM world and lead to abominations like OSGi)
The problems that arose quickly were: - Executing order of plugins attaching to the same extension point.
- Third party library dependencies having different versions
- Traceability and debugging
- Thread-safety
OTOH, it gave our custom dev team to develop integrations and extensions that could be deployed and maintained independently of the main product. So there's definitely a use-case in there, but it requires some coordination regardless.
> (the concept became popular in the JVM world and lead to abominations like OSGi)
I remember this, though it was a couple years before my time. Although some of the underlying technology has changed those problems you outlined have remained the same. These things are all relevant to our next steps. We've been thinking a lot about what developer experience problems need to be solved.
The underlying runtime appears to be Wasmtime, an existing project that you can use separately.
For the system API, Extism supports WASI (a POSIX-like API for WASM) which is already supported by Wasmtime. However it sounds like it also has a different, non-WASI API that provides similar functionality. I'm curious to hear a compare/contrast between these two system APIs, or what motivated inventing a new non-WASI system API. It does appear that WASI is in its early days; WASI was announced in 2019 (https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...) but it appears that all of the specific proposals are still early stage and far from being standardized (https://github.com/WebAssembly/WASI/blob/main/Proposals.md).
For the API, Extism provides a C API/ABI that can be called through FFI, but AIUI Wasmtime already has such an API: https://docs.wasmtime.dev/c-api/
Basically I'm trying to understand the conceptual difference between this project and Wasmtime.
Because we wrap wasmtime, we can also switch it out. That's how we are able to run the same plugins in the browser. There we use the browsers' implementation.
I think one day we will replace some internal pieces of Extism with pieces of the Component Model spec. As of today it's not in a state where we can do all of this in this many languages.
edit: rewording, grammar
I'm Syrus, from Wasmer. I did a quick review of your plugin architecture and it looks great (tons of languages supported, congrats!). I think Wasmer might be able able to help you so you have the same implementation of the runtime inside and outside of the browser (something similar as we did in wasmer-js [1], where we reuse same WASI implementation, but using the native Wasm engine from the browser).
I'd love to see how we can integrate your plugins into Wasmer as well!
[1] https://github.com/wasmerio/wasmer-js
I'm trying to figure out if people really need compile to WASM/WASI -> run it back in a WASM runtime.
for JS in Node, we use wasmtime embedded within our runtime -- looking into what the tradeoffs are to re-implement the whole runtime in Node on its native WebAssembly runtime though. Feedback welcome & appreciated!
I can imagine every language compiling to the common format that is WASM, so you can mix and match libraries from other languages as you please, as well as chip manufacturers adding hardware accelerated WASM processing units if it gets popular enough.
This really is the birth and death of Javascript.
But it will be a powerful low trust portable VM, like none mainstream today. Odds are it kills Lua.
(And yeah, it removes the Javascript monopoly on the browser. At this point, it can't be killed, but it will shrink.)
As far as I know, people don't ship code to remote Lua VMs and execute it. There is no compatibility guarantee across versions, and there are nontrivial compile-time options (like what the number type is).
That doesn't mean Lua isn't useful; it's just not designed for the same things that WASM is.
So, you never used some software scripted with Lua? Or just never shared scripts?
Lua does have other uses, but the vast majority of it is as a low trust VM.
I think it has a good shot! If I'm hedging my bets though I'd say there are some things it will just never be good at. That's okay though it's not a zero sum game.
> This really is the birth and death of Javascript.
One thing I will not bet on is the death of javascript!
I'm curious, what would those be?
> One thing I will not bet on is the death of javascript!
Yep, I'm more so referring to the talk by Gary Bernhardt foretelling of a WASM-like platform emerging [0].
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Questions: 1. Can WASM plugins with Extism easily call back into host provided APIs? 2. Complex types are supported?
To answer your questions: 1. Extism provides a specific set of host provided APIs, and currently we don't have support for user-supplied host functions beyond the ones we make available. This will change though, and we're looking for feedback. We held off because there wasn't a clear way to make it easy across ALL the languages we support.
2. Complex types are definitely supported, you need to encode the data into raw bytes and can use whichever format you want (only limited by which formats are available in host & plug-in languages..)
Eventually we will move towards the Component Model which will make the complex types story much simpler.
* That's an absolutely viscerally horrifying logo
* I absolutely love it and its design
* I am confused about why it's used for a project like this and not some kind of internal NSA project, or maybe a nu-witch house band logo, or something
Thank you on all 3 points!!
I intended to invoke thoughts about how Extism enables one to "extend from within", thus the octopus crawling out from the skull. And also that the thing Extism should replace is rather cursed... loading DLLs / dlopen tons of plug-ins into your program to execute untrusted code is downright scary.
Not sure I would get the escaping from part by looking at a logo.
Another question... Is something like this possible on iOS or will these kinds of runtimes be banned by Apple?
> Would be nice if Unity games could start supporting wasm plugins
That would be pretty neat! I go back and forth over whether this kind of thing will happen or not. Extism's goal is to be very generic (universal). A game engine may have some competing goals like performance or predictability. Still, I wouldn't be surprised if some alternative engines didn't do this in the next few years.
> Another question... Is something like this possible on iOS or will these kinds of runtimes be banned by Apple?
Not today, but I think I know how to get there.
If you need this stuff for your project come join the discord and we can try to prioritize it!