Revise proxy screen (add networks, status indicators)

[GBKS]

Our current proxy settings screen is a bit simplified. Last year we did some extra explorations that had more detail, showing the status of the proxies as well. Additionally, we now want to add 2 more networks (I2P and CJDNS). Let's revise this screen, review it together, and document it.

A screen from last year.

A screenshot from our current screen:

The status only indicates whether the proxy/network is indeed active, not how many connections are using the specific network.

Some questions:

1. Is a restart is needed when making changes?
2. If a change results in closing some connections, should we warn users?
3. In both scenarios above, changes are no instantly applied. Does that mean we need Save/Cancel buttons?

[GBKS]

How about this? The two top sections are for enabling and configuring the two proxy options. Then you have a section to configure which network should be run through which proxy. I'd imagine those would be changed via inline dropdowns on desktop, and slide up panel dropdowns (hope that makes sense) on mobile.

I put the "unsaved changes" message in a floating toast so it is visible even in taller screens where a static placement might be hidden visually. This is a similar thread to what's happening in #44.

[GBKS]

Brief update to try to wrap up some loose ends, since @pablomartin4btc had some questions in Discord.

So we have the following functionality for sure.

• Enable the default proxy and set it's IP and port
• Enable the Tor proxy and set it's IP and port
• Define per network, which proxy it should use (none, default, Tor)
• Changes require an application restart

These are slightly updated desktop designs from above.

• When both proxies are disabled, then the network settings items are disabled (greyed out) as well.
• Changing network proxy happens in a small inline dropdown
• Added screen that shows how the restart prompt is sticky.

And some added mobile designs. The only layout change is the restart prompt, since the horizontal layout no longer works. The two screens on the right show dropdown variations we can choose from. I think the inline dropdown we use on desktop works, but we could also go the more explicit route via an overlay (which we use in other places in the app, but is not necessarily needed for such a simple choice).

A question I still have is showing the current status of the proxies. This come up a long time ago, and I think I never quite understood what was meant. Are we showing how many peers are using each proxy? Or which networks are being used by peers by proxy? Also, what is the use case, what are we trying to make the user understand and what decision are we trying to inform?

That's my current understanding of this screen and functionality. Please point out anything else that needs to be tweaked or added.

[GBKS]

We chatted about this on Wednesdays call and the screens need to change. Essentially, instead of having 2 fixed proxies that users can edit, we have one default one and users can add as many as they want. Design iteration and conversation is happening in Discord.

There was also an idea for creating a visualization of the peer connections to make it easier to understand what is happening.

[pablomartin4btc]

I've been doing some research and performing some testing on the current QT desktop application.

I'll try to answer all questions and will give my point of view on the different comments.

I like most the screenshot from the top/ issue description, the indicator of the protocols in use but without the title which is a bit redundant. I prefer this option rather than the "Network settings" shown in other screenshots (eg). Also, that's not something that a user could "choose" from (checkboxes in current QT are disabled), it's informative.

The indicators (rounded green ticked icons) should be displayed in the next re-start, not when the user sets them (please check below current QT behaviour).

Current QT behaviour

When the app restarts, it checks the proxy/ ies are set, valid and working (in case the user enables tor too), and updates the (disabled) checkbox values:

In case the user enables tor separately, the "Tor" checkbox under the default SOCKS5 proxy would still be enabled until the next run:

Next run you will see the "Tor" checkbox disabled as there's a separate Tor proxy configured and running:

I2P and CJDNS

These are configured separately from the GUI, doesn't exist as options in QT at the moment: I2P(passed thru the command line -i2psam=<ip:port>) and CJDNS(-cjdnsreachable). So those are unrelated with the "Network settings" indicators, when there's a proxy SOCKS5 (the default as you specified), all ipv4, ipv6 and tor traffic will go thru it, unless there's a separate Tor proxy, in that case, the default will have ipv4 and ipv6 and the tor traffic would go to it's specific proxy.

"... visualization of the peer connections... "

Currently in QT there's a window showing the details of peers, there you also could see the network type (ipv4, 6 or onion, which is Tor - I think when I2P and/ or CJDNS are configured and valid each connection thru it would show their type as well, as "i2p" and "cjdns").

