is this cross-distro, cross-desktop, and cross-package-format?

[probonopd]

The name "xdg" implies this is a cross-* standard of some sort.

Is it?

• Is this supposed to end up in every distro (occasionally people a a bit quick to claim such when in fact the proposal has not really been discussed)?
• Is this supposed to end up in every desktop (e.g., KDE, XFCE, etc.) or is it a GNOME-only thing?
• Is this supposed to work with different packaging/bundling formats (e.g., Snap Packages and AppImage) as well, or is this purely a Flatpak-only thing?
• Is this supposed to work with different sandbox/confinement technologies (e.g., Firejail) or is it a Bubblewrap-only thing?

I am a bit confused because on the one hand, "xdg" suggests it has a very wide scope, but then there are files in the source code that suggest it is specific to Flatpak. Please clarify.

[matthiasclasen]

Too many open-ended questions. That's much better discussed in a different channel. As a short answer, it is not really that relevant whats "supposed" to happen. We plan to work on kde backends for the portals too, fwiw.

[alexlarsson]

cross desktop can mean many things. We will make the interfaces for the desktop portal implementable and usable from both gnome and kde (i.e. any APIs will be at some level a common subset of gtk/qt apis). We will also work on qt and gtk implementations.

Furthermore, we're working with various people, including canonical employees working on snappy so that we can share portals as much as possible with them. It may be the case that some parts of portals need to be per-app-system, but the goal is to at least share the API used by the apps, so that they only have to be modified once.

That said, I don't quite understand how something like AppImage could use a portal infrastructure. AppImage seems very much designed around not needing any runtime support (other than fuse), whereas deeper integration like portals is going to require a certain amount of runtime support on the host. For instance, it definately needs some kind of dbus filter (flatpak uses a userspace proxy).

[probonopd]

Good points @alexlarsson and thanks for the clarification. One could imagine a system in which any "untrusted" software could be run with low privileges, and use portals to raise privileges where required (independently of any particular packaging or bundling scheme being used). One could see this mainly as a feature of the sandboxing/confinement system (e.g., Bubblewrap, Firejail) rather than any particular packaging or bundling scheme, right?

[alexlarsson]

The fundamental requirements for portals are two things:
a) Confinement of the app, including some form of dbus filtering (i.e. allowing access to the portal, but not other unconfined dbus services like the portal desktop implementations).
b) The ability of the portal to query the "peer" application id (i.e. desktop file name/dbus name) in a way that is not fakeable for sandboxed apps.

Flatpak uses bubblewrap + a userspace dbus filtering proxy for a, and uses systemd --user to set a cgroup encoding the app id for b.

[matthiasclasen]

Its not just dbus filtering, either. If you can see all of the filesystem, you can just use a filechooser. For a portal system to make sense, the app really needs to be sandboxed.

[matthiasclasen]

I don't think this issue needs to remain open. The questions have been answered as far as possible