Feedback on the unverified badge from upstream

[barthalion]

@barthalion the root issue isn't resolved I think.

To me, it is confusing that the above mentioned Flatpak site looks like the Genay Flatpak package is maintained by the Geany developers. This is because of the "by Geany Team" term below the title and in the blog "Community built" there is a link to the project website directly.

But at no point there is any reference to who really maintains this package and that bug reports related to the Flatpak packaging should be reported there and not to the Geany project itself.

I think it would help all parties, if this could be made more clear that project developers and package maintainers are not the same people.

Thank you.

Originally posted by @eht16 in flathub/org.geany.Geany#92 (comment)

[barthalion]

I think I have some follow-up comments to this:

1. I don't think we should be overwriting developer_name. Maybe the badge should be in the same line?
2. For third-party extra-data apps, we ask submitters to add the "this package is not affiliated with the developer" disclaimer. Should we start doing this automatically?
3. We should potentially rewrite the bug tracker URL to point to the Flathub repo instead.

Mentioning usual suspects stakeholders to discuss this: @razzeee @bertob @cassidyjames @sonnyp

[razzeee]

Duplicates/could be solved by #3125

But that would be something @ximion would need to add to libappstream or we need to force people to login via github once.

[TiZ-HugLife]

Hi there. As someone maintaining a package who is completely separate from the people actually making it--the referenced package, even--I would also consider myself a stakeholder here. Packager / developer disjoint is standard in traditional packaging, but given Flathub's huge push toward verification, I can see how the way it's currently presented on the site is problematic. I think that in unverified situations, it would be beneficial to either not show the author at all, or show both the upstream developer per the metadata and also show everyone who has worked on the package recently. Given a packager's role is comparatively small--especially in Flathub where it's kinda easy--I'm not sure I would want it to be prominent, but I would definitely want it to be easily available.

[barthalion]

Yeah, I don't think #3125 should be implemented. We're not a traditional Linux distro, and ownership shifts between people somewhat easily due to the easy workflow with GitHub.

[kekkoudesu]

