LibP2P Backend for KDE Connect (P2P over internet)

Brainstorm
,
1

TL;DR: Make KDE Connect to work across different networks/NATs without complex VPNs or manual configuration by Integrating libp2p as a new backend to handle automatic hole punching, relaying, and encryption. Benefits - Provides a “it just works” experience, enables features like a WebRTC-based web interface. Trade-off: opt-in feature to balance increased battery/resource usage (maybe?) with seamless connectivity over internet/across networks.

Hi All,

currently one of the frustrating issues with KDE Connect was having to be on same network without per-device Isolation. I get that this is to avoid exposing it to internet, and to totally avoid interacting with third party server, but it still feels limiting.

Even soutions like Tailscale is not the best as most normal users don’t even know about it, and even for experienced devs, it’s clunkly solution as it’s normally constantly fight with other VPNs, like consumer ones or work related ones.

I have been trying to overcome this for years now, and tried ideas like having a web interface for kde connect. - GitHub - Vaisakhkm2625/kde_connect_webapp_poc: a web interface for kde connect, using tailscale · GitHub

and over the years people are tried to sovle this multiple times - Relay Servers (For When Users Is Behind Firewall/VPN) . I know a bluetooth backend development is going on, but it doesn’t provide the same experience as wifi. especially on travel.

But recently i came across this https://libp2p.io/
This is a lib created as a starting point for almost any p2p app, as to avoid reinventing everything from authentication, autherization, encryption to UDP hole punching and relay servers. as most p2p projects like bittorrent reimplimenting these again and again.
This lib has essentially become the backbone of cryto currency projects, so security wise it’s in great shape with constant development.

libp2p has support for anything from raw TCP to websockets and webrtc and much more. by implementing this, we can essentially provide something like a KDE Connect webapp, where a website can connect to our device over webrtc.

I am imagining implementing this as a new backend like libp2pLinkProvider by extending BaseLinkProvider just like how Bluetooth backend or LanBackend, but we don’t even need to handle self-signed certificate exchange or mDNS discovery ourself has it’s handled in the lib itself.

the lib has bindings for almost all languages (for us jvm-libp2p and cpp-libp2p are mature as well.. )

drawbacks

  • Biggest drawback is that, it’s little on the heavier side, as it’s keep a constant stream of rather than sending each packet sperately (so keep-alives can drain battery). but on android side we can configure to be a “DhtClient” (only querying).
  • 3rd party lib - I don’t know how much KDE projects like to add 3rd party libs. but in this case, I hope the benefits outweigh the problems by having a battle tested implementation.
  • Not everyone appreciate it connecting over internet, so need to make it opt in.
2 Likes
2

It being a plugin for KDE Connect wold be comfortable: I currently can’t connect to the same net as my computer because the my WiFi is too far and I’ve always looked for something to connect over the internet.

3

exactly.. (for now you can use tail-scale to connect over internet though)

1 Like
4

It’s not a magical solution that makes all things connect everywhere. You still need to bootstrap or discover from some origin record somewhere as a served resource.

Today kde connect uses broadcasts to connect, meaning they spew a packet to the network broadcast on switched LAN so that everyone gets a copy, and interested receivers will respond in kind. Even bittorrent on the internet relies on a source record (ie. piratebay and like) and seeders hosting the content, so it doesn’t fix your connection issue between endpoints on a non-broadcast/multicast network without an upstream component.

Most vpn’s, even tailscale don’t like broadcast/multicast, so you still need some sort of unicast port traffic to phone-home and connect to some central resource. This is usually where dns and service records come into play.

Now ideally kde connect would include the ability for endpoints to target a host by ip/fqdn, and you use some form of internal dns, but it doesn’t today. A nice alternative at some point is kde connect would act as a server all your connections register and allow them to find each other over unicast by ip, even a tailscale network, and one box could act as a central arbiter/server on the local lan with a dns record as the origin for discovery for everyone.

What you do NOT want is vermin apps using uPnP to open random ports into your network firewall like bittorrent seeding. It was sold as a feature in consumer garbage routers to ease gaming for fools, but that should really never be enabled to allow things in dynamically as you’re defeating the point of network security and only inviting wolves into the henhouse doing so.

5

  1. libp2p uses Hole Punching instead of UPnP. no public port is opened or exposed. (meaning, think like when you send a request to server, how that server can reach back to you with response over internet - we are just using that feature, but in both side)
    Also, most of the time, it’s useless to port forward as the home routers would be behind a CG-NAT anyway so it can’t reach internet…

    It’s not a magical solution that makes all things connect everywhere. You still need to bootstrap or discover from some origin record somewhere as a served resource.

    Yes, it’s not magic. that’s where Bootstrap Nodes comes. we can have few central bootstrap nodes hosted publicly, which then uses a distributed hash table, so data is not held by one party, but shared across nodes - best part is, this node can be local computer itself. And remember, the proposal is to given it as a opt in plugin feature for people who wanted that.

    if we need KDE Connect to work over internet, anyway we need to created some sort of relay/discovery system if it have to work over internet.. and advantage of libp2p is it’s a battle tested lib that already does that , along with handling e2e encryption and authorization - i assume KDE connect developers don’t have enough resources to make a custom protocol secure over internet, so I hope using a production ready lib make sense…