https://bugs.kde.org/show_bug.cgi?id=471994
--- Comment #2 from Thomas Fischer <fisc...@unix-ag.uni-kl.de> --- (In reply to Pedro V from comment #1) > Given that many people/entities are afraid of the mentioned overlay > networks, Yes, that is my understanding as well. Non-technical people may boggle at words like "TOR network" which they may associate with "hackers". If at all, such settings should be well hidden and rephrased, like "overlay network". > - You could probably already do this by using a P2P VPN taking care of most > of the hurdles and connecting the devices by IP address. Unfortunately the > current common FOSS options aren't too great as most of them don't tend to > take care of common P2P needs like peer discovery and NAT, but sacrificing > some security and using proprietary options like ZeroTier or Tailscale could > already work as a solution. This is obviously the easiest approach from the > point of view of developers as there's nothing to change in KDE Connect for > this to work. True, and indeed such a solution is working for me. As you mention is the associated cost (money, security, FOSS principles, setup time). > - Generic SOCKS support would implicitly support some overlay networks too. > Not fully sure about the development effort, but both Qt and Java seems to > have okay support for it. Likely the Java side is the more interesting one, > at least I'd run a Tor service on the desktop side and let the phone connect > through it through Orbot as one possible way. The "Add devices by IP" option > deceivingly implies the restriction of accepting only IP addresses, but then > later the prompt is asking for "Hostname or IP address", so given proxy > support an onion address may work without further work. Do note though that > common Tor and I2P implementations aren't really focusing on what's needed > here, so for example I wouldn't expect proper handling of the primary route > failing while another route is available, at least not before let's say Tor > adopts MPTCP, but not sure if that's even being considered currently. This sounds like the most viable option: to improve the UI to enable (technologically and knowledge-wise) the user to proxies like Orbot. > - A native full-blown P2P implementation with all the bells and whistles > like Syncthing would be the best, but it would also require the most > development effort. I wish there would be a FOSS VPN solution that's as good > as Syncthing to be piggybacked on with the proxy option, although a native > implementation would be always superior mostly on mobile devices with > limited battery life. This could be still combined with the usage of an > overlay network if more privacy or security is desired. This sounds similar to Tor Browser, which combines Firefox/Fennec with a Tor proxy. I am not familiar with Android programming, but out of context I guess there is no easy-to-use plug-and-play Tor proxy to KDE Connect to use. tl;dr: thank you for your detailed answer. Two results: (1) KDE Connect can improve its UI to better support/integrate with Orbot, starting by rewording labels suggesting that it is possible. (2) For a solution to connect KDE Connect on Android/iOS with a desktop across network boundaries, use an existing VPN. While not a perfect solution, it is the most practical one. Pedro, Albert: unless you want to add some technical aspects on integrating overlay networks, I suggest to re-classify this bug as a request to change the UI, or close the bug as "not a bug" (nothing is broken) or "unmaintained" (nobody will every implement it). -- You are receiving this mail because: You are watching all bug changes.
