maybe_async complicates isomorphic use-cases

[cryptoquick]

The maybe_async macro makes the function signature of each method different depending on whether the dependency is compiled for wasm32 or not. This isn't ideal for libraries that might be used in isomoprhic app frameworks like iced, which can compile to either web or desktop-native targets.

I'm not sure what the best approach would be to fix this since Rust's async story is so complex right now. If at some point we enter the shiny future, we can just remove usage of the bdk-macros crate altogether.

For now, I think it's possible to bypass this issue by also using the bdk-macros crate, but this is imperfect because it essentially perpetuates the problem, and "infects" all upstream dependents.

[LLFourn]

@cryptoquick fwiw I am working on this as part of #165. My plan is to have a sync blockchain traits in blockchain and async versions in blockchain::async. Would this work for your use case?

[cryptoquick]

Maybe! I might be able to finagle conditional compilation to accomplish that. Is your branch ready to try? Also, is it merged with main? (I'm typing this on mobile, otherwise I'd check, myself)

[cryptoquick]

Just got back to my machine to check, and it looks like that's just an issue, not a pull request. Still, this might work, and it's idiomatic to how other libraries in the Rust ecosystem works. I'd be willing to close this in light of the work being done there, if you think that makes sense, @LLFourn ?

[LLFourn]

We are starting work on this change today. Won't be ready for testing this week I suspect. I'll keep you updated.

[cryptoquick]

Sounds good. I've also subscribed to the other thread, and also, let me know if you need any help testing your work.

[notmandatory]

The core Wallet type is now Send+Sync and any async or blocking client can be used for blockchain syncing or persistence, see #1873.