Future of this project

[darosior]

It would be nice if we could make this project more friendly to downstream users. At the moment it is tailored to the needs of the Liana GUI, but i think a HWI library in a compiled language is dearly needed in the Bitcoin space. And Rust seems like a good fit for this. Plus, we already have the implementation for the Ledger and Specter devices.

I tweeted about this and it looks like there is interest from other Bitcoin developers in contributing to a Rust HWI. Given the interest in using or contributing to this library, i'm happy for Wizardsardine to dedicate some resources to extend the scope of this library to a wider audience than the Liana project. Let's discuss on this issue the path forward.

Regarding the goal of the library i think there isn't much to discuss. It should aim to be a high-level interface to the largest reasonable number of Bitcoin signing devices. I would just add a requirement that output descriptors be first class citizens. I'm not sure yet how (maybe using @bigspider's wallet policies?).

Regarding the path toward this goal, i think we:

1. First need to cleanup the current code. It's been a one man (@edouardparis)'s project and it could use some review (probably mine but anyone's welcome) / bit more testing.
2. Make the asyncness optional.
3. Re-design the main interface, the HWI trait, with the new goals of this library in mind.
4. Add support for more signing devices.
5. Provide Python bindings.
6. Get to feature parity with the existing Python HWI.
7. ?Get the existing Python HWI to migrate to Rust HWI under the hood?
8. ?Honour an MSRV and move this repo to an org that isn't our company? Rust-Bitcoin maybe?

Thoughts? People interested in contributing to or using this Rust-HWI please chime in!

[vnprc]

It would be amazing to be able to compile to WASM to enable browser-based wallets.

[darosior]

Yes, it's something we are looking at as well. But there is more to it than simply compiling to WASM: the transport should be adapted as well, probably to something like web-HDI.

[edouardparis]

navigator.hid.requestDevice() and other browser javascript interfaces return js promise which are better handled by wasm_bindgen_futures async methods (ex: https://github.com/digitalbitbox/bitbox-api-rs/blob/master/src/wasm/connect.rs#L14)
WASM is one example of transport where the async feature has good support for, an other would be bluetooth as illustrated by this crate that implements the bluetooth communication for ledger Nano X. In fact, Rust hardware ecosystem loves async, new exciting libraries like https://github.com/embassy-rs/embassy/ make full usage of it. This tweet explains one of the reason.

I believe if we want to be ambitious in terms of feature and diversity of transport for this library, we should keep the async support and keep the name crate async-hwi. In the same time I totally understand the interest in a non-async library but I believe it would be too much code duplication and complexity (both in features flag and dependency management) to keep it in the same crate. If some individuals wants to start this project, they will not have to start from scratch as our library is a good way to understand what is possible in terms of common API between all the referenced devices.

---

(Quick divergence on async rust, https://without.boats/blog/why-async-rust/ is a good read, in fact every article from https://without.boats/ are very good and should be read by every developers before screaming about coloring function)