Current QT's "Peers" window

Questions

Some questions:

Is a restart is needed when making changes?

Yes, restart is needed as all the network configuration needs to reset and start fresh with the new configuration.

If a change results in closing some connections, should we warn users?

It's the same when you shutdown your node or restart it, connections will try to be established on the next run.

In both scenarios above, changes are no instantly applied. Does that mean we need Save/Cancel buttons?

Yeah, the new look and feel doesn't have save/ cancel buttons, we can detect if there was a change from the values persisted and act accordingly (if nothing was changed - eg enable and disable something - then nothing will be persisted and we won't warn users to "restart the app in order to th changes to be applied").

How about this? The two top sections are for enabling and configuring the two proxy options. Then you have a section to configure which network should be run through which proxy. I'd imagine those would be changed via inline dropdowns on desktop, and slide up panel dropdowns (hope that makes sense) on mobile.

As I explained above, I don't think we need the "Network settings" section displayed in the screenshots above.

A question I still have is showing the current status of the proxies. This come up a long time ago, and I think I never quite understood what was meant. Are we showing how many peers are using each proxy? Or which networks are being used by peers by proxy? Also, what is the use case, what are we trying to make the user understand and what decision are we trying to inform?

A peers window like the one I mentioned above, as it exists in QT would be useful, in fact I think it's something we need at some point. The peers window will show all the peers and type of network, I dont't think we need to indicate if it goes thru the Proxy, ipv4 and ipv6 will go thru the SOCKS5 proxy and also Tor if there's no a Tor specific proxy, that's all.

Essentially, instead of having 2 fixed proxies that users can edit, we have one default one and users can add as many as they want. Design iteration and conversation is happening in Discord.

I don't think we need multiple proxies unless I'm missing something. I hope what I tried to explain above makes sense to you but we can have a call.

[jarolrod]

@pablomartin4btc ca we get some guidance on how you think this should be implemented, is it as @GBKS commented here: #59 (comment), i'm not sure on i2p and cjdns, can they have a proxies configured?

[pablomartin4btc]

i'm not sure on i2p and cjdns, can they have a proxies configured?

@jarolrod, @GBKS: I2P needs to have a separate proxy in order to work (-i2psam=<ip:port>), CJDNS doesn't need a proxy (like IPv4 and IPv6 - as @vasild commented here) but if the default proxy is set (not the Tor one), the CJDNS network will be reached via the proxy.

[vasild]

I2P is the easiest to grasp: if -i2psam= is not given, then we cannot reach I2P peers (or in other words, cannot reach the I2P network). If -i2psam= is given, then we can. There are no exit nodes on I2P, so we don't use I2P to access other networks through the I2P network.

CJDNS has to be configured at the OS level, it acts as a VPN and the routing table in the OS routes IPv6 addresses that start with fc through that "VPN". This obviously affects all programs on the computer in a transparent way where they do not have to do anything about it. From the point of view of any program it is just communicating with some IPv6 address, like it does normally. Bitcoin Core has the boolean -cjdnsreachable to inform it that the OS has been configured in that way. This is needed because IPv6 addresses that start with fc are "reserved" and unroutable on the Internet (think like 10.0.0.0/8 in IPv4). So, Bitcoin Core needs to know that a fc... IPv6 address is not "junk". Note that we can use a proxy to connect to any IPv6 address, including fc... ones.

Here comes -proxy= and -onion=. If -proxy= is given, then it is used for connecting to IPv4 and IPv6 peers, including fc... ones, meaning that also connections to CJDNS go to -proxy=. Also, the default value of -onion= is whatever is assigned to -proxy=, so it happens that also connections to Tor go to -proxy=. Then the user can assign a different value to -onion= than the one given to -proxy=. In this case IPv4/IPv6/CJDNS go to -proxy= and Tor goes to -onion=.

Furthermore, if -onion= is not set, but -torcontrol= is, then Bitcoin Core will connect to the "Tor control center" and retrieve the location of the Tor SOCKS5 proxy from there, i.e. it will automatically set -onion= if it is not explicitly given by the user and if -torcontrol= is provided.

[jarolrod]

If still relevant, moving this from the dev repo: bitcoin-core/gui-qml#300