Hi there! Since my issue was mentioned (and I'm also in the process of creating my own Unverified Flatpak), I thought I would chime in with some more thoughts. I'm glad this is being discussed.

Even at the time of creation, I didn't think #3125 was a great solution. The important information is not necessarily who is responsible for the package, but who isn't. That is, Google is not responsible for the Flatpak package.

So, you could remove the "by Google" line and add it to the Unverified badge:

It needs some more work (maybe split it into two badges?), but I like this direction more. It's simpler and only a small alteration to the way the page is presented, not requiring changes elsewhere.

Or as @TiZ-HugLife mentioned, simply don't show the author at all for Unverified apps and just provide a tooltip for the Unverified badge so users can quickly learn what "Unverified" means. I think the by $AUTHOR line should go either way in Unverified situations because it's so easy to misinterpret.

[razzeee]

I like the idea to just drop the by x line.

The problem would be with SEO in that case, as it carries important information for some apps. E.g. Microsoft for Teams would be very important, for that page to show up on search engines.

[bertob]

Maybe we keep the author line but add "Not provided by" to it?

[razzeee]

I guess that works, but it might be confusing.

As a random user, I wouldn't expect to see a negation on an apps description, that might raise more questions, then it answers?

[TiZ-HugLife]

I think "Not provided by" just creates more confusion, especially because it's there at the same time as the unverified badge. Maybe the "unverified" terminology, at least in user-facing areas, is what needs to go. And then instead, we could say:

"Application developed by (Developer Name Here)
(<!> Package provided by Flathub community)"

[cassidyjames]

I still lean towards what I mentioned in #2625 (comment):

I might phrase it more like:

Google Chrome

by Google ⚠️ Unverified

Tooltip/popover:

This app has not been verified to be provided by Google or google.com

…assuming we can use the developer name and an un-reversed RDNN there… 🤔

I think the distinction is putting the unverified badge inline/directly next to the developer name when possible, and then including the extra information on click/hover to share the specifics.

Ultimately I don't think we should say who the app is "provided by" e.g. "Flathub community" because that doesn't really mean anything… it's still developed by the developer, packaged by whoever has write access to the manifest repository, and ultimately distributed by Flathub—that's a whole lot of nuance to try to cram into one place that most people will not understand. Instead, let's focus on what we know:

1. the developer name, and

2. the fact that it's not verified

If that's not satisfactory, then I agree that removing the developer name from the header completely may be the right move; we can't verify it's actually from that developer, so it's a valid argument to not show it as such—SEO be damned (want better SEO? verify your apps!).

[razzeee]

Real problem is, that a side by side won't always work on mobile (and looks bad IMO)

[eht16]

For me, as a developer, it is important to differentiate between developer and packager. This is not the same (in most cases).

It might be that this difference does not matter much to some/most users. But why hide the information for those users who care? In my experience, usually there can't be too much information but rather too less. If users do not care about the difference, that's ok as long as they can decide themselves. Not providing this information takes them the ability to decide.

I wish the Flathub software pages would give a clear indication if the software packaged by a third party and also provide users with the information where and how to report bugs related to packaging.

To me, the "Unverified" badge can mean anything.

If you don't want to list individual packagers, why not at least add "Packaged by the Flathub team, report bugs at https://github.com/flathub/org.geany.Geany" or so. Then it would be more clear that the software is packaged by a third party and users know how to get in touch.

[razzeee]

It might be that this difference does not matter much to some/most users. But why hide the information for those users who care? In my experience, usually there can't be too much information but rather too less. If users do not care about the difference, that's ok as long as they can decide themselves. Not providing this information takes them the ability to decide.

"Hide" is kinda phrasing this wrong. The data does not exist.

I wish the Flathub software pages would give a clear indication if the software packaged by a third party and also provide users with the information where and how to report bugs related to packaging.

If it's unverified it 's third party, doesn't get much clearer - bug related links can be found in the link section. Everything related to packaging needs to go to the manifest location.

[TiZ-HugLife]

I actually dislike the "unverified" terminology itself, because it implies that Flathub doesn't know where the package came from, and it was just randomly uploaded by some schmuck. It implies that there is less of a process for package submission than there actually is. When in reality, Flathub knows full well who is submitting and maintaining a package, and if it's not the developer, they know why it's not the developer. And the majority of the time, that reasoning comes down to the developer having apathy toward Linux, anti-Flatpak sentiments, or uncertainty that the software will meaningfully function in Flatpak.

The fact that a package is maintained by the community instead of the developer is in and of itself meaningful, but I'm not sure that "unverified" does a good job of conveying that and its actual implications.

[TiZ-HugLife]

Alright, we need to revisit this. Someone filed an issue (flathub/org.geany.Geany#103) asking me to "verify the package", which is not possible given that Geany's developers do not endorse the package and are not interested in maintaining it themselves. Users are not getting an accurate sense for what verification means or entails, so I really think this "unverified" terminology just needs to completely go.

[AsciiWolf]

Do not worry, I am well aware what "unverified" means since I am quite active in the Flathub community since 2017 or so. :)

[TiZ-HugLife]

Here, me go ahead and copy your comment from the Geany issue over to here so it can be discussed with everyone all at once:

Fair points and do not worry, I am not going around every unverified project, just some (many of my Flatpaks are also still unverified). However, unverified Flatpaks will probably die in the future - for a good reason. Linux Mint already nuked them (they won't be displayed anymore in their Software Manager app) and other distributions will probably follow. As far as I know, there were also some plans to do not allow unverified apps on Flathub at all, but these plans were postponed.

Any distro that chooses to ship Flathub with only the verified subset of apps enabled by default is their own prerogative; it's an understandable decision, but it's not correct to call Mint's decision in this regard "nuking" them, because that implies that they are blocking the installation of unverified applications, and that does not seem to be the case.

What evidence do you have to suggest that other distributions will follow suit?

What evidence do you have to suggest there are eventual plans to completely remove all unverified applications from Flathub? That does not seem like a decision that would be reflective of current reality. There are still plenty of applications (or plugins to existing applications) that do technically support Linux, but the developer is Linux-apathetic, so if the only way for them to be on Flathub is for the developer to directly get involved in some way, it will simply never happen.

That said, if that's the way we're going, it lessens a burden of conscience for me. I've been thinking about stepping away from all of my FOSS involvement for some time for many varied reasons, but some of these packages are solely under my own care. And I know for some of them, I'm not even doing a good job anyways.

[razzeee]

I don't think that will ever happen, at least not from the flathub side of things. And in every (internal/external) flathub channel I'm part of, nobody ever suggested that.

[AsciiWolf]

Well, I remember someone from the Flathub staff considering this, but it was a longer time ago.

Anyway, I really think that it is just a matter of time before other distributions start disabling ("nuking" was not the correct term, sorry about that) non-verified apps from the default search results of their App Stores. Some of my Flatpaks will also be affected since it is not possible to verify them for one reason or another.