Refresh clients data automatically

[thibaultamartin]

As of now, clients data in https://matrix.org/ecosystem/clients/ is not refreshed automatically. We can implement a GH Action to fetch the client information "somewhere" and update the data.

My naive approach would be to have a GH Action running every 24h that:

• Fetches all the *.md in /content/ecosystem/clients, and for each file
  • Parses the frontmatter
  • Reads a definition_file url (https? git? TBD)
  • Fetches the definition file in the url that contains the updated data
  • Updates the data in the frontmatter of the .md file
• Opens a new PR to update the clients data
• Closes old unreviewed PRs it had previously opened

What's left to define:

• Is it acceptable to ask for the definition_file to be accessible via https?
• What information can be updated by the app maintainer, and what information can only be updated by an editor/curator?
• What format should the definition_file follow?

[thibaultamartin]

What information can be updated by the app maintainer?

Information used by matrix.org

• thumbnail: path to the thumnail
• maintainer: name of the maintainer
• maturity: self-assessed maturity of the project
• repo: url to the source code
• matrix_room: alias/address of the matrix room where the project can be discussed
• licence: SPDX Identifier of the licence
• last_release: last release date, in the format YYYY-MM-DD
• featured: so far, my (Thib) opinion on whether this client should be one of the first people try when onboarding Matrix
• features: and array of features the client declares it supports or not
• packages: links to the windows installer, macos installer, and/or webapp; play store id; app store app id and org, f-droid app id, flathub app-id

Information that can be left to the maintainers

My intuition is that is should be pretty much all of them apart from thumbnail which is an implementation detail one, and featured which represents a form of curation.

I have moderate confidence in maintainers updating the last_release date. I would like to fetch that date myself, but it can't be assumed projects are going hosted and released on GitHub or GitLab.

[thibaultamartin]

What format should the definition_file follow?

• What are existing formats that work well for that matter
• Can we reuse existing formats seamlessly? For each, are they simple to put together, are there tools to generate them, are they easy to update, are they used elsewhere relevant for the projects
• What information we need can they contain by default? What information doesn't fit in? Can they be extended?

Matrix apps maintainers, I need you help: can you list file formats you are aware of (and even better if you currently use them) that could work to store data listed above?

[cvwright]

How much of this info is contained in the Fastlane metadata that F-Droid uses? https://f-droid.org/en/docs/All_About_Descriptions_Graphics_and_Screenshots/

[freelock]

There is the "Dublin Core" schema for defining standard elements that might be relevant here - http://purl.org/dc/elements/1.1/ . Drupal publishes an update feed for all of it's modules -- the feed for the Matrix API Drupal module we maintain is here: https://updates.drupal.org/release-history/matrix_api/current . At some point (when I find some time) I'll be spinning up a Chatrix module, to port over the work being done for a WordPress plugin that works in Drupal...

[freaktechnik]

For Thunderbird we have https://product-details.mozilla.org/1.0/ - which is fed by https://github.com/mozilla-releng/product-details/tree/production. You could assemble the last_release date from that (using mostly the thunderbird*.json files, see also https://github.com/thundernest/thunderbird-website/blob/master/product_details.py). All the "more static" stuff we use in the distributed Thunderbird is in https://hg.mozilla.org/comm-central/file/tip/mail/branding/thunderbird - though this repo is of course not necessarily what's in the release, and getting it for the release is sadly more complicated. However it includes things like an AppStream xml file (for the flatpak, https://docs.flatpak.org/en/latest/freedesktop-quick-reference.html#appdata-files) containing info for other fields like licence. I guess that file could also be read out from the distributed flatpak, or possibly the flatpak repo (do those implement appstream, too?).

[HarHarLinks]

Some of this info can be extracted from language-specific metadata files such as https://github.com/nordeck/matrix-neoboard/blob/main/package.json#L2-L6

[shadow-identity]

Unless you have actual data, misleading information should be removed from the site completely. It is so wrong to deceive your users!

Basically seeing that the front line client was updated in 2022 (today is 2024!) discourages me to use the product.

[thibaultamartin]

Absolutely fair point @shadow-identity thanks for bringing it here. I opened #2255 to remove that information from the pages until the situation improved