Last weekend I attended the Linux App Summit (LAS) 2023 in Brno, Czechia, to speak about push notifications and to get a few remaining interoperability issues sorted out.

LAS

While my goal for last LAS was to finally meet people in person again for the first time since the pandemic, I had a much more specific objective this time, get the remaining questions around UnifiedPush on Linux sorted out.

Photo of the UnifiedPush talk at LAS 2023.
UnifiedPush talk at LAS 2023 (photo by Aleix Pol).

Having the talk scheduled early on Saturday was perfect for that and enabled a couple of discussions with others interested in that topic during the rest of the conference.

I’ve put the slides here, a video recording can be found in the livestream capture on YouTube here (the one on the LAS PeerTube channel unfortunately misses the beginning).

Push Notifications

Most importantly, there’s broad consensus that push notifications are needed and wanted on Linux, as well as on the requirements:

  • Work out of the box without interaction/setup.
  • … but also allow for self-hosted infrastructure for people having access to that.
  • Provide transparency and control for the user.

So as I had hoped (and expected) it’s “just” down to sorting out the remaining implementation details.

Flatpak support

Flatpak interoperability for UnifiedPush was the number one feedback in all conversations.

I have meanwhile put the public alerts demo into a Flatpak to test this, and apart from needing extra permission to access the host distributor (--talk-name=org.unifiedpush.Distributor.*) it does work.

Removing the need for the extra permissions will need a portal API for push notifications, which then would also allow implementing explicit permission management for this if needed.

D-Bus API for listing active subscriptions

This is also rather uncontroversial and mostly seen as necessary. Here the next step is probably to write a proposal for a UnifiedPush specification extension.

Also interesting in this context was looking at microG’s version of this, which shows additional details like the amount of received notifications per app and the last activity. Supporting that in the UI would be easily possible with some additional information in the above interface, but it would require quite some extra tracking work from each distributor, not sure that’s worth the effort.

Distributor selection

That’s the most annoying open question, and the one the feedback varied the most on. The range of options still goes from enforcing a single platform distributor and basically exclude support for any scenario with multiple choices up to an architecture that would transparently allow supporting all kinds of complex setups, at the cost of an extra proxy distributor process.

There were good arguments for all of this, which doesn’t really help with deciding on a way forward though.

Common free desktop distributor implementation

This seemed to be the generally preferred approach over each environment doing their own thing. How exactly that would look like and where that would end up being hosted (FreeDesktop? UnifiedPush?) remains to be seen though.

There were however different opinions on whether a single distributor implementing a handful of practically relevant protocols is the right approach in general, or whether the one distributor per push provider model would be better (as originally intended by UnifiedPush).

Outlook

The first thing to progress now is the Flatpak integration, depending how exactly the portal integration will look like things might also clear up for the remaining questions around distributor selection.

LAS wasn’t all about push notifications though, there were more interoperability topics to talk about. One example being handling of popup notification actions for non-running applications, something also for the upcoming Plasma 6 sprint in Augsburg, Germany next week.

And of course there is no travel without some improvements to KDE Itinerary, this being no exception. Train strikes on Friday were particularly helpful with testing trip cancellations, and we also got an important change to libQuotient merged which will enable upcoming group travel features :)

As you can see such events are extremely productive, and can be supported by sponsoring and/or donations to the KDE e.V..