Add support for external Tor SOCKS5 proxies

[fleebicorn]

Why

This started as something I wanted for my own setup, but after working through it it felt useful enough to clean up properly and send out.

The main point of the change is to support an existing Tor SOCKS5 proxy as a real option, instead of assuming the built-in Tor path is the only one that matters. The practical cases here are setups like Tails, Whonix, or a local Tor daemon that is already managed outside the app.

What Changed

Most of the backend work is just pulling the SOCKS5 handling into one place. Before this, the same decisions were spread around in slightly different forms across swap transport, HTTP clients, Electrum, Bitcoin wallet code, Monero RPC pool, and Monero wallet integration. The new tor-socks5 crate owns the proxy address, probing, local-address bypass rules, and the small helpers each caller needs.

On the GUI side, the old Tor toggle is replaced with an explicit network proxy setting. That setting is persisted, passed through the renderer RPC layer, and read by Tauri during context setup. The goal there is mostly to avoid having one proxy setting in the GUI and then a slightly different interpretation of it once the backend starts.

The updater needed a separate bit of handling because it runs before backend context initialization. For that reason the proxy URL is built directly from persisted settings, so update checks and downloads still follow the same SOCKS5 configuration without duplicating the URL formatting logic in TypeScript.

Deliberate Limits

• Local and LAN addresses still bypass the proxy.
• DFX stays on clearnet and can be disabled explicitly.
• The Monero wallet path still only accepts a plain host:port, so that part cannot use per-connection SOCKS5 credentials.

Result

The overall effect is pretty small in terms of user-facing behavior: internal Tor still works as before, but users who already run their own Tor SOCKS5 endpoint now have a cleaner and more consistent path through the app.

[Einliterflasche]

This seems AI generated. Per our AI policy we require all communication to be human written. Please rewrite your own thoughts and reasoning in your own words.

[fleebicorn]

@Einliterflasche, sorry if the pr desc sounded too polished. It's just how I'm used to formatting in my projects.

Idea is simple really - just use existing Tor SOCKS5 proxy if its there instead of assuming built-in Tor is always used. Right now that assumption is kinda baked in random places. SOCKS stuff was all over the place: swap transport, http clients, electrum, btc wallet, monero rpc pool, wallet integration. All doing almost the same thing but slightly diffrent, which was annoying. Moved that into a tor-socks5 crate so at least theres one place that owns it now. Then I removed the old Tor toggle, replaced with explicit proxy setting. Toggle was kinda vauge and in some cases didnt really match what backend was actually doing, which is... yeah not great.

While going through existing Tor code noticed some weird stuff. Built-in Tor is enabled but traffic still goes clearnet in some paths. Not sure if intentional or just unfinished bits. Didn’t touch it here, implemented it only for the new Tor Socks mode. Probably needs separate cleanup later.

Updater needed its own handling since it runs before backend is even up, so proxy URL there is just built from saved settings directly.

LAN and local addresses stay direct, not proxied. Seemed more useful that way, both in general and for my own setup. Added a UI warning when LAN address is used anyway, so user knows whats up.

First tried proxying DFX path too, but seems like it doesn't always play nice with random Tor exit nodes - so ended up not proxying it. Didnt want to just silently send traffic clearnet either tho, so pulled out an 'Enable DFX (clearnet only)' toggle into UI, user can disable monero purchase through it manually if they want.

To reduce correlation between services over Tor, added per-connection SOCKS5 creds so different services dont reuse same circuits. Couldnt do it for monero wallet cause it only takes host:port, so no per-conn creds there for now.

Tested new network proxy mode on Whonix and Tails so far, did a full swap - worked fine. Noticed some scrolling issues in GUI on Whonix, at least on my setup. It's definitely not a regression from this pr cause original client has same behavior. Theres a workaround for now, but should probably file separate issue for it later.

So pipeline looks like this now - user launches client on Tails/Whonix or whatever env with tor socks running. Picks 'Tor Socks' as network proxy in settings, then enters address and port. If theres actually SOCKS5 on that port, indicator turns green. Then app restart needed to start using new routing. 'Enable DFX' toggle is optional, on by default.

Would appreciate feedback on how convenient/intuitive this flow actually feels from user side. Was kinda assuming this mode is mostly for more advanced users, so current steps shouldn't be a problem for them, but might be missing something.

Tried to keep desc high-level here, not sure if more tech details would help or just add noise. lmk if more tech context is needed. Happy to answer any questions or expand on anything.

[fleebicorn]

Rebased on master, brought changes up to date

[binarybaron]

Please also check out #634 as it solves a similar issue and has gone through multiple review cycles.