Yay! The in-progress wasi:i2c proposal (WASI spec for embedded devices) just moved to phase 2!
This means it's not just something promising anymore, but it seems ready to be implemented in host systems and begin gathering implementation and user feedback from.
I'm legit very excited about this! — But this seems like it has a real shot at improving the embedded development experience. Virtual platform layering, local platform emulation, standard APIs, etc. etc. I'm into it!
A question for the WASI folks: what is the value proposition of WASI?
For edge compute, threading, synchronization primitives, and polling (a la select/poll/epoll/etc) would be nice, but I feel like a lot of the other APIs wouldn't be very useful.
For more general server-side stuff, why wouldn't I just run native binaries directly?
Note that I'm operating under the assumption that WASI is for server-side work.
@noah For edge computing, it's less about POSIX files&sockets and more about APIs like wasi-http,, wasi-keyvalue, etc.
For cloud computing, motivations include being able to run many Wasm instances in a single host process, architecture independence, lightweight virtualizability, and composition.
I'd love to get someone's opinion on this but I believe a lot of these instructions don't need to be canonicalized. Differences between NaNs don't seem to be internally observable in the Wasm model of floats until a float is stored back to memory or bitcast to an integer at which point the particular IEEE-754 bit pattern becomes observable. E.g. sNANs are non-trapping and there's no fetestexcept() equivalent.
This gives a lot of people the possibility to begin using a platform with components that they already know and love -- and it gives the ability to target any arch or os with one "artifact". multiarch builds goes away here.
@squillace A key achievement of this spec is that a Wasm component in an OCI registry is conceptually still a component, rather than a wrapper that modifies the semantics of a component.
Among other things, this means that artifacts in OCI registries can continue to participate in component composition.
what have I been up to? well, hm, good question, let’s see.
I’ve been pushing along a wasm runtime in rust — with something like half of the core test suite passing now — which has been instructive (pun. intended.)
I’ve also been absolutely tanking this book, “empires of the word”, which examines different lingua franca through the years. It’s very dry but also very interesting?
A subtlety about capability-based security in Wasm components is that there is no "ambient authority".
There are functions with no arguments that return handles, which at first glance looks like classic ambient authority.
But, all functions are interposable at link time. So users can wasi-virt or wac or other mechanisms to link a component to whatever they want, and attenuate or redirect the function however they want.
So instead, we say those functions use "link-time authority".
@oborosaur Perhaps: implicit access to an external resource.
It's subtle, because if you think about something like a Unix process, we often talk about an "ambient authority" to open files in a filesystem namespace, but technically, many Unix-like platforms have added ways to run processes in alternate filesystem namespaces, or attenuate things with ACLs or seccomp, or so, so it isn't truly implicit, meaning it isn't truly ambient.
@oborosaur Ultimately, even though the phrase "ambient authority" is well-known in some circles, I think the Principle of Least Authority (PoLA) is the more interesting concept to focus on.
PoLA is all about granularity. Ideally, don't grant monolithic access to anything, and don't grant any access to monolithic things. Build modular systems and grant fine-grained access to the modules that need it.
And handles are a really great tool for doing that. But not the only tool.
The Principle of Least Authority is a more informative way to describe systems, and from that perspective we see things like:
seccomp is complex to set up for non-trivial tasks, so it isn't used as often as it theoretically could be,
Child processes tend to be inconvenient to work with, and processes are pretty heavyweight, so applications tend to use a single process for everything, so authorities are often granted to parts of programs that don't need it.
@sunfish Hi! I hope I'm not disturbing - but I wonder if you could point me towards somewhere I can ask for help with e.g. using wit-bindgen in a personal project. I've found the Bytecode Alliance zulip - is that suitable for newbie queries, or more for those developing the tools? Thanks!