Shipping libnotify-bin as part of a snap balloons its size by 14mb. That however is not the main issue.
Notification system today is part of the platform in all modern systems (classic distros, or other OS(s)) and is part of the application development story. Hence I believe confined snaps should be able to talk to libnotify on the system somehow instead of shipping its own copy. IOW notify-send needs to have the same treatment that xdg-open got i.e. ship a script as part of the core snap, which tells snapd to talk to the platform to show the notification.
AFAIK notifications are covered by a Freedesktop spec with quite simple DBus API. You do not need to use notify-send. You don’t even need to use libnotify if your app is using sufficiently recent glib. Mediation of DBus calls is already covered by the desktop interface.
it is my understanding that xdg-open is special in the sense that its use is quite universal, dates back a lot and until portals emerged there was no other API for sandbox applications to achieve this. IOW, your application was tightly coupled with xdg-open being available in your $PATH and having access to the configuration files in your ~/.config which obviously is a problem with sandboxing.
In contrast, the Notifications are a DBus thing, so all you need is the ability to mediate DBus. There’s a Notifications portal provided by the xdg-desktop-portal now (maybe @jamesh knows whether it’s fully functional). However, I would expect the portal to be the only notification proxy for sandboxed apps to use in the long term.
notify-send has never been a great way to post desktop notifications, since it exposes a small subset of what you can do with notifications. For example, it offers no way to respond to the notification, and doesn’t associate the notification with a desktop application.
It’s also worth noting that GNOME 3 adds a new notification API that is described here:
This one supports notifications persisting after an application exits, and doesn’t wake every application when a notification is clicked on. In addition to this, there is an xdg-desktop-portal notification API:
This one is basically there to cover the case that both the FDO and GTK notification APIs make it possible to impersonate another application. We’re not yet at a point where we can reliably support the GTK or portal notification API’s though, since they rely on D-Bus activatable desktop files to handle notification actions. We’re slowly getting to the point where we should be able to handle it though.
If you are writing an application that needs to handle notifications, I would suggest using GLib’s GNotification API rather than shelling out to notify-send. This should provide the best experience going forward.
