wasm32-wasi vs wasm32-unknown-unknown

[miraclx]

wasm32-unknown-unknown gives us full (manual) control over all the external sources of data that the guest is permitted to access. But this means we're unable to use those interfaces as sources for things that would otherwise depend on libc.

Which means all the io has to go through manually built structures that call our custom host functions.

wasm32-wasi lets us compile anything that uses these libc interfaces, to eventually be backed by (still custom written) host functions, with IO backed by Blob API for example, and perhaps entropy by #194.

Meaning apps have access to libc syscalls for managing files, networking, etc. Worth thinking about.

Q: does it make sense to back app state with the "node" storage at that point? or just let app devs embed their own storage in-app with the Blob API backend storing hashes in the "node" storage, with a generic block store elsewhere. Downside of this model (when considered with #272) is that the state update you receive would just contain a bunch of hashes. And you have to do subsequent fetches to get the data contained within them. Ideally Blob API should be for non-essential data like on-demand resources and not state.