The road to KDE Connect 2.0

KDE Connect was designed 10 years ago (!) with Android smartphones as one of our first supported platforms. Because of that, when designing the KDE Connect protocol we had to work around many technical limitations that Android had back in its infancy.

This year I will be working on a project named “KDE Connect discovery and transport protocol improvements” that received a grant from the NLnet foundation as part of the NGI Assure fund. This grant will allow me to work full time in KDE Connect, with the goal of updating the protocol and apps to modern standards.

Below are the 3 main areas that will improve thanks to this and become KDE Connect 2.0 (even though some changes will show up sooner, because we release early, release often).


The strength of KDE Connect (compared to some of the non-free alternatives that popped up in these last 10 years) is that KDE Connect only uses your local network for communication and doesn’t need intermediary servers in “the cloud“. This adds a challenge: devices running KDE Connect have to discover each other in the network before they can talk to each other.

Discovery is possible in the current protocol using UDP broadcasts, but the state of the art nowadays is to use multicast DNS (mDNS) instead, which is more reliable and less often blocked by the network configuration. We wanted (and tried) to adopt mDNS for a while, but it was a a bigger endeavour than what we could tackle.

By focussing full time on this, my goal is to implement an mDNS backend for KDE Connect on all supported platforms (Linux, Windows, MacOS, Android and iOS) before fall this year. Wish me luck!


Before Android 5, only TLSv1 and a limited set of cipher suites could be used. We always try to stay compatible with old devices and to fight the programmed obsolescence that plagues modern technology, but that meant keeping the KDE Connect protocol compatible with insecure encryption protocols.

Starting with KDE Connect v1.22 for Android, we now require Android 5 or later so we can drop compatibility with insecure encryption in all the KDE Connect implementations (and not only Android). In addition to that, we are reviewing and updating the dependencies we bundle as part of the app to make sure we have the latest security patches.

Later this year, and also thanks to NLnet, we will get a security audit by Radically Open Security. This will be the second time KDE Connect is audited, after the openSUSE security team did so in 2020.


We recently adopted Material 3 in the Android app (thanks Dmitry Yudin for doing most of the work!) and KDE as a whole is getting ready to migrate our desktop apps to Qt6. These times are a perfect opportunity to review the accessibility of our user interfaces, and for that NLnet is helping us get an accessibility audit by the HAN University also later this year.

All in all, exciting times for the KDE Connect project! Stay tuned for future updates :)


50 thoughts on “The road to KDE Connect 2.0

  1. Awesome news! Do you think that besides mDNS, also a) a Bluetooth connection could be used to in the future and/or b) a WiFi hotspot to quickly hook up a connection between one’s phone using KDE Connect and the applet running on the desktop or laptop?

    1. I remember asking that same question a few years ago, and was given the answer that the android wifi hotspot feature Just Works with kde connect, which it did (including the usual discovery delay, but that’ll hopefully be fixed with mDNS, too)

    2. Bluetooth connection in addition to WiFI would be great, yeah.

      Though, ngl, I would also really love it if an online server could be supported (though initial connection being local-only would be a good compromise). I wouldn’t mind paying KDE for use of it, especially if it’s done a la Bitwarden with option for self-hosting.

      Also, scrcpy integration would be the most awesome thing, as that is one function that WIndows Companion App that I miss.

  2. Great news! KDE Connect is a killer app.

    For version 2, I would like to suggest a new feature.

    From time to time, I need to put a handwritten signature on a pdf (like an administrative form); for that I have to send the pdf from my computer to my smartphone, then sign it, and finally send it back to my computer.

    Would it be possible to use kde-connect, on my smartphone, to write my signature in a pdf opened in Okular on my computer?

    It seems to me that this feature would be very useful for many people.

    Thanks to all the team for your great work.

    Translated with (free version)

    1. Can’t you use the remote input plugin such that your touch screen on the phone acts as the pointer on the computer?

      1. It is possible, but inserting a recognizable signature in Okular is not precise enough. This solution is too close to what you would get by signing with your finger on a touchpad
        I’m thinking more about okular “calling” the smartphone to use it as a small graphic tablet via kde-connect.
        The problem with pdf administrative forms is that they are usually dense and there is very little room for a signature.
        It would be necessary to be able to capture the drawing on the smartphone to insert it in this small dedicated space.
        Obviously it would be easier if we all had an electronic identity card with a digital signature certificate.
        But unfortunately the French administration is far from being so modern!

  3. Sweet. Were I live multiple users share the network. Its overloaded. I tried to hack on KDEconnect to use Bluetooth. Its kinda working. Any changes on that or network usage with your work, will it use less or more network with this? And sharing network to PC from phone, will that improve with this?

  4. Great news, thanks! Would be awesome to have a connection via Bluetooth too, it’s it hard to implement?

    1. How is mDNS “less often blocked by the network configuration”? It took me hours to realize mDNS was a problem which blocked me from using scanning(but not printing for some reason) between VLANs and I had to configure it on pfsense.

    1. Yes, but this is not so easy way for regular users, and also not so battery friendly, so natively connecting via Bluetooth com port would be much better!

  5. It would be so awesome to be able to sync windows outlook 2003 to android using caldav/carddav using kdeconnect.

  6. Any chances for sharing not only files but directories/folders with their content in it between devices?

  7. Please make sure the new KDE Connect application for Linux works well on Linux phones like Pine64’s PinePhone.

  8. This could be a good opportunity to see the following information to the protocol:
    Event input selected/unselected and type of input like numeric/email/password or similar. This allows clients with remote input plugin to automatically show/hide the most fitting on screen keyboard while using all space for touch/pointer input when no input is selected.

    This should basically show the same behavior as a local on-screen keyboard just on another device instead.

    This information should be available in Wayland.

  9. It would be great to have a way to send clipboard content from phone to computer ONLY and not vice versa, for security peace of mind.

    1. Yeah! And maybe even better to have a separate action “get clipboard / send clipboard” instead of auto synching all the time.

  10. Hopefully, I will then be able to use an SD card that may be present in the smartphone/tablet. Only the internal memory of the smartphone/Tablet can be used. Samsung Tab s6 LTEwith Android 12

  11. Great!!
    Good luck with that!!
    Es fascinante ver cómo una aplicación que empezó de modo tan modesto, se convirtió rápidamente en una herramienta imprescindible, muy demandada y “envidiada” en otras plataformas…

    He querido difundir la noticia entre la comunidad latina, publicando la noticia en mi blog traducida/adaptada:

    Happy hacking!!

  12. KDE-connect is great, but with time some of its functionally broke. For example, previously, when I had a call, media paused and when the call was ended, media resumed. It is no longer true. Pausing works rarely, resuming doesn’t work anymore.
    I realize, that many of the issues lies on the Android side, so we need a good kde-connect documentation to show us, how to set the Android for the best experience.
    I would also love, if kde-connect grow to something like pushbullet. Writing SMSes on it is far superior experience, because I can see my existing SMSes, start writing new ones, choose the recipient, all that with a nice UI. So, so far, I still need to use kde-connect and pushbullet to get the full connectivity between my phone an a computer. It would be nice, if kde-connect was a one solution for all those functions. However, I understand that pushbullet is a commercial project and has many devs working on it, so probably my expectations are too high.

  13. I second the option to push clipboard manually. Currently, when I need it, it doesn’t work, when I don’t need it, it syncs clipboard, or when I need it, and it works, it doesn’t sync some things only others, not sure why. I see no need to have constant synced clipboard, only reliable on-demand sync.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s