Add support for UnifiedPush #42

spazziale commented 2023年01月02日 10:01:08 +01:00 (Migrated from github.com)

For both desktop and mobile Linux, https://unifiedpush.org is a standard that can deliver push notifications over D-Bus, while allowing the end-user to self-host infrastructure. UnifiedPush on Android is already being used by a few apps like Tusky and Fedilab ( mastodon clients ) , but the Linux implementation is new.
The UP chat is at https://matrix.to/#/#unifiedpush:matrix.org

It's probably a low-priory feature, but it's a nice thing to have.

For both desktop and mobile Linux, https://unifiedpush.org is a standard that can deliver push notifications over D-Bus, while allowing the end-user to self-host infrastructure. UnifiedPush on Android is already being used by a few apps like Tusky and Fedilab ( mastodon clients ) , but the Linux implementation is new. The UP chat is at https://matrix.to/#/#unifiedpush:matrix.org It's probably a low-priory feature, but it's a nice thing to have.

julianfairfax commented 2023年07月04日 00:47:33 +02:00 (Migrated from github.com)

I don't understand why you can keep Tuba running in the background. If this feature isn't supported, what's the point of that?

I don't understand why you can keep Tuba running in the background. If this feature isn't supported, what's the point of that?

johnlpe commented 2023年07月05日 07:23:46 +02:00 (Migrated from github.com)

From #349:

Please add support for UnifiedPush push notification protocol/standard.

We need push notifications, but we don’t want use centralized online service that read we all notifications, like Android has Google Firebase Messaging Service and iOS has Apple Push Notification service. UnifiedPush protcol is the solution for this. UnifiedPush is open protocol/standard for connection between online service (Application Server) → notification service (Push Server) and notification service’s client (Push Distributor) → application (End User Application). It enables the user to choose the service through he receives his push notifications.

Especially GNU/Linux on mobile is very big need of push notifications and with UnifiedPush we can fix it.

_From #349:_ Please add support for [UnifiedPush](https://unifiedpush.org) push notification protocol/standard. We need push notifications, but we don’t want use centralized online service that read we all notifications, like Android has Google Firebase Messaging Service and iOS has Apple Push Notification service. UnifiedPush protcol is the solution for this. UnifiedPush is open protocol/standard for connection between online service (Application Server) → notification service (Push Server) and notification service’s client (Push Distributor) → application (End User Application). It enables the user to choose the service through he receives his push notifications. Especially GNU/Linux on mobile is very big need of push notifications and with UnifiedPush we can fix it. <img src="https://raw.githubusercontent.com/UnifiedPush/documentation/main/static/img/animation-flow.svg" width="300"/> <img style="float: right;" src="https://github.com/mastodon/mastodon/assets/138632900/a52dd1a5-c972-4e00-8e65-4fec1aa3a5a0" width="300" />

johnlpe commented 2023年07月05日 07:36:07 +02:00 (Migrated from github.com)

