Open SamsungGalaxyPlayer opened 5 years ago
Good stuff :-)
I believe it's unclear what the line/circle colors mean. What does it mean for a link to be gray or yellow? Why is the Monero Network red sometimes? It's like warning people that connecting to the network is bad.
IMHO just highlighting the link where the choices apply to would be less confusing.
Good stuff!
screenshot #1: "Would you like to enable this feature? " this sentence should be as last, before the two buttons.
Second paragraph, I would remove it. You could show as a possible reason if there were some problems with connecting to i2p or tor.
The two options below the paragraphs don't feel/look like buttons. I would make them look like on the 2nd screenshot, orange. Two buttons next to each other, centered. Also buttons text could be: "Yes, protect my connection" and the other "No thanks"
Screenshot #2:
Other ones, not quite sure what green and red suggest...
Btw. Is it possible to wrap some words in (https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_abbr_test) tag to quickly explain what it is? For example, node, tor, i2p. Not just here but it would be beneficial to do it everywhere. That would save time to explain bits over and over and save time for the user to scan the internet for answers.
Best.
imho, we shouldn't add yet another configuration screen to simple mode. Perhaps add it to the Mode selection with radio buttons, like this? This way, in Advanced Mode, you can just clarify how you want to use I2P and Tor, and in Simple Mode, it's done by default.
Lastly, if the selected method fails while the user is in simple mode, they get a popup prompting them to change it.
@dginovker we still need to present an option to users in simple mode, since using i2p is more dangerous than using Monero in some jurisdictions.
since using i2p is more dangerous than using Monero in some jurisdictions.
Citation required. Non-obvious to me that this is the case.
When Whonix (or similar) is detected [1], which torifies all connections by default, and to prevent Tor over Tor: don't show any of these new screens?
[1] See for detection: https://github.com/monero-project/monero-gui/issues/2421
Hey so this seems a little stalled and I'd like to take it up sometime next month. How prepared are you guys for a PR to do accomplish this? Do have you settled o a design yet? Also, have you considered "hybrid" nodes where I2P-using nodes do communicate with the clearnet, but only over Tor, in order to act as anonymous bridges between the networks?
I'm sorry I wasn't able to make the meeting today, I was tied up elsewhere and really underestimated how much communication I would need to catch up on when I got back. If possible, could we do some of this discussion asynchronously, here on the github issue? There are a few things of note for me re: this process
.zip
or tar.gz
or other package. In this case the monero daemon would have to first discover if an I2P router exists, then if it does not, start I2P-Zero instead. Then the monerod would connect to the I2P-Zero control port in order to set up the tunnels it needs and read the destinations back from the control port.libi2pd
library which powers the i2pd
C++ router. The i2pd
project uses this library and makes it available to others to use, and it accepts identical arguments to the i2pd
executable. In this case the monero daemon would need to read the .dat
keys written by the i2pd router and convert them into b32.i2p
addresses.I2P-Zero
, one of those two things would be making it automatically update. An I2P-Zero UpdatePostProcessor could distribute updates using Bittorrent-over-I2P for efficiency and security, and would be able to update a "bundle" of any kind, including updating the monero
executable, resources and libraries as well. 3. also has some appeal but lacks the auto-update mechanism.I will try to be on Matrix all this week.
@eyedeekay I think including i2p-zero is a good idea. Not all users need to use it of course, but a user should be able to toggle it on without needing to worry about opening up another application manually. My personal vote is also for 2.
Can people do clearnet queries through i2p? I'm under the impression that i2p has many limitations there. One of the benefits with Feather defaulting to using Tor is that all the external connections like price feed, Monero CCS, and Reddit are hidden behind Tor. We don't need to do all of this in the GUI (just price queries for fiat prices). i2p seems useful for node connectivity, but I'm a little skeptical if it provides the most comprehensive solution for things most users want.
Yeah we don't normally do exit traffic ourselves, but there are a handful of volunteers who run exit proxies(outproxies) which could hypothetically be configured for Monero. The use of a general exit proxy may not be required, though. What would happen in the case of Monero for instance is that some nodes would need to run in 2 modes at once, either with Tor+I2P or with Clearnet+I2P, to communicate between the I2P and non-I2P sides of the network. I usually refer to this technique as being a "Bridge" and IMO it's generally a little easier for individuals to pull off than acting as a general exit proxy, since one side of a bridged connection may not be anonymous.
The chart of meaningful available configurations and their characteristics:
.onion
connections routed over TorItem to Hide | Options | Comment |
---|---|---|
Sync old blocks | Clearnet (fast), Tor (slow), i2p (slow) | Some performance testing is needed, but most users will likely opt to sync old blocks over clearnet. Feather does not hide this by default. |
Sync very recent blocks | Clearnet (fast), Tor, i2p | Users get better "bang for the buck" with Tor/i2p here. Syncing very recent blocks with Tor/i2p increases plausible deniability versus an ongoing clearnet connection. Feather does not hide this by default (I think). |
Broadcast transactions | Clearnet (no protection), Tor, i2p | This is the most important information to hide, hands down. Tor and i2p both address this. Feather hides this with Tor by default. |
Price API lookups | Clearnet (no protection), Tor, i2p (weak support) | Tor is the best trade-off here as things currently stand, because it's far better for reaching clearnet services. Unless someone wants to run a great price API through i2p, this probably won't change. Feather hides this with Tor by default. |
@eyedeekay
What are the benefits to using i2p over Tor for these actions by default? If we were to protect broadcasts to remote nodes by default, would i2p be noticeably better than using Tor?
Supporting i2p makes sense from the perspective of someone connecting to their own Monero node behind a double-NAT. I'm less sure it makes sense for a more novice user connecting to a rando remote node.
Here's a table of the most realistic 2 default options. Other options like Tor-only are possible but shouldn't be a default for performance reasons.
I Item to Hide | Option 1 Default | Option 2 Default |
---|---|---|
Sync old blocks | Clearnet | Clearnet |
Sync very new blocks | Tor | i2p |
Broadcast transactions | Tor | i2p |
Price API lookups | Tor | Tor |
In my mind, it's a matter of determining if there's a material benefit to using i2p over Tor by default for those 2 items.
Unfortunately I'm not always going to be able to say which one is better or not, because there are sometimes just going to be trade-offs. I've grown to think that comparing I2P and Tor as direct competitors is not usually very productive and distracts from the ways they can be mutually beneficial. Tor's good at exit diversity, I2P's good at relay diversity, etc. One clearer advantage we have is that once you're well-integrated into I2P it's pretty difficult to disconnect your router by killing off connections to your peers. Some of it will also depend on what decisions we make when integrating I2P. I'll try to explain while I answer your questions, most of my theses will revolve around our relatively extensive configurability of tunnels. That said, I think this is probably a case where it makes sense to use them together as a default.
What are the benefits to using i2p over Tor for these actions by default? If we were to protect broadcasts to remote nodes by default, would i2p be noticeably better than using Tor?
Supporting i2p makes sense from the perspective of someone connecting to their own Monero node behind a double-NAT. I'm less sure it makes sense for a more novice user connecting to a rando remote node.
I think the strongest argument is probably(and surprisingly) for the initial syncing.
Potentially relevant discussion also happening here: http://zzz.i2p/topics/3219-socks-outproxy-plugin and here https://i2pgit.org/i2p-hackers/i2p.i2p/-/merge_requests/46
We are considering the possibility of enabling I2P to forward non-I2P requests to a proxy which is running locally, with a default of localhost:9050
. This would enable I2P to handle Tor connections as well.
I am continuing a discussion about Monero GUI network connection options. Note that this is subject to change and improvements. Related Reddit discussion
This latest iteration better separates specific options and descriptions with the type of node or connection they are related to. As always, I tried to keep simple mode especially as easy as possible, with a simple on/off.
Startup Screens
Simple mode:
Expert mode:
Simple Mode
Note: default uses i2p for broadcast and syncing new blocks. It falls back to clearnet for old blocks (>1 week? >1 month?)
Expert Mode, Random Nodes and Manual Untrusted Nodes
Note: if only i2p is selected, all options for Tor are removed. Manual may be removed too.
Expert Mode, Manual Trusted Nodes
Note: requires https://github.com/monero-project/monero/issues/5590. Automatic mode uses clearnet, i2p, or Tor to connect to the custom node as necessary depending on the TLD.
Expert Mode, Local Node
Please leave feedback! This is the third main design iteration. Comment on the basic layout, the wording, setting organization, and more. Let's get some discussions going so that this important feature can be implemented in 0.15, and for the implementation to be super awesome for all users.