# Introducing WASI for IC
**URL:** https://forum.dfinity.org/t/introducing-wasi-for-ic/18583
**Category:** Developers
**Tags:** Discussing
**Created:** [February 19, 2023, 11:46am UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583 "2023-02-19T11:46:49Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 19, 2023, 11:46am UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/1 "2023-02-19T11:46:49Z")
Hi all,
My name is Stan. I wanted to announce that I have started working on the WASI support for the IC under the Developer Grant Program.
# Background
WebAssembly System Interface (WASI) is emerging as the standard target for compiling WebAssembly (Wasm) programs. WASI provides a set of functions to access system resources such as the file system, network, and environment variables regardless of the underlying operating system. This allows Wasm programs to be run in a variety of environments, including the web, cloud, and embedded devices.
Many popular programming languages, including [JavaScript](https://wapm.io/mozilla/spidermonkey) (SpiderMonkey engine), [Python](https://wapm.io/python/python) (CPython), [C++](https://medium.com/wasmer/wasienv-wasi-development-workflow-for-humans-1811d9a50345), [Go](https://wasmbyexample.dev/examples/wasi-hello-world/wasi-hello-world.go.en-us.html) (TinyGo), [Haskell](https://www.tweag.io/blog/2022-11-22-wasm-backend-merged-in-ghc/) (GHC), [Swift](https://github.com/swiftwasm/swift), and [Ruby](https://wapm.io/katei/irb), support WASI as a compilation target. A popular database [Sqlite](https://wapm.io/sqlite/sqlite) can also be compiled to WASI.
# Project Description
The goal of the project is to use the IC’s System API to implement the core WASI functions, effectively [polyfilling](https://developer.mozilla.org/en-US/docs/Glossary/Polyfill) WASI for the IC. This would allow developers to take advantage of the WASI ecosystem and run WASI-compatible programs on the Internet Computer.
[The set of WASI functions](https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md) consists of the following groups:
1. Accessing the program arguments and environment variables:
- args\_get(), args\_sizes\_get(), environ\_get(), environ\_sizes\_get().
2. Getting the current time:
- clock\_res\_get(), clock\_time\_get().
3. Working with files and paths:
- fd\_advise(), fd\_allocate(), fd\_close(), fd\_datasync(), fd\_fdstat\_get(), fd\_fdstat\_set\_flags(), fd\_fdstat\_set\_rights(), fd\_filestat\_get(), fd\_filestat\_set\_size(), fd\_filestat\_set\_times(), fd\_pread(), fd\_prestat\_get(), fd\_prestat\_dir\_name(), fd\_pwrite(), fd\_read(), fd\_readdir(), fd\_renumber(), fd\_seek(), fd\_sync(), fd\_tell(), fd\_write(), path\_create\_directory(), path\_filestat\_get(), path\_filestat\_set\_times(), path\_link(), path\_open(), path\_readlink(), path\_remove\_directory(), path\_rename(), path\_symlink(), path\_unlink\_file()
4. Working with sockets:
- sock\_accept(), sock\_recv(), sock\_send(), sock\_shutdown().
5. Polling on time and file events:
- poll\_oneoff()
6. Getting randomness:
- random\_get()
7. Other:
- proc\_exit(), proc\_raise(), sched\_yield().
Polyfilling groups 1, 2, 5, 6, 7 should be straightforward with a caveat that currently randomness is not available at canister installation time, which will make random\_get() pseudorandom in the initial version. True randomness would require protocol changes to provide randomness during canister installation time. The plan for group 3 is to implement the simplest possible file system on top of IC’s stable memory and [stable-structures](https://github.com/dfinity/stable-structures). This is where most of the work is expected to happen. Group 4 will not be supported because sockets are not required to run most of the WASI programs mentioned in the Background section.
Additionally, I am planning to write a command line tool to parse Wasm binaries and substitute the WASI imports with their implementations from the polyfill library.
The workflow for an IC developer utilizing WASI will look as follows:
1. Write a WASI program in any language that supports wasm32-wasi.
2. Incorporate a build step to my command line tool to replace WASI dependencies.
3. Run the Wasm binary on the IC.
I’ll post more updates in this thread once I have the initial prototype implementation.
---
### Author:  [@rossberg](https://forum.dfinity.org/u/rossberg)
#### Post date: [February 19, 2023, 12:03pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/2 "2023-02-19T12:03:44Z")
That would be great! Will it be a problem for the implementation that some services can only be accessed asynchronously on the IC?
---
### Author:  [@Gekctek](https://forum.dfinity.org/u/Gekctek)
#### Post date: [February 19, 2023, 3:45pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/3 "2023-02-19T15:45:41Z")
This is great. I’ve been so excited for wasm in general to take over.
This would be a great opportunity for Motoko to expand it’s wasi support.
---
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 19, 2023, 4:37pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/4 "2023-02-19T16:37:22Z")
> [@rossberg](#):
>
> That would be great! Will it be a problem for the implementation that some services can only be accessed asynchronously on the IC?
In order to use the asynchronous features of the IC, the program would need to use the System API in addition to WASI. The primary benefit of the project is to allow the usage of WASI-based libraries in the IC canisters.
---
### Author:  [@chenyan](https://forum.dfinity.org/u/chenyan)
#### Post date: [February 19, 2023, 5:32pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/5 "2023-02-19T17:32:54Z")
Interesting idea! I think group 1 is also tricky to implement. If the goal is to replace the whole WASI binary to run on the IC, how do you decide their Candid types and the endpoint API? If we plan to use the WASI binary as a library, we don’t have a good story for Wasm linking yet.
---
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 19, 2023, 9:43pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/6 "2023-02-19T21:43:50Z")
> [@chenyan](#):
>
> Interesting idea! I think group 1 is also tricky to implement. If the goal is to replace the whole WASI binary to run on the IC, how do you decide their Candid types and the endpoint API? If we plan to use the WASI binary as a library, we don’t have a good story for Wasm linking yet.
The concrete goal is to support the `wasm32-wasi` compilation target for canisters. This will allow a canister to use a library that requires WASI, which is currently impossible with the target `wasm32-unknown-unknown`. Note that the library here means not a Wasm file but rather an actual library defined in the source language of the canister. For example, a Rust canister could embed a rust port of the sqlite library [rusqlite](https://github.com/rusqlite/rusqlite) that supports the WASI target.
In theory it might be possible to support libraries defined in Wasm files, which, as you have mentioned, would require some Wasm linker, this is out of scope in this project.
> [@chenyan](#):
>
> I think group 1 is also tricky to implement.
For now I am aiming for the simplest possible implementation of the polyfill functions, which means the args\_get() and environ\_get() would return empty results.
---
### Author:  [@paulyoung](https://forum.dfinity.org/u/paulyoung)
#### Post date: [February 19, 2023, 9:53pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/7 "2023-02-19T21:53:42Z")
For the `fd_*` stuff you might be interested in [GitHub - codebase-labs/icfs: Internet Computer File System](https://github.com/codebase-labs/icfs)
---
### Author:  [@cymqqqq](https://forum.dfinity.org/u/cymqqqq)
#### Post date: [February 20, 2023, 1:16am UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/8 "2023-02-20T01:16:22Z")
Good work! I have a question here:
> [@sgaflv](#):
>
> 1. Run the Wasm binary on the IC.
Run the wasm binary on the IC, do you mean a canister? if so, how do you generate the candid file?
---
### Author:  [@skilesare](https://forum.dfinity.org/u/skilesare)
#### Post date: [February 20, 2023, 11:55am UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/9 "2023-02-20T11:55:14Z")
Would this even work with motoko? Seems the referenced library could do something unexpected…maybe yield flow to something that never returns?
---
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 20, 2023, 11:55am UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/10 "2023-02-20T11:55:23Z")
> [@paulyoung](#):
>
> For the `fd_*` stuff you might be interested in [GitHub - codebase-labs/icfs: Internet Computer File System](https://github.com/codebase-labs/icfs)
Thank you! I will take a look, does it support folders?
---
### Author:  [@paulyoung](https://forum.dfinity.org/u/paulyoung)
#### Post date: [February 20, 2023, 5:04pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/11 "2023-02-20T17:04:32Z")
Yes. There’s an example showing how you can provide a POSIX-style API:
>
There’s also an issue for making a more idiomatic Rust API: [icfs-fatfs: provide similar functionality to std::fs · Issue #23 · codebase-labs/icfs · GitHub](https://github.com/codebase-labs/icfs/issues/23)
---
### Author:  [@icpp](https://forum.dfinity.org/u/icpp)
#### Post date: [February 20, 2023, 10:07pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/12 "2023-02-20T22:07:47Z")
@sgaflv ,
This is great news!
We use the wasi-sdk to compile C++ to wasm, and we currently stub those methods you mentioned.
Even when the file system is not used at all, the wasi-sdk linker still might include calls to fd\_\* functions. For extra safety we also trap the execution with a clear message.
Looking forward to be able to use the full wasi-sdk capabilities!
---
### Author:  [@paulyoung](https://forum.dfinity.org/u/paulyoung)
#### Post date: [February 21, 2023, 7:21pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/13 "2023-02-21T19:21:29Z")
[`wasm-snip`](https://github.com/rustwasm/wasm-snip) can sometimes help simplify things when imports show up but those code paths aren’t used.
---
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 22, 2023, 7:20pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/14 "2023-02-22T19:20:36Z")
> [@cymqqqq](#):
>
> Run the wasm binary on the IC, do you mean a canister? if so, how do you generate the candid file?
The goal is to allow building canisters that contain `wasm32-wasi` target dependencies, but otherwise you are developing the canister by the usual canister development flow.
---
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 22, 2023, 7:27pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/15 "2023-02-22T19:27:44Z")
> [@skilesare](#):
>
> Would this even work with motoko? Seems the referenced library could do something unexpected…maybe yield flow to something that never returns?
As far as I know Motoko does not compile to `wasm32-wasi` (it also [doesn’t have FFI](https://forum.dfinity.org/t/any-possible-to-invoke-rust-code-in-motoko/5751/4)). My initial focus is low-level languages like Rust and C++.
---
### Author:  [@skilesare](https://forum.dfinity.org/u/skilesare)
#### Post date: [February 22, 2023, 7:37pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/16 "2023-02-22T19:37:19Z")
There is definitely a --wasi-system-api flag for outputting to wasi. I’d say that @claudio or @matthewhammer would have more info.
If there are a few small things that could be added to get motoko into the mix it would be really helpful.
---
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 22, 2023, 7:38pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/17 "2023-02-22T19:38:09Z")
Great! Many thanks! I might have more questions when I start working on the `fd_` functions.
---
### Author:  [@skilesare](https://forum.dfinity.org/u/skilesare)
#### Post date: [February 22, 2023, 7:43pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/18 "2023-02-22T19:43:20Z")
I also don’t know if this has any crossover with what @v1ctor has done on [Assigned: ICDevs.org - Bounty #34 - Wasmer Motoko - $10,000](https://forum.dfinity.org/t/assigned-icdevs-org-bounty-34-wasmer-motoko-10-000/17887), but if it does it would be nice to build on the work that has already been done over there. I think this is likely the other side of the coin from this work, but I want to make sure you guy know about each other and can compare notes.
---
### Author:  [@sgaflv](https://forum.dfinity.org/u/sgaflv)
#### Post date: [February 22, 2023, 7:53pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/19 "2023-02-22T19:53:54Z")
Thank you for the information, I will take a look at that project and see if there is something in common that can be reused. At the moment I don’t have a clear picture how it would work in Motoko, but supporting `wasm32-wasi` is a good sign!
---
### Author:  [@rossberg](https://forum.dfinity.org/u/rossberg)
#### Post date: [February 22, 2023, 9:10pm UTC](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583/20 "2023-02-22T21:10:34Z")
One important detail I’m still missing from the workflow described in the OP is this: at the end of the day, any program useful on the IC will need to interact with the IC’s system API in some way, i.e., at least be able to receive and respond to ingress messages. That is rather different from how programs interact with more traditional environments. What is the plan for bridging that gap?
[Next page](https://forum.dfinity.org/t/introducing-wasi-for-ic/18583.md?page=2)