From where it stands, it seems that rust-ipfs is not exactly platform agnostic in a sense where it could run on every platform without an issue (mostly around wasm). rust-libp2p is platform agnostic, although testing may need to be done around wasm, wasi, etc., but have not seen many reports of issues on those platforms while rust-ipfs, being directly tied in with tokio, which does not support wasm completely, would likely have trouble running on such platforms.
Platforms that rust-ipfs can run on:
[x] PC (Works on Windows, Linux, Mac. For FreeBSD, OpenBSD and NetBSD, testing coming soon)
[ ] Make rust-ipfs less dependent on tokio to give the user option to choose between different libraries (eg smol, async-std, etc)
[x] Gate any IO operations behind features not to conflict with platforms that cannot perform direct IO (eg WASM)
[x] Test official protocols against WASM in rust-ipfs to determine what does and doesnt work
[ ] Test interop with js-ipfs and go-ipfs
Notes:
Under default configuration, DNS would not operate on android due to its attempt to locate /etc/resolve.conf. As a result, we have to check for the target os and use the following lines to use the default dns (which I believe would be google dns)
We can use idb, or gluesql for the data and block store when targetting wasm to make it easier on us.
We may want to utilize send_wrapper when handling any wasm32 libraries as many of them that interact with bindings will not support Send or Sync.
From where it stands, it seems that rust-ipfs is not exactly platform agnostic in a sense where it could run on every platform without an issue (mostly around wasm). rust-libp2p is platform agnostic, although testing may need to be done around wasm, wasi, etc., but have not seen many reports of issues on those platforms while rust-ipfs, being directly tied in with tokio, which does not support wasm completely, would likely have trouble running on such platforms.
Platforms that rust-ipfs can run on:
bug in relay protocol, see https://github.com/libp2p/rust-libp2p/issues/5305)What should be done in the future:
Notes:
Under default configuration, DNS would not operate on android due to its attempt to locate/etc/resolve.conf
. As a result, we have to check for the target os and use the following lines to use the default dns (which I believe would be google dns)send_wrapper
when handling any wasm32 libraries as many of them that interact with bindings will not supportSend
orSync
.