Containers (#171): finalize metadata representation
User stories
xdg-desktop-portal maintainers would like to be able to use #171 generically, to identify applications that are managed by a non-Flatpak, non-Snap container manager without having to write container-manager-specific code for it.
Some non-maintainers commenting on #171 are not happy with the metadata representation in various ways.
Description
One big issue in x-d-p is that right now we need sandbox engine specific ways of looking up metadata like the desktop file. The sandbox engine could provide this information to us easily.
I am sympathetic towards this view, but the design that was merged (and then disabled in late 2021) did not address this: it only had:
-
type: Reversed domain name identifying a container manager or container technology, as passed to the
AddServer
` method, such as org.flatpak or io.snapcraft -
name: Some unique identifier for an application or container, whose meaning is defined by the maintainers of the container type.
- Implementation detail: for Flatpak, I expect that this would be the Flatpak app ID (
$FLATPAK_ID
), a reversed DNS name, for exampleorg.gnome.Weather
. Flatpak apps are constrained to only be allowed to export AppStream metadata that is either$FLATPAK_ID
or$FLATPAK_ID.desktop
, Desktop Entry files that are$FLATPAK_ID.desktop
or$FLATPAK_ID.anything.desktop
, D-Bus names that are in a similar namespace (unless special permissions are added), and so on. - Implementation detail: for Snap, I expect that this would be the Snap app ID, which is a short string like
firefox
orsteam
in a namespace curated by Canonical's single canonical Snap repository, and does not necessarily have anything to do with the AppStream or Desktop Entry namespaces.
- Implementation detail: for Flatpak, I expect that this would be the Flatpak app ID (
-
metadata:
a{sv}
of metadata describing the application or container, with the keys and values defined by the maintainers of the container type.
We could get what @swick is looking for by simply redefining the spec for metadata, for example using the same sort of namespacing as Features: we could say that names with no dot are defined by the D-Bus Specification, or by some freedesktop.org spec shared by D-Bus and Wayland (for example we could say that desktop_id
is an exported Desktop Entry for the app), while names with a dot are reversed-DNS and defined by the domain owner (for example Canonical could define com.ubuntu.apparmor_profile
and make Snap set it, if they want to).
Meanwhile, @WhyNotHugo requested an "instance ID" as a top-level thing (presumably namespaced by the type, and available in all the same places that the type and name are), and @swick pointed out that the equivalent Wayland specification has an instance ID (although not yet any extensible metadata).
In Flatpak specifically, the instance ID is important because two instances of org.gnome.Weather
don't necessarily have the same permissions and other sandboxing parameters, but two processes within the same instance ID definitely do have the same permissions and sandboxing parameters.
It's not clear to me where the best place is to draw the line between "top-level, guaranteed to exist" and "extension point, not guaranteed". The sandboxing framework that "owns" the container instance makes sense to me as top-level and guaranteed, because other fields are going to be defined in terms of it. I think it's reasonable to assume that every sandboxing framework is going to have some concept of an app name that is broadly equivalent to what Flatpak and Snap have, and even if it doesn't, the empty string is a valid value. It's less clear to me whether "instance ID" is equally universally-applicable - but since Wayland security contexts have it at top level, if we want to share a registry/namespace of metadata with those, it might be a good idea to be consistent.
Acceptance
-
Decision needed: How are keys in the metadata dict namespaced? (As far as I can see, this is just a documentation problem: it's likely to be an a{sv}
either way.) -
Provide spec wording for the namespacing, referring to some external spec if appropriate. -
Decision needed: Do we add an instance ID at top level, next to the type and name? -
If a top-level instance ID is desirable, add it to the implementation (trivial change by mimicking how we handle the type and name, should be relatively suitable for dbus beginners). Allow the empty string as a possible instance ID.
Nice to have
-
Ask Snap maintainers what they consider to be the canonical (no pun intended) domain name for Snap, and use the reverse of that in our examples, analogous to org.flatpak
. I previously usedio.snapcraft
but because Snap is centralized, it isn't immediately obvious whethersnapcraft.io
is the equivalent offlatpak.org
(the sandbox implementation itself), orflathub.org
(the conventional app-store), or both.
Out of scope
- Defining specific metadata fields for interoperable/fd.o use
- Defining specific metadata fields for Flatpak
- Defining specific metadata fields for Snap