Description
What
As mentioned and discussed at bitcoindevkit/bdk_wallet#196 adding Tor support to both rust-esplora-client or rust-electrum-client is really useful as an alternative to the current SOCKS proxy support, and adds another layer of privacy and anonymity for BDK, and other crates that rely on rust-esplora-client
.
That said, why the new releases of Arti it became somewhat easy to add support for Tor, even more so for HTTP-based requests such as this crate, arti-client can be used in a way to have Tor support as async streams requiring some work with it's APIs and streams.
The Arti team already added support to HTTP requests by using hyper, keeping its usage APIs and usage, through arti-hyper.
As rust-esplora-client
has support for both blocking/async/TLS/SOCKS based on its feature flags, I think that adding Tor support by using arti-hyper, and exposing it as a new feature flag, such as: async-arti-hyper
would be a good approach.
NOTE: For the long-run I think that adding a different approach, as a new feature or refactor that is based on usage of different data streams, selected or built by the user, would make it easier to add support for different transport layers using the same API, something similar to what have been done on electrum_client::client::ClientType
How
It can be done by adding a new feature and adding support for all HTTP calls with arti-hyper, I think it's somewhat straightforward, and I can get it started working if it seems like a good approach.
If you are curious about arti-hyper and hyper usage, you can check both docs/examples:
Metadata
Metadata
Assignees
Labels
Type
Projects
Status