andreaTP (Jun 01 2026 at 16:59): andreaTP (Jun 01 2026 at 16:59):Since the announcement of Endive, several people have reached out expressing interest in contributing Component Model support.
I’ve opened this repo to help facilitate the conversation and give the community a place to quickly iterate on a prototype: https://github.com/roastedroot/endive-cm
Anyone interested is very welcome to join and contribute!
Zachary Whitley (Jun 01 2026 at 22:06):@andreaTP Congratulations on Endive! I have a project that I'm working on that will have a interesting use for Endive especially if it supports components.
Zachary Whitley (Jun 01 2026 at 22:08):I noticed you gave a shutout on the endive-cm page. Thanks
Shusek (Jun 03 2026 at 16:25):I've been testing chicory/endive recently to create a plugin system for a player similar to Kodi, only based on security, and so far it looks really promising. Component Model looks really promising, i could harden the SDK on WIT bindings.
andreaTP (Jun 03 2026 at 16:31):CM support is barely started, all the help is welcome!
Jeremy Grelle (Jun 10 2026 at 15:17):@andreaTP Thanks for setting up this initial repo, it's a great jumpstart for getting things moving. The development phases you've outlined are really helpful.
If nobody else already has it in progress, I'd like to go ahead and get started on the type model, parser, and some supporting parts of the wasm-tools component commands (I think validation in particular). I've already got a version of all of these in progress in a private experimental repo that takes a slightly different approach, and it should be a fairly straightforward task to port the code over to fulfill the patterns that you've outlined and transform it to a more "endive native" approach. I would try to do this in somewhat of an incremental manner in order to keep PR sizes reasonable.
To facilitate this development, I think it would also be useful to go ahead and set up some spec testing infrastructure, incorporating wast tests from https://github.com/WebAssembly/component-model/tree/main/test - I'll take a deeper look at the spec testing infrastructure in the main endive project and see what can be re-used and what patterns can be replicated.
andreaTP (Jun 11 2026 at 09:38):Hi @Jeremy Grelle sorry for the delay, great to see you around!
The development phases
Feel free to iterate on the document, it's just an initial plan.
If nobody else already has it in progress
Please go ahead, and thanks a lot!
incorporating wast tests
That's a great idea! Feel free to add it very very early to the plan.
In endive we are generating unit tests and assertions out of the wast files, feel free to replicate/re-use as much as possible the infrastructure.
Jeremy Grelle (Jun 19 2026 at 14:39):Very much still a work-in-progress, but I've gone ahead and pushed the beginnings of this work to a branch in my personal endive-cm fork:
https://github.com/jeremyg484/endive-cm/tree/types-and-parser
I've basically set up just enough plumbing and infrastructure to make progress on the type model and parser, and have thus far implemented component validation (via wasm-tools) and the parsing for a decent chunk of the <core:type> section.
@andreaTP I see two different ways of proceeding and wonder if you have a preference?
andreaTP (Jun 19 2026 at 14:45):Hey @Jeremy Grelle ! Thanks for the help, I skimmed through and I like it!
I think the size is great for a first PR
Shusek (Jun 19 2026 at 19:21):andreaTP napisał:
CM support is barely started, all the help is welcome!
I'm currently processing the entire runtime, as you can see. Unfortunately, I needed cross-platform support, so Maven and Java were no longer an option.
https://github.com/Shusek/kotlin-runtime-web-assembly
andreaTP (Jun 19 2026 at 19:27):Chasm is an interpreter focusing on kotlin multi-platform support: https://github.com/CharlieTap/chasm
Zachary Whitley (Tegmentum) (Jul 15 2026 at 19:56):Were you planning on adding CM support directly to Endive or layering it on top? I might be able to spare some cycles for that effort.
I'm still not quite ready to release it yet but I successfully got my JDK running under webassembly with wasmtime4j and Endive. It's a Java running in Wasm running in Java using Endive. I was able to sandbox log4j with facade jar and demonstrate that it successfully protects against the log4shell cve. In addition it's able to log any attempt to access denied capabilities that provide a signal of attempted compromise. Initial testing shows a modest 16% overhead.
It runs with a full JIT but doing it is a little rough without the CM.
andreaTP (Jul 15 2026 at 20:01):CM support started here:
https://github.com/roastedroot/endive-cm
It will eventually move to the main repo, so the plan is to add direct support in endive.
Looking forward for a blog about this exploration!
Jeremy Grelle (Jul 30 2026 at 17:35):Thought I should give a quick update here on what I've got in progress and what is coming imminently...
My plan is to break up the work I've been doing the last couple weeks into 3 sequential PRs to make it manageable (it's a big chunk of code :sweat_smile:)...one straightforward one for more of the Canonical Operations parsing in preparation for eventually implementing the async stuff and other bits, one for the low-level ABI lowering/lifting, and another tying everything together in runtime.
The 3rd one will introduce the most visible change, as it will include some enhancements to the test suite to include actual component instantiation as a step for all of the (component) style test cases (as opposed to (component definition) which will continue to only invoke the parser and not instantiate). I turned that on in my branch for all of the existing enabled tests and it helped me to fill in quite a few holes. Depending where things stand at that point, that PR might be a good time to go ahead and incorporate the most recent changes to the component-model test suite. I will just pin to an earlier commit in the two prior PRs.
Once that 3rd PR gets merged, we should have all of the basics of component instantiation and sync component function invocation with lifting and lowering support for all component model types up to and including resource. I'm leaving the appropriate space and creating skeleton types where necessary for the eventual implementation of the async semantics, which I would probably start to tackle next.
andreaTP (Jul 30 2026 at 18:16):Thanks for the update @Jeremy Grelle !
Looks like an amazing plan, looking forward to the PRs :slight_smile:
Jeremy Grelle (Aug 10 2026 at 03:03):Time for another quick update...
I got a little carried away with enabling more and more of the spec tests and making the way we implement their checks a bit more thorough. :sweat_smile:
The net result though after another weekend of hacking, is that the current state of my active working branch is:
Tests run: 1173, Failures: 0, Errors: 0, Skipped: 7
Most of those are spec tests. I now have all of the tests enabled and passing except for those in async and values...so basically pretty close to a WASI-p2 state of the Component Model.
We got the first of my above 3 outlined PR's merged at the start of this past week, and my plan for the other 2 remains the same...I will basically split the diff from my above branch into two separate PR's. I'll put up one for the added canonical-abi module first, and then another for the runtime work that ties everything together. Before doing so, I need to make another pass through the code to do some cleanup...mostly naming and extraneous comment noise from the places where I've let AI do the repetitive mechanical bits. Hoping to get that done in the next couple evenings and have the first of these other 2 big PR's up mid-week.
andreaTP (Aug 10 2026 at 10:04):Hey @Jeremy Grelle thats great to hear!
pretty close to a WASI-p2 state of the Component Model.
Seems like it's almost time to start experimenting with real-world modules, do you have a few links of wasi-p2 upstream project that we can start throwing at it? (and maybe testing in CI too)
the next couple evenings and have the first of these other 2 big PR's up mid-week.
I'm currently a bit travelling/kids/etc. but I'll try to catch up with reviews asap!
All in all, you are doing an amazing job Jeremy, let me know if I can do anything to better support your effort, and we need to start thinking about next steps (I believe we can start releasing with P2 available, no need to have a full P3).
FYI, I started hacking together something for OCI compatibility: https://github.com/andreaTP/inlay will release soon, and it should :crossed: enable approaches similar to wasmCloud and Wasette.
Jeremy Grelle (Aug 10 2026 at 11:40):Seems like it's almost time to start experimenting with real-world modules, do you have a few links of wasi-p2 upstream project that we can start throwing at it? (and maybe testing in CI too)
Well, first keep in mind that this is really just the baseline for being able to implement the actual WASI interfaces on the host side. As a means of implementing them, we would need to focus on figuring out and making use of a nice way of consuming and binding to WIT definitions on the host side, which I haven't really touched implementation-wise yet. Note that the support for some of the higher level types like Records is currently pretty rudimentary...I just used Maps as a starting point there, figuring we can evolve an approach to mapping more typical Java objects on top of that as we figure out the WIT bindings.
I'm currently a bit travelling/kids/etc. but I'll try to catch up with reviews asap!
Enjoy your time, no worries and no rush! I'm about to enter a hectic period of a few weeks where the demands of my "day job" could extend more frequently into evenings, which is one reason I've been pushing to get to this point.
FYI, I started hacking together something for OCI compatibility: https://github.com/andreaTP/inlay will release soon, and it should :crossed: enable approaches similar to wasmCloud and Wasette.
Awesome! I would bet @Mark Fisher will be very interested in looking at that.
andreaTP (Aug 10 2026 at 12:40):As a means of implementing them, we would need to focus on figuring out and making use of a nice way of consuming and binding to WIT definitions on the host side
Right, if you have any note/investigation on how to get there please share :pray:
andreaTP (Aug 10 2026 at 12:41):I'm about to enter a hectic period
I see, thanks for the heads up, and thanks a lot for your commitment!
If you start to be short on time, feel free to open half baked PRs and I'll try to catch up :-)
Jeremy Grelle (Aug 25 2026 at 16:41):A quick update for anyone following along that the planned giant runtime PR is now up: https://github.com/roastedroot/endive-cm/pull/38
Once that gets merged, I think the next steps should probably be to start on bindgen support and a WASI p2 implementation, as mentioned above. I think that warrants a separate discussion thread which I will start when I get a moment.
andreaTP (Aug 26 2026 at 14:14):Thanks a lot @Jeremy Grelle ! I'll try to have a look sometime soon, but I'm a bit swamped too
Last updated: Aug 30 2026 at 09:07 UTC