feat: configurable tor obsf4 bridge #239
Conversation
…er progress event, change wording in progress page
|
While we're at it we should also allow disabling tor entirely |
* add alert in deposit page to warn against replace-by-fee
There was an issue before we were falsely applying a default node to use and not actually iterating through our list and checking for availiability. This commit fixes this issue and removes a few dead nodes.
|
Okay it turns out that Tor Browser bundles a binary called On darwin / linux you can also install However I was very glad we did not have to put up with external binaries anymore... For mobile support this'll also not work. I'm unsure how to proceed. What do you think @Einliterflasche ? |
|
This is unfortunate... I agree that bundling a binary is not something we would want to do. A potential problem I see is that we might not be able to rely on the default path. In my experience installing tor on windows really just gives a folder with the executable; and the folder can be anywhere. We could build a UI to where we check at different locations or a user can input a specific path. |
|
I recommend adding "use own Tor" checkbox instead which does SOCKS5 to 127.0.0.1:9050 and recommending users to start their Tor Browser and keep it running, will be less complicated than telling to use a specific binary they have to find the location of, browser automatically provides socks functionality when running and will of course use the settings already used by the user This would also allow more advanced users to use their own Tor daemon and build more secure configuration |
Tor Browser uses 9150 where as tor (daemon) runs on 9050 by default. It should probably be user configurable with 9150 being default |
|
Yes, pls make it user configurable with 9150 being default. as in some configurations stream isolations needed if many apps run simultan, so you can run every app with an own Tor Circuit |
|
I see your point. I really do but it introduces so much extra complexity... I'll have to think about it. |
Einliterflasche
changed the title
Before, monero::Wallet wrapped a Mutex<Client>, and locked the mutex on each operation. This meant releasing the lock in between operations, even though we rely on the operations being executed in order. To remedy this race condition, we wrap monero::Wallet itself in a mutex, requiring any caller to hold the lock for the duration of the operation, including any suboperations.
This reverts commit 235c835.
|
Converting this to a draft for now. I don't want to introduce this much extra complexity to the codebase at the moment. |
|
In that case we should introduce a new pr that simply allows disabling tor until we can get back to this. #266 for example is a common problem, I think and the fix is easy enough that we shouldn't postpone it. |
Shouldn't be hard to implement. The code is structured such that the tor client can be |
|
Implemented the toggle in #300 |
No description provided.