Tuba does support notifications when the app is the foreground, right? And remember the point of UnifiedPush is that one Push Distributor keep active connection. When Push Distributor receive notification it shows notifications directly or wakes up End User Application like Tuba (the notification can be only ping that isn't shown to the user and the End User Application fetch the content of the notification from the server after being woken up by UnifiedPush).

However, IDK, is UnifiedPush protocol defined a way to wake up the End User Application? It may be that the app needs to be running, but it doesn't need to do anything heavy, like keep active connect to the server. The app just need to listen Dbus.

https://github.com/UnifiedPush @p1gp1g

Tuba does support notifications when the app is the foreground, right? And remember the point of UnifiedPush is that one Push Distributor keep active connection. When Push Distributor receive notification it shows notifications directly or wakes up End User Application like Tuba (the notification can be only `ping` that isn't shown to the user and the End User Application fetch the content of the notification from the server after being woken up by UnifiedPush). However, IDK, is UnifiedPush protocol defined a way to wake up the End User Application? It may be that the app needs to be running, but it doesn't need to do anything heavy, like keep active connect to the server. The app just need to listen Dbus. https://github.com/UnifiedPush @p1gp1g

GeopJr commented 2023年07月05日 07:43:57 +02:00

I don't understand why you can keep Tuba running in the background. If this feature isn't supported, what's the point of that?

The renaming of this issue should make it a bit more clear:

• Tuba has notifications, as long as it's running (either on the foreground or the background (with --hidden or when "background work" is enabled etc))
• UnifiedPush allows you to receive notifications without Tuba constantly running / keeping an active websocket connection to your instance

This issue is low priority however.

> I don't understand why you can keep Tuba running in the background. If this feature isn't supported, what's the point of that? The renaming of this issue should make it a bit more clear: - Tuba has notifications, as long as it's running (either on the foreground or the background (with `--hidden` or when "background work" is enabled etc)) - UnifiedPush allows you to receive notifications without Tuba constantly running / keeping an active websocket connection to your instance This issue is low priority however.

johnlpe commented 2023年07月05日 07:54:47 +02:00 (Migrated from github.com)

UnifiedPush allows you to receive notifications without Tuba constantly running / keeping an active websocket connection to your instance

Yup, and I think supporting UnifiedPush it pretty trivial. The standard defines a quite simple way to receive notifications and I think UnifiedPush contributors on https://matrix.to/#/#unifiedpush:matrix.org are happy to help. Also tehere is KUnifiedPush library by KDE.

https://unifiedpush.org/spec/dbus/
https://invent.kde.org/libraries/kunifiedpush
https://www.volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.html
https://discourse.gnome.org/t/push-notifications-for-linux/16074

This issue is low priority however.

Why you think so? I think this is very important for GNU/Linux on mobile.

> UnifiedPush allows you to receive notifications without Tuba constantly running / keeping an active websocket connection to your instance Yup, and I think supporting UnifiedPush it pretty trivial. The standard defines a quite simple way to receive notifications and I think UnifiedPush contributors on https://matrix.to/#/#unifiedpush:matrix.org are happy to help. Also tehere is KUnifiedPush library by KDE. https://unifiedpush.org/spec/dbus/ https://invent.kde.org/libraries/kunifiedpush https://www.volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.html https://discourse.gnome.org/t/push-notifications-for-linux/16074 > This issue is low priority however. Why you think so? I think this is very important for GNU/Linux on mobile.

GeopJr commented 2023年07月05日 08:11:29 +02:00

Why you think so? I think this is very important for GNU/Linux on mobile.

Someone (probably me) needs to write bindings to the C/Go library and the wording on all related pages doesn't sound that promising:

NOTE: This library is unstable as long as it's on version 0.x.x
(https://github.com/UnifiedPush/go_dbus_connector)

Linux support is still experimental, also check out KUnifiedPush for an application-framework (KDE) based implementation.
(https://unifiedpush.org/developers/go_c/)

> Why you think so? I think this is very important for GNU/Linux on mobile. Someone (probably me) needs to write bindings to the C/Go library and the wording on all related pages doesn't sound that promising: > NOTE: This library is unstable as long as it's on version 0.x.x (https://github.com/UnifiedPush/go_dbus_connector) > Linux support is still experimental, also check out [KUnifiedPush](https://invent.kde.org/libraries/kunifiedpush/) for an application-framework (KDE) based implementation. (https://unifiedpush.org/developers/go_c/)

johnlpe commented 2023年07月05日 08:29:43 +02:00 (Migrated from github.com)

Someone (probably me) needs to write bindings to the C/Go library and the wording on all related pages doesn't sound that promising:

Eh, the killer feature for v2.0 of Tuba?😆

> Someone (probably me) needs to write bindings to the C/Go library and the wording on all related pages doesn't sound that promising: Eh, the killer feature for v2.0 of Tuba?:laughing:

julianfairfax commented 2023年07月14日 10:13:56 +02:00 (Migrated from github.com)

Tuba has notifications, as long as it's running (either on the foreground or the background (with --hidden or when "background work" is enabled etc))

I have never gotten these, despite the fact that I run Tuba in the background. When I "open" the app (so just bring it forward basically), it shows there are a lot of notifications, but I never receive any notification on my desktop. I'm running the Flatpak.

> Tuba has notifications, as long as it's running (either on the foreground or the background (with --hidden or when "background work" is enabled etc)) I have never gotten these, despite the fact that I run Tuba in the background. When I "open" the app (so just bring it forward basically), it shows there are a lot of notifications, but I never receive any notification on my desktop. I'm running the Flatpak.

GeopJr commented 2023年07月14日 22:10:24 +02:00

Could you open a new bug issue for it? Preferably with logs (flatpak run dev.geopjr.Tuba) - specifically any errors before or after messages that start with "Opening stream: ". FWIW, notifications have been supported since Tootle / before Tuba and they use the portal so something else is going on.

Could you open a new bug issue for it? Preferably with logs (`flatpak run dev.geopjr.Tuba`) - specifically any errors before or after messages that start with "Opening stream: ". FWIW, notifications have been supported since Tootle / before Tuba and they use the portal so something else is going on.

p1gp1g commented 2026年01月14日 07:58:39 +01:00 (Migrated from github.com)

Hey. I'm trying to improve UnifiedPush ecosystem on Linux.

Do you think a libunifiedpush (.so) would help its adoption? Would it help you to support it? Or, as the protocol is pretty simple, do you think it would be more efficient to get an implementation per framework directly?

---

Mastodon supports standard web push (RFC8030, RFC8291, RFC8292) since version 4.4.0. Web push is the server to server protocol used with UnifiedPush. We can describe UnifiedPush as web push for applications. It means you can properly receive and decrypt your Mastodon events with the protocol, you don't need to synchronize with the server on push

---

@johnlpe

However, IDK, is UnifiedPush protocol defined a way to wake up the End User Application?

Yes, using D-BUS activatable services

Hey. I'm trying to improve UnifiedPush ecosystem on Linux. Do you think a libunifiedpush (.so) would help its adoption? Would it help you to support it? Or, as the protocol is pretty simple, do you think it would be more efficient to get an implementation per framework directly? --- Mastodon [supports standard web push](https://docs.joinmastodon.org/methods/push/#create) (RFC8030, RFC8291, RFC8292) since version 4.4.0. Web push is the server to server protocol used with UnifiedPush. We can describe UnifiedPush as web push for applications. It means you can properly receive and decrypt your Mastodon events with the protocol, you don't need to synchronize with the server on push --- @johnlpe > However, IDK, is UnifiedPush protocol defined a way to wake up the End User Application? Yes, using D-BUS activatable services

GeopJr commented 2026年01月15日 09:29:13 +01:00

Do you think a libunifiedpush (.so) would help its adoption? Would it help you to support it? Or, as the protocol is pretty simple, do you think it would be more efficient to get an implementation per framework directly?

Hey! On GNOME-land, I believe it would, but specifically with gobject-introspection (so all languages in the ecosystem (python, vala, js, rust etc) get automatically generated bindings). Now that the dbus doc feels more complete than the last time I gave it a try, even if you aim for a non-glib-based library, someone could easily create one with some additional helper functions.

Would it help you to support it?

I've been pretty busy since the last release so I can't make any promises. Since this issue was opened, Tuba's notifications have changed a bit, from filtering to multi-account aware notification quick actions. Judging from Android apps, this is something UnifiedPush doesn't prevent in anyway but it requires more studying from my side which I don't have the time for at the moment.

> Do you think a libunifiedpush (.so) would help its adoption? Would it help you to support it? Or, as the protocol is pretty simple, do you think it would be more efficient to get an implementation per framework directly? Hey! On GNOME-land, I believe it would, but specifically with gobject-introspection (so all languages in the ecosystem (python, vala, js, rust etc) get automatically generated bindings). Now that the dbus doc feels more complete than the last time I gave it a try, even if you aim for a non-glib-based library, someone could easily create one with some additional helper functions. > Would it help you to support it? I've been pretty busy since the last release so I can't make any promises. Since this issue was opened, Tuba's notifications have changed a bit, from filtering to multi-account aware notification quick actions. Judging from Android apps, this is something UnifiedPush doesn't prevent in anyway but it requires more studying from my side which I don't have the time for at the moment.

p1gp1g commented 2026年04月10日 16:48:56 +02:00 (Migrated from github.com)

For information, I've just published libunifiedpush, a new library with GObject-introspection for UnifiedPush

There might be a few things to improve, we'll see when the first apps will start using it. I've tested from C and python

For information, I've just published [*libunifiedpush*](https://codeberg.org/UnifiedPush/unifiedpush-rs/src/branch/main/libunifiedpush), a new library with GObject-introspection for UnifiedPush There might be a few things to improve, we'll see when the first apps will start using it. I've tested from C and python