Make it clear who packages flathub artifacts

[kkartaltepe]

Flathub.org is incredibly misleading about its packaging typically hiding the actual packagers under a link with no names attached at all. This continually causes users to think upstream is maintaining these broken third party packages.

The frontend should clearly identify (by name or other identifier) the packagers and make it clear where users can file bugs against the packaging.

https://tracker.debian.org/pkg/obs-studio (maintainers clearly identified)
https://packages.ubuntu.com/bionic/obs-studio (maintainer clearly identified)
https://snapcraft.io/obs-studio (About as bad as flathub, but at least packagers have the courtesy to mark their unofficial packaging and inform users where to file bugs recognizing the flaws of the platform they are distributing on.)
https://www.archlinux.org/packages/community/x86_64/obs-studio/ (maintainer clearly identified)

In case you somehow believe users are able to divine what your cryptic links and arbitrary naming of "publisher" mean, here is the most recent example of users being completely confused by this:
obsproject/obs-studio#2683

[bilelmoussaoui]

I think the right way to handle this is an actual way to display if the package is maintained by the upstream developers. If not the case, just redirect the issues url to the github repository on github.org/flathub instead of the upstream one.

A packager name doesn't make sense, because Flathub tries to avoid having a packager and just give all the keys to the developer to deploy their application and update it to all the users.

[kkartaltepe]

A packager name doesn't make sense, because Flathub tries to avoid having a packager and just give all the keys to the developer to deploy their application and update it to all the users.

I would say this makes less sense. You cannot say that you expect upstream to be the primary packagers when you yourselves are releasing third party packages (modified from upstream distributions at that). https://github.com/flathub/com.obsproject.Studio. How am I supposed to believe you?

--- edit
That may sound needlessly accusative. I dont intend to say no one should package software. But to point out how natural it is for software to get packaged in the linux community (and I am thankful to the people who package software for various systems). But the need here is to make it clear WHO is supporting this packaging not just for upstream to avoid needless bugs but for packagers to get reports so they can continue to provide high quality packaging. To expect there to be no third party packagers is just naive (nor can I find a single package on flathub.org that is maintained upstream).

[bilelmoussaoui]

A packager name doesn't make sense, because Flathub tries to avoid having a packager and just give all the keys to the developer to deploy their application and update it to all the users.

I would say this makes less sense. You cannot say that you expect upstream to be the primary packagers when you yourselves are releasing third party packages (modified from upstream distributions at that). https://github.com/flathub/com.obsproject.Studio. How am I supposed to believe you?

--- edit
That may sound needlessly accusative. I dont intend to say no one should package software. But to point out how natural it is for software to get packaged in the linux community (and I am thankful to the people who package software for various systems). But the need here is to make it clear WHO is supporting this packaging not just for upstream to avoid needless bugs but for packagers to get reports so they can continue to provide high quality packaging.

https://github.com/flathub/flathub/wiki/App-Submission#someone-else-has-put-my-app-on-flathubwhat-do-i-do

[barthalion]

Just as with any form of binary distribution, you are either trusting whoever distributes it or not. Slapping name of person who is the supposed maintainer on it does not really change anything. You are accusing us of modifying upstream source (or so I understand), while Debian applies 8 not upstreamed patches, Ubuntu uses cryptic "Ubuntu MOTU Developer" and Arch mentions at least 3 other names in the change log. Snap links to their bug tracker – which isn't really far from what we're doing.

Yes, we do ship a portal which allows users to use your project in the first place on distributions with Wayland enabled by default, but there's nothing in the license prohibiting from doing so.

The application has been added Flathub before prerequisites for submissions were well fleshed out. These days we require submitters to reach out to upstream them whether they would be interested in maintaining their application on Flathub and proceed with addition only when 1) they are, 2) there was no response 3) they are not interested in packaging whatsoever.

Not saying there's no room for improvement here. Your issue is already partially covered by #213. With clear designation which applications are upstream-maintained (also for these built on Flathub infra), we'll be able to display more useful in Publisher field. It's a process though, nothing happens overnight.

P.S. Also yes, we're always happy to handover repository ownership for applications submitted by third party packagers.

[kkartaltepe]

you are either trusting whoever distributes it or not.

This is precisely the issue. Flathub.org is not clear on who is distributing packages. As evidenced by users coming to us asking us to fix it. That is why I have opened this issue.

You are accusing us of modifying upstream source (or so I understand)

Im only pointing out if your claim is A packager name doesn't make sense, because Flathub tries to avoid having a packager and just give all the keys to the developer to deploy their application and update it to all the users.. But obviously there is a packager AND it evidenced by the fact that they are making changes required for their platform (as you mention adding xdg portal functionality). So this needs to be transparent to the user, they are trusting the upstream name but getting code that isnt from upstream. (And its obvious flathub does not attempt to avoid having a packager since it is the packager for everything on flathub.org, at least that I could randomly sample)

