Question: How to handle developer id

[ghost]

I'm personally working on updating appdata files for GNOME and associated apps to comply with Appstream 1.0.

According to the documentation, it is recommended to provide a unique ID for the developer element. This ID should ideally be a web URL, such as gnome.org, to ensure greater uniqueness.

• Developers often request their websites, like yakusha.net, to be used as IDs. Is it acceptable?
• For projects mostly related to GNOME but hosted on GitHub, is it acceptable to use gnome.org as the ID?
• Can developers use their social media accounts, like @[email protected], as an ID?

[GeopJr]

Without trying to derail the issue (I can open a separate one if needed), if the whole point of the ID is distinguishing developers that have the same name, I'd rather see the <developer/> element be extended in a way that replaces DOAP files than using an arbitrary ID.

Most (GNOME) software have a similar DOAP file, for example here's Collision's:

<Project
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:foaf="http://xmlns.com/foaf/0.1/"
  xmlns:gnome="http://api.gnome.org/doap-extensions#"
  xmlns="http://usefulinc.com/ns/doap#"
>
  <name xml:lang="en">Collision</name>
  <shortdesc xml:lang="en">Check hashes for your files</shortdesc>
  <homepage rdf:resource="https://github.com/GeopJr/Collision" />
  <bug-database rdf:resource="https://github.com/GeopJr/Collision/issues" />
  <programming-language>Crystal</programming-language>
  <maintainer>
    <foaf:Person>
      <foaf:name>Evangelos "GeopJr" Paterakis</foaf:name>
      <foaf:mbox rdf:resource="mailto:[email protected]" />
      <foaf:account>
        <foaf:OnlineAccount>
            <foaf:accountServiceHomepage rdf:resource="https://github.com/"/>
            <foaf:accountName>GeopJr</foaf:accountName>
        </foaf:OnlineAccount>
      </foaf:account>
    </foaf:Person>
  </maintainer>
</Project>

Most of the info is already in the appstream file (name, description, homepage, issue tracker etc) but under "Person" you can list e-mails and other online accounts to distinguish people.

The main difference I see is that DOAP allows you to list multiple people with different roles (maintainers, translators, developers, testers, documentors, helpers, testers)

(Here's nautilus' doap file)

If there's any interest in this, it might be worth contacting people that use DOAP and Appstream to gather metadata for their opinion on it. Like "Apps for GNOME" https://gitlab.gnome.org/Teams/Websites/apps.gnome.org/-/blob/main/METADATA.md#doap (uses DOAP to gather platform info and maintainer accounts for https://apps.gnome.org and https://welcome.gnome.org) and maybe libadwaita (which can populate About windows using the appstream file https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/ctor.AboutWindow.new_from_appdata.html, having everyone involved in the appstream would probably allow it to also populate the "designers" and "translators" fields too 🤷)

[sonnyp]

@sophie-h migh have interest in this

[sophie-h]

Sadly, this already falls apart in the spec:

a web URL, like gnome.org

A web URL would be https://gnome.org, and gnome.org is a domain. So the recommendation here should be clarified.

IMO it makes sense to use a URL such that people can use URLs like https://github.com/<username> if they don't own a domain. Ideally, the example would not mention gnome.org to not incentivize people to use it without being a GNOME Core app.

For projects mostly related to GNOME but hosted on GitHub, is it acceptable to use gnome.org as the ID?

That's a GNOME internal question. I think as of our Software Policy it's pretty clear, that you can't use gnome.org.

[ghost]

Another issue related to developer IDs is that there are some apps with multiple developers, and there is no way to handle multiple IDs.

  <developer_name translatable="no">Manuel Genovés, Wolf V.</developer_name>
  <developer id="gnome.org">
    <name translatable="no">Manuel Genovés</name>
    <name translatable="no">Wolf Vollprecht</name>
  </developer>
  <description>

[razzeee]

IMO it makes sense to use a URL such that people can use URLs like https://github.com/ if they don't own a domain.

Only way that would make sense/be okay would be, if we then convert this to a hash. Otherwise it won't work for app stores, that are in the browser and would like to have sane looking urls.

[sophie-h]

Only way that would make sense/be okay would be, if we then convert this to a hash. Otherwise it won't work for app stores, that are in the browser and would like to have sane looking urls.

Good point. I guess the recommendation to use a URL should be dropped then and replaced with something like "domain"

[sophie-h]

Another issue related to developer IDs is that there are some apps with multiple developers, and there is no way to handle multiple IDs.

Yeah, this also goes back to @GeopJr's comment. The fact that the example only features "gnome.org" as an ID already shows the limitation and missing guidance for this new spec.

[razzeee]

reverse domain scheme might make sense, similar to apps. still, nothing that would improve our SEO ratings, speaking from the POV of a website

[ximion]

