feat: unifiedpush #1690

GeopJr commented 2026年07月13日 16:36:19 +02:00

fix: #42

---

Uses https://codeberg.org/UnifiedPush/unifiedpush-rs/

I'm not entirely sure about the UX around it, but functionality-wise it works. One deliberate decision was to skip most of the app startup when activated through dbus. That's because it's quite expensive for stuff that's left unused for handling the notification (e.g. reading secrets, network monitor, proxy, settings etc.). So it just does the bare minimum and if activated normally it will go through the proper startup code. I do think I went a bit too far with the compile time flags and might be annoying to maintain now, might have to let it call the separate function in the non-unifiedpush compilation too...

---

Onto API:

1. on startup we create the unifiedpush instance and try to register a distributor. There's only 1 on Linux as far as I know, so I didn't bother with a UI yet, if there's more than 1, it will use the first it find, if there's 0, it will set a variable so we know that UP is not available.
2. if --unifiedpush-bg push is passed, the process will launch as a service and will die after a while (aka after it handles the message in this case). The above startup workflow will run which is basically skipping the normal workflow.
3. on new endpoint, it unregisters and then registers a webpush instance with mastodon, uses the user's settings for what types to receive and sets unifiedpush_enabled to true for the user if successful
4. on unregister, it unregisters from the instance and sets unifiedpush_enabled to false
5. on new message, it gets the account uuid from the instance (it's uuid:fedi_instance) and parses the message which includes {notification_type, icon, title, body, notification_id} among others. If it's running in --unifiedpush-bg, we basically just use the info from the message and send the notification as is, but if it's running in normal mode, we fetch the actual notification object from the ID and then send the notification like we'd normally do with our own titles, bodies, buttons, grouping, etc. That, again, allows this to be very optimized when the app is closed while fully featured when it's open.
6. For a user to register, they go to settings>notifications, if UnifiedPush + distributor is available there will be a clickable switch, otherwise it won't be clickable and the reason will be shown. Oh, and on registration, we also use the VAPID from the mastodon instance, if it has any.
7. When the settings window is closed, we also send the muted-notification-types to the webpush api so mastodon only sends us those we want. Some newer ones are missing however, so that's just true for now.
8. To support both UP and our current websocket notifications, if the user has enabled UP, the instance account will disconnect from the websocket and vice-versa
9. oh and, we never really requested the "push" permission from fedi servers so accounts will have to be re-authed to use UP

I think that's all, I don't know if I'm missing something. I'm slightly confused about https://unifiedpush.org/developers/ux/#unregistration. Am I supposed to re-register accounts that didn't manually unregister? 🤷

Other than that, I did run across some segfaults, but I didn't manage to dump them and can't reliably reproduce them so I don't know if they are from libunifiedpush or our recent huge refactors, so I'll have to further investigate/stress test it.

cc: @s1m does this sound okay?

image

fix: #42 --- Uses https://codeberg.org/UnifiedPush/unifiedpush-rs/ I'm not entirely sure about the UX around it, but functionality-wise it works. One deliberate decision was to skip most of the app startup when activated through dbus. That's because it's quite expensive for stuff that's left unused for handling the notification (e.g. reading secrets, network monitor, proxy, settings etc.). So it just does the bare minimum and if activated normally it will go through the proper startup code. I do think I went a bit too far with the compile time flags and might be annoying to maintain now, might have to let it call the separate function in the non-unifiedpush compilation too... --- Onto API: 1. on startup we create the unifiedpush instance and try to register a distributor. There's only 1 on Linux as far as I know, so I didn't bother with a UI yet, if there's more than 1, it will use the first it find, if there's 0, it will set a variable so we know that UP is not available. 2. if `--unifiedpush-bg` push is passed, the process will launch as a service and will die after a while (aka after it handles the message in this case). The above startup workflow will run which is basically skipping the normal workflow. 3. on new endpoint, it unregisters and then registers a webpush instance with mastodon, uses the user's settings for what types to receive and sets `unifiedpush_enabled` to true for the user if successful 4. on unregister, it unregisters from the instance and sets `unifiedpush_enabled` to false 5. on new message, it gets the account uuid from the instance (it's uuid:fedi_instance) and parses the message which includes {notification_type, icon, title, body, notification_id} among others. If it's running in `--unifiedpush-bg`, we basically just use the info from the message and send the notification as is, but if it's running in normal mode, we fetch the actual notification object from the ID and then send the notification like we'd normally do with our own titles, bodies, buttons, grouping, etc. That, again, allows this to be very optimized when the app is closed while fully featured when it's open. 6. For a user to register, they go to settings>notifications, if UnifiedPush + distributor is available there will be a clickable switch, otherwise it won't be clickable and the reason will be shown. Oh, and on registration, we also use the VAPID from the mastodon instance, if it has any. 7. When the settings window is closed, we also send the muted-notification-types to the webpush api so mastodon only sends us those we want. Some newer ones are missing however, so that's just `true` for now. 8. To support both UP and our current websocket notifications, if the user has enabled UP, the instance account will disconnect from the websocket and vice-versa 9. oh and, we never really requested the "push" permission from fedi servers so accounts will have to be re-authed to use UP I think that's all, I don't know if I'm missing something. I'm slightly confused about https://unifiedpush.org/developers/ux/#unregistration. Am I supposed to re-register accounts that didn't manually unregister? 🤷 Other than that, I did run across some segfaults, but I didn't manage to dump them and can't reliably reproduce them so I don't know if they are from libunifiedpush or our recent huge refactors, so I'll have to further investigate/stress test it. cc: @s1m does this sound okay? 

GeopJr commented 2026年07月13日 16:37:22 +02:00

TODO: CI flatpak libunifiedpush

TODO: CI flatpak libunifiedpush

GeopJr commented 2026年07月13日 17:55:15 +02:00

@s1m wrote in #1690 (comment):

Overall, LGTM

There is one thing I am not sure, that may be good to look at or to implement:

* When the app is started from the D-Bus activated service, the app runs in the background without UI.
* It would be great if the app could close itself:
 
 * After a few seconds if it doesn't receive new notifications
 * If another instance of the app is started with the UI. For this second point, your opinion is important. Do you think we need to add something to the lib ?

GLib.Application has a flag called IS_SERVICE, which I enable when --unifiedpush-bg is passed. That spawns the app for a few seconds, goes through the startup process and then closes if the user doesn't activate/launch it normally. I tested all cases here,

1. when a message is received and tuba is launched with --unifiedpush-bg, it skips the expensive parts of the startup (setting up the UI, networking, accounts etc) and goes straight into handling the message then it dies
2. if the user launches the app while that's happening, the app will go through the normal startup process and launch a window

(ignore the ram usage, it's wrong, I think)

kUnifiedPush launched tuba with --unifiedpush-bg, it handled the notification and died.

For this second point, your opinion is important. Do you think we need to add something to the lib ?

So no, I don't think that's important, however, it might be worth documenting somewhere that users should pass IS_SERVICE to their GApplication. I mean, it already does that when passing --gapplication-service by default (this was the service Tuba and other GTK apps install). It's briefly mentioned on https://docs.gtk.org/gio/method.Application.run.html

Now, I don't know if it would make it easier if --gapplication-service was passed by UP instead of --unifiedpush-bg. It would be "automatic" but at the same time, personally, I prefer knowing it's UP that launched it so I can skip the expensive parts of startup.

@s1m wrote in https://codeberg.org/GeopJr/Tuba/pulls/1690#issuecomment-19136429: > Overall, LGTM > > There is one thing I am not sure, that may be good to look at or to implement: > > * When the app is started from the D-Bus activated service, the app runs in the background without UI. > > * It would be great if the app could close itself: > > * After a few seconds if it doesn't receive new notifications > * If another instance of the app is started with the UI. For this second point, your opinion is important. Do you think we need to add something to the lib ? GLib.Application has a flag called `IS_SERVICE`, which I enable when --unifiedpush-bg is passed. That spawns the app for a few seconds, goes through the startup process and then closes if the user doesn't activate/launch it normally. I tested all cases here, 1. when a message is received and tuba is launched with `--unifiedpush-bg`, it skips the expensive parts of the startup (setting up the UI, networking, accounts etc) and goes straight into handling the message then it dies 2. if the user launches the app while that's happening, the app will go through the normal startup process and launch a window <video src="/attachments/57bf0204-1997-4980-bcd1-4fcb013abb7e" title="Screencast From 2026年07月13日 18-46-15" controls></video> *(ignore the ram usage, it's wrong, I think)* kUnifiedPush launched tuba with `--unifiedpush-bg`, it handled the notification and died. > For this second point, your opinion is important. Do you think we need to add something to the lib ? So no, I don't think that's important, however, it might be worth documenting somewhere that users should pass IS_SERVICE to their GApplication. I mean, it already does that when passing `--gapplication-service` by default (this was the service Tuba and other GTK apps install). It's briefly mentioned on https://docs.gtk.org/gio/method.Application.run.html Now, I don't know if it would make it easier if `--gapplication-service` was passed by UP instead of `--unifiedpush-bg`. It would be "automatic" but at the same time, personally, I prefer knowing it's UP that launched it so I can skip the expensive parts of startup.

s1m commented 2026年07月13日 18:05:35 +02:00

Thanks, so the background launch works great.

Now, I don't know if it would make it easier if --gapplication-service was passed by UP instead of --unifiedpush-bg.

You can do that if you prefer:

data/dev.geopjr.Tuba.UnifiedPush.service.in

- Exec=@BINDIR@/dev.geopjr.Tuba --unifiedpush-bg
+ Exec=@BINDIR@/dev.geopjr.Tuba --gapplication-service

So no, I don't think that's important, however, it might be worth documenting somewhere that users should pass IS_SERVICE to their GApplication. I mean, it already does that when passing --gapplication-service by default (this was the service Tuba and other GTK apps install). It's briefly mentioned on https://docs.gtk.org/gio/method.Application.run.html

Definitely agree. Where would be the best place in your opinion? As you have just implemented it, where did you look for this information? Maybe we can add an example for the D-BUS activated service in libunifiedpush readme ?

Thanks, so the background launch works great. > Now, I don't know if it would make it easier if --gapplication-service was passed by UP instead of --unifiedpush-bg. You can do that if you prefer: *data/dev.geopjr.Tuba.UnifiedPush.service.in* ```diff - Exec=@BINDIR@/dev.geopjr.Tuba --unifiedpush-bg + Exec=@BINDIR@/dev.geopjr.Tuba --gapplication-service ``` > So no, I don't think that's important, however, it might be worth documenting somewhere that users should pass IS_SERVICE to their GApplication. I mean, it already does that when passing --gapplication-service by default (this was the service Tuba and other GTK apps install). It's briefly mentioned on https://docs.gtk.org/gio/method.Application.run.html Definitely agree. Where would be the best place in your opinion? As you have just implemented it, where did you look for this information? Maybe we can add an example for the D-BUS activated service in libunifiedpush readme ?

GeopJr commented 2026年07月14日 06:36:13 +02:00

As you have just implemented it, where did you look for this information? Maybe we can add an example for the D-BUS activated service in libunifiedpush readme ?

I'd say maybe something on https://codeberg.org/UnifiedPush/unifiedpush-rs/src/branch/main/unifiedpush#start-from-a-push-notification ? The problem is that the docs will become a bit too GLib-specific then :/

## GApplication
For GLib-based applications, passing `--gapplication-service` instead or setting the [G_APPLICATION_IS_SERVICE](https://docs.gtk.org/gio/flags.ApplicationFlags.html#is_service) manually, will launch the app in "service" mode and will automatically exit after 10 seconds unless activated by the user. That will allow you to handle the UnifiedPush message without launching the GUI. [Read More](https://docs.gtk.org/gio/method.Application.run.html#description)

---

I just pushed libunifiedpush to the flatpak manifest used by the CI, it works

> As you have just implemented it, where did you look for this information? Maybe we can add an example for the D-BUS activated service in libunifiedpush readme ? I'd say maybe something on https://codeberg.org/UnifiedPush/unifiedpush-rs/src/branch/main/unifiedpush#start-from-a-push-notification ? The problem is that the docs will become a bit too GLib-specific then :/ ``` ## GApplication For GLib-based applications, passing `--gapplication-service` instead or setting the [G_APPLICATION_IS_SERVICE](https://docs.gtk.org/gio/flags.ApplicationFlags.html#is_service) manually, will launch the app in "service" mode and will automatically exit after 10 seconds unless activated by the user. That will allow you to handle the UnifiedPush message without launching the GUI. [Read More](https://docs.gtk.org/gio/method.Application.run.html#description) ``` --- I just pushed libunifiedpush to the flatpak manifest used by the CI, it works

GeopJr commented 2026年07月14日 06:36:57 +02:00

So, I'll go ahead and merge, thanks for the review, help and libunifiedpush! 🙇

So, I'll go ahead and merge, thanks for the review, help and libunifiedpush! 🙇

s1m commented 2026年07月14日 14:17:59 +02:00

Thanks a lot!

I've updated flatpak doc: UnifiedPush/documentation@e7d88607bb

And unifiedpush-rs README for Gapplications: UnifiedPush/unifiedpush-rs@ca0e5f9120

Thanks a lot! I've updated flatpak doc: https://codeberg.org/UnifiedPush/documentation/commit/e7d88607bb371e44c905d5f67220e42fbec7e2be And unifiedpush-rs README for Gapplications: https://codeberg.org/UnifiedPush/unifiedpush-rs/commit/ca0e5f9120328e508b1dff222485cfb83d7a860f

s1m commented 2026年07月14日 14:19:09 +02:00

If you're OK, I'm going to post something with UnifiedPush's Mastodon account to introduce UnifiedPush support in Tuba

If you're OK, I'm going to post something with UnifiedPush's Mastodon account to introduce UnifiedPush support in Tuba

GeopJr commented 2026年07月14日 15:53:12 +02:00

Sure, though users won't see it until the next major release, so just don't make it sound like they can use it right away!

Sure, though users won't see it until the next major release, so just don't make it sound like they can use it right away!