Waxosuit is a secure WebAssembly runtime environment for enterprise-grade, cloud-native applications with a focus on productivity and developer experience. It is a small application that loads a guest module (any wascap-compliant Wasm file) and securely binds it to a suite of cloud native capability providers that are dynamically loaded as plugins.
WASI, WebAssembly System Interface is a standard that essentially takes low-level, libc type calls and replaces them with WebAssembly imports. The types of system calls that are currently covered by WASI are things like file descriptors, sockets, file paths, environment variables, and a handful of others. This means that anything “compiled for WASI” will rely on a host runtime to satisfy these system calls. Wasmer and several other host runtimes are “WASI compliant”.
Waxosuit uses wasmer as a host runtime, but it does not allow WASI calls or any other system calls. In short, Waxosuit does not and will not violate the WebAssembly sandbox. WASI-compiled WebAssembly modules have direct, unfettered system access, and one of Waxosuit’s main tenets is providing a secure, capabilities-driven sandbox in whic WebAssembly modules run.
Waxosuit can run anywhere you can run a compiled binary. It is optimized for running in the cloud, but you can run it on your development workstation/laptop, in Docker compose, inside a single Docker image, within Minikube, Critical Stack, Kubernetes, or any other container scheduler.
As long as the capability providers can satisfy their pre-requisites (e.g. connection to a message broker, database, etc), then Waxosuit will run just fine. Developer flexibility and ease-of-use are core to Waxosuit’s mission.
Yes! Waxosuit can host a WebAssembly module anywhere the small waxosuit process can run. Waxosuit is designed from the ground up to be cloud native and to work seamlessly from inside a Docker image. You can use Kubernetes to create a deployment that executes the Waxosuit binary and loads a WebAssembly module either pulled from a container-mounted volume or from a Gantry (Under Development) repository.
Yes! A Knative function is really just a service that launches, exposes an HTTP endpoint, and reacts to incoming web requests. Knative manages scaling this service to zero (no running copies) or up to however many copies you want to run. Waxosuit might have a slightly higher cold start time (at least in its current infantile development stage), but once warmed up will execute at native speeds and can handle whatever workloads you throw at it.
In order for your Wasm modules to work with Knative, they must be granted the wascap:http_server capability when signed.
In short, no. Waxosuit is an implementation of a set of standards. Firstly, these standards form a foundation for securely signing, verifying, identifying module provenance, and validating capability claim attestations. Secondly, these standards describe the means by which the host runtime and the guest module communicate, which we analagously refer to as “protobufs over Wasm FFI”
Waxosuit’s Rust implementation does include a Guest SDK, which is a small framework that encapsulates the low-level protocol buffer communication protocol in a way that makes the developer experience of building guest modules easier, simpler, and more ergonomic.