A rDNS name for this is already recommended in the local Git copy, see https://github.com/ximion/appstream/blob/main/docs/xml/metainfo-component.xml#L1170
(to become live on fd.o at release time)

I could make that mandatory and validate that scheme, if we want to settle on it... Having a Mastodon/Fediverse handle as ID would also make a lot of sense to me though (so @[email protected]).

[razzeee]

FYI, current feeling is, that we won't be using it on flathub, as we might just use verification for this.

[sophie-h]

FYI, current feeling is, that we won't be using it on flathub, as we might just use verification for this.

What do you mean by that? The person who verified the project becomes the author?

[razzeee]

Not sure if it's well thought out, but basically, if we want to group apps by organizations/authors, we would go by who verified them.

[ximion]

Well, client apps use the developer-ID and project_group for grouping though, so that seems a bit redundant.
Of course, you could override the developer-ID on the server-side with the ID of whoever verified an app... That would work.

Of course, the developer element may allow to add the verification info in a generic way in future (so Flathub wouldn't have to use a custom entry for this), but let's see if that's needed.

[razzeee]

We got rid of the project_group, as it was problematic, that everyone could just claim that they are a gnome/kde app

[ximion]

Well, anyone can claim anything with the metadata, it's the job of the software distribution channel to check it. The critical elements that need verification or review are the component-ID, project_group, developer name and ID, the replaces relation and compulsory_for_desktop.
Those are super important (as they can mess with the user quite heavily or make the app claim to be from someone else) and should only allowed to be altered after a manual review. Potentially the component-name would also be in that list, but at least a name change doesn't change ownership declaration.

As for project_id specifically, the validator will warn if someone without an org.kde component-ID claims to be in the KDE group, these checks can be tightened on demand. But of course the deployment channel needs to have the last word and gatekeep this stuff to not cause chaos.

[bbhtt]

We got rid of the project_group, as it was problematic, that everyone could just claim that they are a gnome/kde app

But of course the deployment channel needs to have the last word and gatekeep this stuff to not cause chaos.

Appstreamcli does error on this in the linter. The severity of org.gnome was also increased as an override https://github.com/flathub-infra/flatpak-builder-lint/blob/def52b310b8658be99da554dc30956783a4f60d7/flatpak_builder_lint/appstream.py#L21

This is documented in https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#project-group

[ximion]

The severity of org.gnome was also increased as an override

I lowered it in the past on request of GNOME. If that decision has changed, I will gladly make it a warning or higher again upstream as well :-) (this will then propagate to the whole ecosystem though).

This is documented in https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/#project-group

This matches the tag's intent and upstream description. Looks fine to me :-)

[sophie-h]

Not sure if it's well thought out, but basically, if we want to group apps by organizations/authors, we would go by who verified them.

This will not work. People might originally use a personal domain for the app id, but later the app is maintained by a group or someone different. But it will forever be grouped with other apps by this one person. And that's just one example.

[sophie-h]

Appstreamcli does error on this in the linter. The severity of org.gnome was also increased as an override https://github.com/flathub-infra/flatpak-builder-lint/blob/def52b310b8658be99da554dc30956783a4f60d7/flatpak_builder_lint/appstream.py#L21

There is one official GNOME app for which this will break https://flathub.org/apps/ca.desrt.dconf-editor It's a bit outdated anyway :/

I lowered it in the past on request of GNOME. If that decision has changed, I will gladly make it a warning or higher again upstream as well :-) (this will then propagate to the whole ecosystem though).

Can you point me to this request by GNOME? I would like to know who asked for that and why.

[ximion]

Can you point me to this request by GNOME? I would like to know who asked for that and why.

I just checked, this is an ancient change introduced 8 years ago in d7e1435 - the discussion about it must have happened somewhere else in a bug or on IRC, I don't recall who asked me... I do know though that the change annoyed people and I was asked to not enforce it just yet.

Given that this was almost a decade ago, I guess we could change this now though, I doubt the original reasons for demoting it are still in place.

[razzeee]

Not sure if it's well thought out, but basically, if we want to group apps by organizations/authors, we would go by who verified them.

This will not work. People might originally use a personal domain for the app id, but later the app is maintained by a group or someone different. But it will forever be grouped with other apps by this one person. And that's just one example.

You can just rebase the app to a new ID, but I guess it's offtopic

[JakobDev]

I think Flathub should just use the new developer Name or ID instead of the App ID to group Apps together. The original Argument against this was that People could just claim they were someone else, but as AppStream changes are now moderated, that's no longer true.

[ximion]

I think the original question by @sabriunal has been addressed: The specification contain guidance now on what is and isn't allowed, and the ID is validated by the validator as well. Changes will be live with the next release (originally today, but I'll delay it for a couple of days).

For other issues, please file separate bugs! :-)