WebAssembly Gateway Interface (WAGI)+IPFS

When I first came across WebAssembly, I was already aware of the IPFS project, and immediately thought that the two would work well together. Specifically, I thought that WebAssembly modules stored in IPFS could be loaded automatically by an edge web server to allow for dynamic content without a centralized server and without requiring IPFS on the device utilizing the service. The latter is important for supporting legacy devices and services that cannot be updated.

At the time, I was also trying to use WebAssembly in any manner and failed to do so, in large part because it wasn’t ready for use. The tools were very immature, browser support was present but at the toy level, and the documentation and tutorials to get people started didn’t exist. I tried writing a virtual machine to test the idea, and while it did work, I dropped it shortly thereafter.

Now, I’ve starting taking another look at the idea. WebAssembly has advanced considerably. It was relatively easy to get a development environment setup and I could get a hello world program running in less than a day. It is far enough along that I am paying close attention to what is going on in the space, so when I came across WAGI, I was rather excited because it was almost exactly what I was trying for before.

WebAssembly Gateway Interface (or WAGI) is a prototype-level project that combines WebAssembly binaries with a webserver and uses an interface nearly identical to the much older Common Gateway Interface (CGI) from the beginning of the interactive web. The WAGI server is explicitly labeled as experimental code, so if you try it out, expect problems.

The way WAGI experiment is setup requires trusting that the code being run will not use excessive CPU, which doesn’t mesh with the idea I had, which is completely untrusted code with an explicit time limits for a given request, and a maximum CPU time per day to prevent abuse (unknowing CPU mining cryptocurrency).

The gateway server I envision would use a pre-forking design. When a request is made to the gateway, the wasm module is loaded if needed, then passed to a forked process if the total CPU time for the day has not been exceeded, otherwise 5xx error. If the process does not finish within the request timeout, the child process is forcibly killed (kill -9), an 5xx error is returned, and a new child process is launched. Wasm modules would be initialized in the server process, but never run there. The modules in the child processes would either reset memory, or discard the module after use. The modules would have access to a IPFS mutable file system directory accessible thru the WASI API.