Support for identifying the guest making a host call · wasmtime

Stream: wasmtime

Topic: Support for identifying the guest making a host call

Eduard Smet (Celarye) (Jan 30 2026 at 18:38):

Continuation of #wasmtime > Getting component information on host calls.

I would personally like for Wasmtime to support identifying the guest which is making a host call.

I have not been able to think of a different way to resolve this besides maybe providing some key (like a UUID) to the guest which they must provide when making host calls but I find that to be quite dirty as I don't want to put the burden on the guest.

Some of my use cases are:

I will run an unknown amount of plugins all with different permissions. I need to make sure a callee has the permission to do some action.

Example: Some plugins may be allowed to shut down the whole applications while others don't, this is configurable at runtime by the user. To solve this I have made a shutdown host function but I need to be able to verify that the callee has the permission to actually initiate this.

Plugins may (un)register some (recurring) tasks at an arbitrary time, I want to solve this via host functions as well. Then again I need to be able to map the task to the right plugin so that I can send the result of the task to right plugin.

To go a bit more in depth into this issue. I currently solve this by having an initialization guest function which I call at the start of my program and ask for all task registrations then. But I've noticed that this doesn't fully solve it and that I instead want support plugins (un)registering tasks at any time.

I think that generally there are a lot of other use cases for plugin based systems besides the above.

Let me know what your thoughts are on these use cases.

cc @Alex Crichton

Lann Martin (Jan 30 2026 at 19:09):

Does each guest have its own Store?

Eduard Smet (Celarye) (Jan 30 2026 at 19:11):

Yes, but down the line a plugin will have multiple stores as a bunch of events will initiate a call to the same plugin. The store will then also be dropped at the end of the call.

Lann Martin (Jan 30 2026 at 19:33):

Recentish wasmtime lets you optionally bindgen host function signatures where the function will receive a reference to the Store. You can embed some identifier in the store's data (inner T).

Lann Martin (Jan 30 2026 at 19:33):

This is also possible in older wasmtime but slightly more complicated.

Eduard Smet (Celarye) (Jan 30 2026 at 19:36):

I guess that will indeed solve my issue in a cleaner way than adding a key as parameter. Could you perhaps point me to the relevant bindgen option?

And is this invisible to the guest?

Lann Martin (Jan 30 2026 at 19:38):

https://docs.rs/wasmtime/latest/wasmtime/component/macro.bindgen.html
Search `store` flag

Lann Martin (Jan 30 2026 at 19:39):

Yes, invisible to the guest

Eduard Smet (Celarye) (Jan 30 2026 at 19:40):

Then I guess that if I can get this to work that my issue can be considered resolved. Although maybe the topic itself is not resolved per se, depends if someone else has something to add to it.

Eduard Smet (Celarye) (Jan 30 2026 at 19:42):

You could also consider this as a solution to it I guess and it would probably be a good thing to explicitly document it somewhere (e.g. Component Model book) like that as well.

Lann Martin (Jan 30 2026 at 19:43):

Well, the solution is somewhat Wasmtime-specific, and we sometimes refer to this kind of approach as "host magic" which we try to avoid for general-purpose interfaces, but I think it is reasonable for a plugin system

Lann Martin (Jan 30 2026 at 19:47):

Another approach that might work here would be to return some resource type when you register a task. Resource access is enforced by the runtime; a component (instance) cannot do anything with a resource unless it has been explicitly passed a handle to it.

Eduard Smet (Celarye) (Jan 30 2026 at 19:54):

Lann Martin said:

Well, the solution is somewhat Wasmtime-specific, and we sometimes refer to this kind of approach as "host magic" which we try to avoid for general-purpose interfaces, but I think it is reasonable for a plugin system

I am not planning on switching away from Wasmtime or to support other runtimes so I think I should be in the clear for using this.

Eduard Smet (Celarye) (Jan 30 2026 at 19:54):

But maybe we wouldn’t want Wasmtime specific solutions in the Component Model book?

Eduard Smet (Celarye) (Jan 30 2026 at 19:56):

Lann Martin said:

Another approach that might work here would be to return some resource type when you register a task. Resource access is enforced by the runtime; a component (instance) cannot do anything with a resource unless it has been explicitly passed a handle to it.

Can you perhaps link an example, as my understanding on how to use resources is quite limited as well.

Eduard Smet (Celarye) (Jan 30 2026 at 19:57):

Although I can’t even imagine how use case one would look with this.

Eduard Smet (Celarye) (Jan 30 2026 at 20:01):

Lann Martin said:

https://docs.rs/wasmtime/latest/wasmtime/component/macro.bindgen.html
Search `store` flag

I found it in the docs and it reminded me how the async keyword in WIT files enables this as well, do you perhaps know the reason for that?

Lann Martin (Jan 30 2026 at 20:06):

It's hard to give specific design advice without details but based on your description I could imagine something like this:

interface plugin-registrar {
  register: func() -> registered;
}
resource registered {
  unregister: func();
  shutdown: func();
}

Where plugins would import plugin-registrar from the host.

Lann Martin (Jan 30 2026 at 20:08):

I guess you'd still need something in the Store with this specific design. Again, hard to say without more context.

Eduard Smet (Celarye) (Jan 30 2026 at 20:24):

I am going to give the Store solution a try first

Alex Crichton (Jan 30 2026 at 21:23):

I can chime in to basically just second everything Lann said, putting data in the Store, with a plugin-per-store, is a key feature of how to model an embedding in wasmtime

Eduard Smet (Celarye) (Jan 30 2026 at 21:29):

Alright thanks a lot for the support again. Just so they don’t get lost I think these questions are still nice to see answered:

Why does the async keyword in WIT files include the Store context to host functions by default?
Would a short section in the Component Model book on a design pattern like this be interesting? If so, I would love to contribute that once I’ve successfully implemented it. As I would say that it makes quite a significant positive change to how I will implement things.

Alex Crichton (Jan 30 2026 at 21:35):

For the async keyword, that's more or less a bug in wasmtime. There are subtle reasons why it's the case, but the short reason is that it's the only way wasmtime supports

Alex Crichton (Jan 30 2026 at 21:35):

For expanding book documentation, I think that would be great!

Eduard Smet (Celarye) (Jan 30 2026 at 21:36):

Alex Crichton said:

For the async keyword, that's more or less a bug in wasmtime. There are subtle reasons why it's the case, but the short reason is that it's the only way wasmtime supports

"Feature bug" by now or something that'll get fixed (if possible)?

Alex Crichton (Jan 30 2026 at 21:39):

Hard to say unfortunately. It's an artifact of trying to reconcile "old async" in wasmtime which is invisible to the guest and allows no concurrency with "new async" which is visible to the guest and allows concurrency. The component async keyword implies behavior in the guest which if the host wants to faithfully represent requires the signature with the store right now. An alternative is basically unknown at this point but something I want to tackle because I don't want wasmtime to indefinitely have two async systems in effect

Last updated: Feb 24 2026 at 04:36 UTC