Forward full desktop notification payload

[safrano9999]

Summary

• forward the assigned ID and every Notify argument to WebSocket clients
• unwrap D-Bus hint variants so values such as raw image bytes remain MessagePack-encodable
• use the assigned ID for browser notification replacement and avoid logging binary hint contents
• allocate notification IDs atomically because exported D-Bus methods may run concurrently

Existing summary and body keys remain unchanged.

Tests

• go test ./...
• node --check rootfs/opt/noVNC/app/notificationService.js

[jlesage]

Hello, what is the benefit of forwarding the full notification content ?

[safrano9999]

Hi, so I probably have a completely different use case for this container—I added a DBus wrapper and am piping social media notifications from Firefox out in real time.
I asked my agent to do a deeper search to see if there was already a suitable repo before I started from scratch, and he chose yours ☺️

[jlesage]

So I'm assuming that you are using a different Javascript client to handle the notification sent by the container ?

[safrano9999]

Not quite — I kept the existing browser client in notificationService.js. Its handleWebSocketMessage() still decodes the MessagePack message and creates the browser notification. On the Go side, the path is essentially Notifications.Notify() -> NotificationMessage -> notificationWebsocketHandler(). The expanded message now makes the full freedesktop notification fields available, including the app name, replacement ID, icon, summary, body, actions, hints, and timeout.

The separate SOCIALMEDIA-SYNCHER does not scrape browser state through another JavaScript client. It observes the same org.freedesktop.Notifications.Notify traffic on the session D-Bus and supports two capture backends:

1. Plasma watcher mode: _run_plasma_backend() registers _PlasmaNotificationWatcher through _register_plasma_watcher(). Plasma then calls _PlasmaNotificationWatcher.notify() with the full notification.
2. D-Bus monitor mode: _run_monitor_backend() calls _become_monitor() (BecomeMonitor). Its handle_monitored_message() filters the Notify calls, and _notification_from_monitor_message() converts them into a RawNotification.

The auto setting tries the Plasma watcher first and falls back to the monitor. After capture, DbusNotificationSource._receive() normalizes the data into a SocialEvent and feeds it into Bridge.submit() for Telegram or webhook delivery.

A concrete use case is receiving X post notifications live in Telegram. The same event can instead be used as a ping to any webhook, so another process can be triggered or synchronized to that cadence/rhythm.

I sent you invitations with write access to two private working-copy repositories containing the patch and the syncher. I will keep that write access open for two weeks, through August 16, 2026, and then remove it again until further notice.

Just out of curiosity: what are you using this notification mechanism for on your side?

[jlesage]

The separate SOCIALMEDIA-SYNCHER does not scrape browser state through another JavaScript client. It observes the same org.freedesktop.Notifications.Notify traffic on the session D-Bus

So who is using the new notification fields sent in the websocket (from the Go side)?

Just out of curiosity: what are you using this notification mechanism for on your side?

It's used to forward desktop notifications generated by the dockerized app to the user's host browser. So an app generating a desktop notification inside the container will appear as a native notification on the user's host computer.