Make this a slick re-usable crate?

[stnbu]

Hi there. This project overlaps with stuff I'm interested to a large degree. I'd be happy to contribute/collaborate in any way you'd find helpful...if that would be helpful.

For me, it would be great to be able to just add this as a crate to my "project". Maybe there's already such stuff? Maybe some generalization is in order?

I donno. Just another RFC I guess. (Request For Collaboration)

Whatever the case, thanks! This is a super enlightening repo from my point of view. 👏 Much understanding blossoms.

[kauly]

Thanks men. I did this as a poc to also use in a project later. I dont have plans to make this reusable but who knows. There is a big limitation in the code though. I was not able to make the web3 struct(let web3 = web3::Web3::new(transport); ) global available between systems so we cant listen to wallet events like chain or address changes.

[stnbu]

Very interesting! I went ahead and forked it and have just begun prodding but I can use it as a regular old cate and insert the bundle without errors/works!

let web3 = web3::Web3::new(transport); 

I'll stubbornly get ta working on that!

[stnbu]

was not able ... global available between systems

Can you give me any helpful "post mortem" or dead ends you encountered or tips or...? I'm new to rust but the cogs are catching.

It sounds like there might be a call for 'static mmaybe?

I'm excited to try and crack this obviously-valuable nut!

[kauly]

So Im pretty new to rust too but yea the problem is the 'static + Send + Sync that the web3 dont satisfy.

https://docs.rs/bevy/latest/bevy/ecs/system/trait.Resource.html

[stnbu]

I cannot yet fully grok that trait and what it does as from my experience a "resource" (edit) is just a regular type that you define, e.g. a struct. When you "insert" it, it becomes a singleton within bevy. There's no decorator ("attribute"?) like there is with Components:

#[derive(Component)]
struct MyCompnt;

That said, I barely understand what's going on around here!! ;-)

I currently am poking at the problem via this toy package.

I get the following compiler error:

$ cargo build --release --target wasm32-unknown-unknown
   Compiling web3 v0.18.0
error[E0432]: unresolved imports `async_std::net::TcpListener`, `async_std::net::TcpStream`
   --> /Users/mburr/.cargo/registry/src/github.com-1ecc6299db9ec823/web3-0.18.0/src/transports/ws.rs:481:30
    |
481 |     pub use async_std::net::{TcpListener, TcpStream};
    |                              ^^^^^^^^^^^  ^^^^^^^^^ no `TcpStream` in `net`
    |                              |
    |                              no `TcpListener` in `net`

error[E0425]: cannot find function `spawn` in module `async_std::task`
   --> /Users/mburr/.cargo/registry/src/github.com-1ecc6299db9ec823/web3-0.18.0/src/transports/ws.rs:352:26
    |
352 |         async_std::task::spawn(task.into_task(stream));
    |                          ^^^^^ not found in `async_std::task`
    |
help: consider importing this function
    |
3   | use std::thread::spawn;
    |

error[E0282]: type annotations needed
   --> /Users/mburr/.cargo/registry/src/github.com-1ecc6299db9ec823/web3-0.18.0/src/transports/ws.rs:130:9
    |
129 |         let stream = compat::raw_tcp_stream(addrs).await?;
    |             ------ consider giving `stream` a type
130 |         stream.set_nodelay(true)?;
    |         ^^^^^^ cannot infer type
    |
    = note: type must be known at this point

Some errors have detailed explanations: E0282, E0425, E0432.
For more information about an error, try `rustc --explain E0282`.
error: could not compile `web3` due to 3 previous errors

After digging, I find that async-std skips these types for wasm32-unknown-unknown.

I'm taking a very different zagg from you thought I think. I'm using websocket, just trying to get anything to work. I picked a verbatim example using ws:// and thought nothing of it! That led me down a rabbit hole. Fun digging out.

That's not called for in our case, so I've "wasted" a bunch of time. Learned a lot! 😩

I'll try with the eip1193 transport and see what happens.

[kauly]

All the examples in the web3 repo are for desktop targets. For wasm you must use the eip1193 transport to have a web browser blockchain client.

[stnbu]

I have "read" the async book (gasp...wheeze). I've read and mostly comprehended ei_1193.rs. Here's some thoughts/observations:

• It looks like eip_1193.rs itself has some barriers to threading, the use of Rc among them. I think I'm going to drop the WASM part as I experiment and just try to use web3::Web3<Eip1193>(...) across/with threads, just to eliminate one complicating factor, if temporarily. Corollary: eip_1193.rs itself needs to be modified or replaced. (I think)
• Could this stuff be short-circuited by not allowing web3::Web3<Eip1193>(...) to cross threads or be moved at all? Does that obviate using within bevy? Seems like it should still be possible. For example, could web3::Web3<Eip1193>(...) live in its own thread and communicate with the rest of the system through a Mutex that only stores the stuff we care about? Assuming that's a thing, there might be some inspiring examples out there. Trying to think of one, myself.
• It looks like async_std::net::TcpStream solves some similar problems. For the motivated student, it might be worth looking at diff std::net::TcpStream async_std::net::TcpStream (roughly speaking)
• This issue looks relevant, some. I think the _ in the original code is there for a reason, e.g. giving the variable a name allows it to potentially live beyond where it's safe to reference, as explained in the async book. Mmaybe the compiler allows it here because of the extern "C" block. 🤷 (or, the only relevant thing here might be the issue title...)
• eip_1193.rs has plenty of async code! Somehow it doesn't trip over the Rcs in the rest of the code. Interestingly some methods are exern "C" and are also async. I'm not sure what the implications are.

Did I just muddy the waters?

[stnbu]

Oh... It just occured to me, EIP 1193 is an "Ethereum Provider JavaScript API".

So I'm stuck inside of wasm or I find something outside of wasm I can use for testing or I create some stub code to do that myself.

[stnbu]

maybe https://docs.rs/bevy/0.7.0/bevy/tasks/struct.IoTaskPool.html ?

EIP 1193 is IO intensive but more importantly the pool could have a singleton task in which lives all of the 1193 stuff should do the trick. I think. some Mutex could be used to do api calls within a frame... I guess I'm still thinking "resource" and not "component".

[kauly]

The requests are working fine. The limitation is that the web3 transport instance dont live enough to listen for events reponses. So its always necessary create a new instance before do any request.

[kauly]

maybe https://docs.rs/bevy/0.7.0/bevy/tasks/struct.IoTaskPool.html ?

EIP 1193 is IO intensive but more importantly the pool could have a singleton task in which lives all of the 1193 stuff should do the trick. I think. some Mutex could be used to do api calls within a frame... I guess I'm still thinking "resource" and not "component".

That seems promisse, I never used before but make sense.