At KDE Akademy early October I presented how we could get push notifications for KDE applications, something I haven’t written about here at all yet. Time to rectify that.

Push Notification

Push notifications are a mechanism to support applications that occasionally need to receive some kind of information from their server-side part, and where receiving in a timely manner matters. Chat applications or weather and emergency alerts would be examples for that.

Technically applications can achieve this by keeping a long living network connections to their respective server. This is however neither efficient nor robust, especially on resource-constrained or battery powered devices. Each additional network connection costs energy to be kept alive, and all this only works as long as the application is actually running, which conflicts with aggressive suspending of (background) applications to conserve resources.

Push notifications address this by moving parts of this to shared platform infrastructure. A platform service keeps a single network connection to a central server which collects all messages for a specific device. On receiving a message on the client the respective application is activated and the message is delivered to it.

This avoids keeping more than one long-running network connection alive, and it works no matter whether the receiving application is running or not.

Proprietary Platforms

Conceptually that works, but practically we have the problem that those systems only really exist on proprietary platforms, in particular the mobile ones of Google and Apple. Those systems are neither usable on platforms we are more interested in, nor can they be replaced by a more trusted and/or free alternative on their platforms.

The proprietary ecosystems also have the additional problem of the high abuse potential of giving app vendors the ability to start their app remotely on your device.

So, none of this is really what we want and you can probably guess where this is going, we need to build this ourselves.

UnifiedPush

This isn’t something specific to KDE though, and fortunately the FOSS community has already done the groundwork, in form of the UnifiedPush standard.

Diagram of the UnifiedPush architecture.
UnifiedPush architecture diagram (by UnifiedPush, Apache-2.0).

The UnifiedPush standard defines the interfaces that the client and server parts of an application can use to register for and receive push notifications. These interfaces aren’t particularly complicated and use standard protocols like D-Bus on the client and REST on the server.

There isn’t just a standard though, multiple implementations exist as well, such as Ntfy or NextPush. Those are pretty solid when comes to their server part and the Android client components, but the Linux client components are lagging a bit behind.

KUnifiedPush

Fortunately that is something we can fix, which is what KUnifiedPush attempts to do. This currently contains three separate components:

  • A connector library for use by applications on the client. This allows registering for push notifications and receiving push messages.
  • A distributor daemon for the client platform which supports Ntfy, NextPush and Gotify as push providers.
  • A configuration module (KCM) for the distributor daemon, for configuring a push provider and for managing applications currently registered for push notifications.
Screenshot of push notification settings page showing push provider configuration and applications registered for push notifications.
KUnifiedPush KCM embedded in System Settings.

KUnifiedPush gives you full transparency and control over which applications are using push notifications and why, which goes a long way already to mitigate potential abuse like on the proprietary platforms.

It also enables the use of self-hosted infrastructure, which is great but probably something only available to a minority of our users. In order for applications to be able to rely on push notifications being generally available we would also need a default configuration that works out of the box though.

Infrastructure

Having such a viable default configuration practically means we also need to host the push provider server ourselves, without the need for signing up for any form of user account. Technically that is possible, as Ntfy shows with their open server.

However, operating infrastructure also comes with privacy and legal challenges:

  • A push provider server holds active network connections to basically all clients, and thus also sees the times they are active and their IP addresses.
  • Push message payloads are seen by the push provider. Applications are supposed to encrypt those, but there is no way of enforcing that.
  • Push message might need to be stored for a limited period of time (say a day or two), for clients currently unable to connect.
  • There is no authentication on either side of this. That is somewhat by design to avoid even more sensitive identifiers and data to be around, but it also makes it more difficult to block malicious actors.
  • It is theoretically possible to abuse this for storing small amounts of arbitrary data. Given the abuse issues we had with the pastebin service, that could be problematic, even if this is far more involved to (ab)use, and only works for a much shorter period of time.

None of this is an insurmountable obstacle I think, but these are clearly things needing careful consideration.

So, is this worth pursuing? Do we as KDE want to host and provide generally available push notification infrastructure?