Does Wasmtime provide too many interfaces for the `proxy` world?

[alexcrichton]

The current definition of the proxy world has a TODO which indicates to me that it's known that there are more interfaces there than there should be. The Wasmtime implementation of providing imports for proxies however delegates to the command module which provides lots of interfaces, some of which aren't listed in the proxy world such as:

• wasi:filesystem/{types,preopens}
• wasi:cli/{exit,environment,terminal_*}
• wasi:sockets/*

This is an issue which poses the question about what to fix here. Should Wasmtime's definition be trimmed down? Or should the proxy world grow more imports?

[lukewagner]

I think it's fine and even expected that each concrete host will provide a superset of the WASI-standard worlds that the host supports. I could however imagine adding a runtime flag to Wasmtime that says "restrict yourself to world X" (where X could be "wasi:http/proxy" or "wasi:cli/command" or, in the future with registry integration, any published world) and this would be valuable for two reasons:

1. developers could test that the component they produced indeed only depends on the target world
2. wasmtime CLI users get a nice succinct way to control the capabilities provided to the component they want to run, analogous to the permissions feature of deno

If you had this feature, there is still a question of defaults and whether, by default, wasmtime serve enables everything or just some default world, but that's separable.

Thus, I'd propose that the answer to your question is that wasi:http/proxy stays as is (and in a P3 timeframe deletes those imports tagged with TODOs).

[alexcrichton]

I think it makes sense to be configurable yeah, but I'd naively at least expect that wasmtime serve matches an exact WASI world which can be referred to. Currently that's not the proxy world because of the missing interfaces I mentioned above. So this is sort of a question for should those interfaces be added to the proxy world? Or should they be removed from wasmtime serve by default to be enabled with an opt-in flag?

[lukewagner]

I could imagine defining a wasmtime:serve/default world that includes wasi:http/proxy and adds whatever else, and you could say "this is the world that is targeted by default". I think this matches what most production embeddings of Wasmtime would do, s/wasmtime/company-name/, so we could think of wasmtime as just the generic/vanilla example of this.

[alexcrichton]

I've opened bytecodealliance/wasmtime#7597 to address the Wasmtime side of this.

[alexcrichton]

I'll also close this since this is a Wasmtime issue, not a spec issue.