If a mobile device running KDE Connect and the corresponding desktop are located in different network subnets (e.g. mobile network and an organization's firewalled LAN, respectively) and the distance in between is too large for Bluetooth, communication between both endpoints may be impossible unless manual steps like establishing a VPN first are taken. My proposal is that all KDE Connect instances (mobile and desktop apps) have either TOR or I2P or both built-in, so that both endpoints have a better chance of communicating with each other if other means fail. Using either hidden service comes at the cost of additional latency and limited bandwidth, so it should only be a fallback if 'normal' network and Bluetooth are not available. To avoid security/trust issues and to not bother the user with technical questions, two endpoints should automatically exchange public keys and hashes when connected the first time via WiFi or Bluetooth, and make use of those credentials for future connections via hidden services if the need arises. The use of hidden services should be both compile-time configurable (if packages do not want to have this feature included) and run-time configurable (if users want to avoid generating traffic that may look suspicious to network security).
This sounds like it should be multiple separate feature requests, but they are also not necessarily the best ways to reach the goal mentioned in the description, so the title is somewhat misleading about what may be needed here. The current public key comparison by the user during pairing should already cover identity security as a starter. Given that many people/entities are afraid of the mentioned overlay networks, it's likely more palatable to focus on the goal of connectivity when the devices are either not in the same logical network, or a direct connection between them is forbidden. This issue can be approached by multiple ways: - 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. - 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. - 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.
(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).