Error while installing on substrate-node-template

[amiyatulu]

Add iroh in dependencies

iroh = { version = "0.10.0", default-features = false }

It gives following error:

error[E0599]: no method named `reset_immediately` found for struct `Interval` in the current scope
   --> /home/amiya/.cargo/registry/src/index.crates.io-6f17d22bba15001f/iroh-net-0.10.0/src/net/netmon/actor.rs:128:43
    |
128 |                         debounce_interval.reset_immediately();
    |                                           ^^^^^^^^^^^^^^^^^ method not found in `Interval`

error[E0599]: no method named `reset_immediately` found for struct `Interval` in the current scope
   --> /home/amiya/.cargo/registry/src/index.crates.io-6f17d22bba15001f/iroh-net-0.10.0/src/net/netmon/actor.rs:134:39
    |
134 |                     debounce_interval.reset_immediately();
    |                                       ^^^^^^^^^^^^^^^^^ method not found in `Interval`

Substrate does uses WebAssembly (Wasm). However, it doesn't necessarily rely on the browser's WebAssembly environment. So will it support dependencies like quinn?

[rklaehn]

We want to support WASM at some point, but we currently don't have it as a supported platform.

Quinn-udp is using low level networking apis to send and receive UDP packets. That is definitely not going to work in the browser.

Our plan is to use good old websockets and then later maybe webrtc.

May I ask what the use case is?

[amiyatulu]

Substrate don't run on browser. This is what substrate documentation says

Compilation target

When building a Substrate node, we use the wasm32-unknown-unknown compilation target which means that Substrate runtime engineers are constrained to writing runtimes that must compile to Wasm. This implies that you can't rely on some typical standard library types and functions and must only use no_std compatible crates for the majority of runtime code. Substrate has a lot of its of own primitive types and associated traits that make it possible to work around the no_std requirement.

The use case involves storing data in the blockchain and providing incentives for it, similar to the Crust network. The benefits of storing data directly in blockchain apps or Substrate offchain workers include the ability to perform some validation on the data before storage. Additionally, there is no need for a separate executable; both the blockchain and distributed storage are integrated into one.

Since IPFS is commonly used for blockchain storage, this feature needs to be on the priority list.

[rklaehn]

The substrate:ipfs project you link to contains a docker image. So I assume the ipfs node itself is running in that docker image, and the substrate worker talks to this?

So what you would want is to use a native iroh process from inside a substrate worker, but not embed an entire iroh node?

This would currently be hard because our RPC is using QUIC as well, but we are working on switching the RPC. So maybe we can make this work. What IO facilities do you have from inside a substrate worker?

[amiyatulu]

Ipfs is installed in three places including substrate node and client, all packaged together into rust executable, and than to docker. Seems it do require no-std. Though I am currently learning offchain worker, a substrate expert can say it better.

Here is the code:
https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node-template/node/Cargo.toml#L19
https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/bin/node/cli/Cargo.toml#L41
https://github.com/rs-ipfs/substrate/blob/offchain_ipfs_bleeding_edge/client/offchain/Cargo.toml#L23

[amiyatulu]

quinn needs rusttls and rusttls currently don't support no_std. They seem to be in phase 1