How is this different from other packager managers I point out? Debian again has their own packages with their own bug trackers and make it clear to users this is the case via apt. They also appropriately modify versions reported by the application to denote its packaged by Debian and not an upstream package (https://salsa.debian.org/multimedia-team/obs-studio/-/blob/master/debian/rules#L18).

Ubuntu mostly just pulling debian packages does the same. And provides the same transparency and facilities for their packages.

Arch provides a way to contact the current maintainer, or provide comments and bug reports on the package. It would be preferable if they also marked their package versions.

Im happy that people want to package obs on flathub, but I just want flathub.org to support transparency for users to know what they are getting, from whom, and how to contact the people who support it. Thats all.

(The concept of "give all the keys to the developer" doesn't really fit with the open source model of software you are packaging on flathub IMHO. Maintainers come and go as seen on the arch linux packaging you note. This is another reason why transparency on packagers is needed on a package manager like flathub.org)

[TingPing]

Just to be clear we have our own bug tracker and it is linked the website. We can just work to make it more obvious. I believe everybody involved with Flathub wants that to happen. Nobody is trying to hide some details.

[kkartaltepe]

I hope it doesnt sound like I am accusing flathub of trying to actively trying to hide this or anything so nefarious. I just think as it stands with the current UI design the end result is user confusion (more so than the typical linux packaging misunderstandings).

[1player]

Personally, more than making clear who's packaging the app, I would just like to know whether the original author is packaging it or not. Simply, an "official" checkmark. Or alternatively an "unofficial" label.

Snap does it, and as a user my order of preference currently is: Official Flatpak -> Distro-specific package -> Unofficial Flatpak.

This is not borne out of mistrust of the volunteers who package the apps, it's just easier to know who to blame if anything is wrong with the app, and in case of Flathub.org, gives it a little bit of additional legitimacy.

[SISheogorath]

Yesterday I played around a bit with how to implement around how to make this status more clear. Main issue currently remains where do we get this status from without requiring a manual approval process or alike, since everyone has more than enough to do.

One could argue, that we should just trust the maintainer to be honest in that perspective, since we trust maintainers anyway. I'll leave this up to discussions, I'll also provide some screenshots later.

[elsiehupp]

One way to differentiate between developer-published packages and “community-published” packages could be to have the storefront check for a specific <meta> tag in the <url type="homepage"/> URL. For comparison, Safari on iOS has long had the ability to check for the following <meta> tag:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, app-argument=myURL">

Flathub could provide a similar template, along the lines of:

<meta name="flathub-flatpak-app" content="app-id=FlathubID">

This <meta> tag would allow several things:

1. If page at the <url type="homepage"/> URL of a Flathub app had a <meta> tag with the corresponding Flathun App ID, the Flathub storefront could feature a “blue checkmark” or something similar in one or more places on the page.
2. Flathub (or, honestly, any third party) could build one or more browser extensions checking for the <meta name="flathub-flatpak-app" content="…"> tag on each page and showing a small banner (as on iOS) telling the user that the page has a corresponding app available on Flathub or suggesting that the user open the app if they already have it installed. (There are a number of further security considerations here that are beyond the scope of this thread.)
3. Eventually, the tag and extension could support an app-argument (as on iOS) for the purpose of allowing websites to deep-link into corresponding apps. (Again, with additional security considerations.)
4. Since one of the concerns on this thread is properly directing bug reports and support requests, the Flathub storefront could set the <url type="bugtracker"/> to github.com/flathub/<app_id>/issues unless the <url type="homepage"/> has been verified.

Obviously, anybody could unilaterally add this <meta> tag to their website; the more important question would be whether Flathub would run a bot making any use of it. Essentially, the <meta> tag could facilitate a “handshake” that would enable a given app page on Flathub to display “flair” emphasizing its verified/official status. App pages without verified <url type="homepage"/> URLs would continue to appear exactly as is aside from the <url type="bugtracker"/> defaulting the corresponding Flathub GiHub Issues page.

Does this seem like a reasonable approach to the specific issues people are presenting in this thread?

[elsiehupp]

Note: there’s an existing npm package specifically for grabbing URL metadata, so the Flathub web storefront wouldn’t have to rebuild the wheel from scratch.

[SISheogorath]

We have been talking about such "verified" badges in another issue #48 and so far, we didn't reach any consensus on how the verification should work. Main concern is: Maintainers also control the metadata and therefore could point it wherever they want. Which is why I pointed out that it's probably enough to just trust maintainers to be honest.

However we might manage to make app-ids claimable through a verification process. That could be an idea, but in unrelated to this issue.

[1player]

Verification badges are now tracked in flathub-infra/website#44