Proposal to change WASI to stand for "WebAssembly Standard Interfaces"

[lukewagner]

As discussed in the WASI meeting today, the proposal is to change "WASI" to stand for "WebAssembly Standard Interfaces" (from "WebAssembly System Interface" today). This reflects two important properties of WASI: (1) it's virtualizability, such that interfaces do not need to be implemented by the system to be valuable for standardization, (2) it's modularity, such that not all hosts need to implement all interfaces. Credit to this proposal goes to @ospencer, who had the idea around a year ago, and it has been circulating around since. Most folks I talk to seem to quite like the idea and noone raised any objections in the meeting today, so this issue is mostly just raising visibility before there is a poll in the next meeting to go ahead and make the change.

[stuartpb]

Just throwing this idea out there: if "WASI" is expanded to be a general collection of standardized interfaces, then would the WASM-4 API qualify?

[lukewagner]

Without knowing much of the context, I think it could. Note that, even without being standardized, the tooling infrastructure used by WASI (viz. WIT and its associated bindings generators in a growing set of languages) is available to all interface authors, standard or not. Thus, the reason to undertake the time and effort to standardize an interface in WASI is not to get bindings in a bunch of languages (you sortof get that for free from the Component Model), but to encourage a variety of interoperable implementations. Thus, I expect what the subgroup would want to see is a collection of distinct clients and implementations interested to use/implement the interface. But with sufficient stakeholders established, yeah, totally.

[woodsmc]

I understand the rational behind the proposed name change, I accept @lukewagner and @ospencer logic. I would go further, as the name change better reflect the facets of the Component Model, and gives credence to the concept of standardizing non-system interfaces, But I don't think this is the right move,... right now... later, yes, but, please, not right now. Can we pause this, and come back to this question as we approach WASI v1 ?

I am worried that a name change now would have the unintended consequence of driving people away from WASI and WASM in general.

The vast majority of software development is conducted on pre-existing code bases. These developers need a way to bring their code, and their products to WebAssembly. The majority of this code expects a source compatible, stable POSIX like interface. For WASI this means a binary compatible POSIX like interface across multiple platforms. The truth is we are at preview1, and looking at adopting of a new binary interface for preview 2 - so we just don't have that right now. "We are where we are". Having said that, I know that there are a lot of people working hard on the critical task of system interface stability, it is important that we advertise their incredible work to the community at large.

I have spoken to several people who've pointed at system interface stability as a core reason to not adopt WASM at all. These people point out the changes coming with preview 2, the fluctuation in system interfaces today, how different runtimes have added non-standard extensions to provide for missing functionality, how the resulting *.wasm files aren't universally compatible. Something that should be addressed by and large with wasi::cli. These same people are highlighting that there are other teams who claim to have system interface stability.

Let me quote from an article from back in 2019, from The Register: Mozilla tries to do Java as it should have been – with a WASI spec for all devices, computers, operating systems

"Code outside of a browser needs a way to talk to the system  –  a system interface," explains Mozilla software engineer Lin Clark in a blog post. "And the WebAssembly platform doesn’t have that yet."

I think once was::cli included with preview 2 is out of the door and we can demonstrate portability, we can look again at the name change, which would, at that time, be more than justified for reconsideration.

[ttrenner]

I am not that concerned about the naming. But I am quite concerned about its implications.

Just to highlight @woodsmc 's 4th paragraph : If the system interface is continuously subject of change, it is hard to argue to use it at all, especially for long lasting systems in the embedded domain. Who knows, whether an existing wasm file will also run on an updated embedded device with another wasm runtime, that uses another WASI? Backward compatibility is an important thing. If it's not there, it puts the polyglot property at risk. Yes, backward compatibility is a big pain for moving forward. But I cannot remember on successful SW (stacks) that break with existing installations on and on.
It could turn out, that WASI will not be used in embedded scenarios as long as there is no stable WASI 1.0. This indeed puts more pressure on R&D efforts, because without a "system interface", wasm is just a calculator. And that could result in not using it at all.

[lukewagner]

Thanks Chris, that's really helpful feedback. So, to summarize my understanding, your point is that, at this moment, the name change might create more confusion than necessary and that we'd avoid this by waiting for Preview 2 to ship more widely. That sounds fine to me; I only put it on the agenda b/c it seemed like everyone already agreed and it's nice to align docs with reality. But this isn't a pressing issue to address, so I'm happy to wait and bring this up in half a year.

