I agree with the concept, I think that would help moving forward.

I might bikeshed the syntax but I'm not sure of anything better offhand.

Added a small section about the syntax at the end of the description.

--socket=fallback-x11 is prior art for this, sort of (it's effectively not-x11-if,wayland in the syntax proposed here).

In particular, anyone looking at implementing this should look at the implementation of fallback-x11, and how Flatpak special-cases it so that moving from --socket=x11 --socket=wayland to --socket=x11 --socket=fallback-x11 --socket=wayland is not considered to be a permissions increase that requires prompting. --device=not-all-if,... should behave similarly.

Would it perhaps be better to design a syntax for which any app with a Flatpak >= 1.16.0 dependency will be able to stop specifying --device=all, so that eventually (maybe in 5 or 10 years) that can go away?

For example I could imagine that in future, we might want something like:

--device=fallback:gamepad,input,all --device=fallback:usb,all --socket=fallback:wayland,x11

with the semantics being:

• ignore any --device=all or --device=input or --socket=x11 that were specified at the same level of precedence
• do not ignore those if specified at a higher level of precedence (so users can still flatpak override --device=all if they want to)
• if --device=gamepad (a hypothetical future option) is implemented in this Flatpak, then behave as if --device=gamepad had been used
• else if --device=input is implemented in this Flatpak, then behave as if --device=input had been used
• else if --device=all is implemented, then behave as if --device=all had been used
• if --device=usb (another hypothetical future option) is implemented in this Flatpak, then behave as if --device=usb had been used
• else if --device=all is implemented, then behave as if --device=all had been used (which makes --device=input redundant, but that isn't a problem)
• similar logic for Wayland and X11

That way, as soon as an app is comfortable with adding a dependency on a Flatpak that is new enough to understand the fallback: syntax, it can stop adding the confusing --device=all.

--socket=fallback-x11 is implemented by adding x11 into the permissions, and then flatpak check the fallback first. It's not a very complex case.
Technically, --socket=fallback-x11 and ``--socket=x11` is valid, and lead to the exact same result: x11 is only available as a fallback.

That way, as soon as an app is comfortable with adding a dependency on a Flatpak that is new enough to understand the fallback: syntax, it can stop adding the confusing --device=all.

The goal here is to not have to wait for "being comfortable to depend on a flatpak new enough". The policy of certain distros lead to a too long wait time to get newer version. The goal is that it works, albeit with broader permissions, with today flatpak, without user intervention.

I like this idea of this fallback syntax, but I don't think the complexity is worth to have more than one fallback per device. It feels more verbose, but clearer of intent than my proposal.

However the following:

--device=fallback:gamepad,input,all --device=fallback:usb,all

wouldn't work on an old flatpak: it wouldn't know about any of the device and there would be none exposed. Now we could make it so that:

--device=fallback:gamepad,input,all --device=fallback:usb,all --device=all

would do the same as above, but, because all is in any fallback, all gets ignored alone, living the permission thight.

An older flatpak that doesn't understand the fallback syntax would just use all. One that to understand the fallback syntax but doesn't know the device would use the fallback as needed.

Further we could make it less verbose:

--device=input,all --device=usb,all --device=all

The difference with above is the lack of fallback: in the syntax, it works the same way.

The goal here is to not have to wait for "being comfortable to depend on a flatpak new enough"

I understand that, but I also don't want to still be carrying around 2024 workarounds in 2044 because there was no exit strategy for removing them. There has to be some point in the distant future at which app authors can rely on a new enough Flatpak.

Now we could make it so that:

--device=fallback:gamepad,input,all --device=fallback:usb,all --device=all

would do the same as above, but, because all is in any fallback, all gets ignored alone, living the permission thight.

An older flatpak that doesn't understand the fallback syntax would just use all. One that to understand the fallback syntax but doesn't know the device would use the fallback as needed.

Yes, that's what I thought - and then, eventually, perhaps in 2029 or 2034, app maintainers can drop the confusing --device=all and just have the "new" fallback: syntax (which by then will be 5 or 10 years old).

Further we could make it less verbose:

--device=input,all --device=usb,all --device=all

I think the meaning of this is not clear enough to a reader: it looks like a strange way to spell --device=input --device=usb --device=all.