But just to be clear about the proposed name change and its implication: WASI still very much is concerned with defining stable, backwards-compatible interfaces that are implemented natively by systems. It's just that the path to these stable interfaces requires some breaking iteration based on feedback and the better understanding of the problem space that comes with implementation experience.

[pchickey]

In response to @ttrenner, I will clarify what what "breaking" means in the context of changes. The Preview 2 to Preview 3 iteration will permit changes to interfaces, so long as it is possible for all Preview 2 programs to run on Preview 3 interfaces by way component virtualization (often we call this an "adapter"). This is the same guarantee as we provide today for Preview 1 modules to run as Preview 2 components by way of the Wasmtime project's wasi-preview1-component-adapter. Stability is provided for the authors of WASI programs where old binaries will work on newer iterations of the interfaces. Those authors can opt into improvements in the interfaces, and new capabilities, by adopting the new interfaces directly, but if they do nothing their existing code keeps working.

The component model permits us to use this compatibility strategy where legacy interfaces can be provided fully virtually (meaning, implemented fully in Wasm using component composition), instead of requiring that the concrete host implementation offer both the latest interface as well as implementations of all of the obsolete interfaces.

If you are shipping an implementation of WASI, rather than shipping programs that use WASI, this compatibility story can be a tremendous advantage because it allows you to delete legacy implementations and ship all of your compatibility using sandboxed Wasm code rather than native code.

But ultimately this whole virtualization or adapter story is just an implementation detail: users who write programs for running in WASI never have to know it exists. Their WASI preview 1, preview 2, preview 3 programs will all keep running after Preview 4 or 1.0 or whatever comes out. Backwards compatibility can be provided by platforms, no problem. We know how important that is to platform providers and their users, implementors are committed to providing it, and as a spec we will make sure we don't break the possibility for backwards compatibility to be implemented this way.

If you are shipping a WASI implementation for embedded that you will not be able to update, but will need to ship new WASI programs to beyond when a newer WASI interface is standardized, you will need to limit the authors of WASI programs for your embedded system to target the same WASI version you shipped, and not take advantage of newer version features. This is the same story as with any other virtual machine or SDK out there, whether plain Linux, Android, Java, CLR, iOS apps, the Web itself, etc. - if your program authors need to deploy to systems using less than the latest interfaces, they will pin their SDKs to use an older set of interfaces, and it will run on the very oldest systems out there plus all of the other newer ones.

[woodsmc]

Thanks Chris, that's really helpful feedback. So, to summarize my understanding, your point is that, at this moment, the name change might create more confusion than necessary and that we'd avoid this by waiting for Preview 2 to ship more widely. That sounds fine to me; I only put it on the agenda b/c it seemed like everyone already agreed and it's nice to align docs with reality. But this isn't a pressing issue to address, so I'm happy to wait and bring this up in half a year.

But just to be clear about the proposed name change and its implication: WASI still very much is concerned with defining stable, backwards-compatible interfaces that are implemented natively by systems. It's just that the path to these stable interfaces requires some breaking iteration based on feedback and the better understanding of the problem space that comes with implementation experience.

Awesome Luke, you nailed it. Thanks for the understanding. I completely understand the WASI team's rational for the proposal and suggestion as once the POSIX / LibC Systems like interfaces are locked down the vast majority of the effort of the group will be in the wider world of the component model and its ecosystem - and yes, the name change then would be perfect. In the more immediate future as folks are still brining their legacy code to WASM they will need a system interface and preserving that name will help with discovery and adoption.

[woodsmc]

@pchickey Thank you for the extra context on stability and adapters - this is awesome:

But ultimately this whole virtualization or adapter story is just an implementation detail:

For our use cases we'd need to understand the implementation concept - I know this is off topic for the issue, so I suggest we take this up together separately / via an offline discussion.. Thanks again for the support.

[RReverser]

Aside from waiting for stability, such naming seems like a slippery slope.

I understand that for those of us who work with WebAssembly on the server or in CLIs, those APIs might already be the standard interface. But for those who work with WebAssembly on the Web, such naming would only create unnecessary confusion when learning Wasm and trying to google e.g. interfaces for interacting with DOM - which, on the web, is the standard interface / API for communicating with outside world, even though it currently requires various binding systems.

I'm aware that there are various WASI polyfills for the browser as well (having written one myself in the past), and I appreciate WASI for what it is, but, given the entirely different feature set it covers, I don't see it becoming the primary standard API for WebAssembly applications on the Web anytime soon.