Differentiate between official and community AppImages

[mgord9518]

There should be a tag in the database (feed.json) that explicitly tags an AppImage as official -- straight from the developer and manually verified either through obvious means (hosted on the official website) or a public announcement from the developer. This would make it a lot easier to decide on whether to trust a certain software or not.

I understand that this database prefers official AppImages, but it contains many (primarily historical) community made AppImages and there's no good way to set them apart

[probonopd]

Agree! 👍

Volunteers?

[mgord9518]

@probonopd I'd be willing but I currently have no clue how to implement it here. Would you have a starting point that I could look at?

[probonopd]

Well, first of all we would need to work out some logic how to detect whether an AppImage that is being tested has been made by the application's original authors or not. Is this even possible in an automated way?

[probonopd]

Another option would be to split up data/ into official/ and inofficial/ by hand, and based on where the file is located, have worker.sh set a key in the .md files that gets written in apps/, like so:

layout: app

type: inofficial

permalink: /86Box/

icons:
  - 86Box/icons/512x512/86box.png

(...)

Once the key is in that file, it'd be trivially easy to make use of that information when rendering the output for the website and the feed.

[mgord9518]

@probonopd I don't think it would be possible to automate in a reliable fashion.

The splitting of /data is a good idea

By default, all current AppImages (besides the very well-known and obvious ones) would be assumed to be unofficial until manually verified, all new additions would just be verified on submission.

[probonopd]

Makes sense to me.

[mgord9518]

@probonopd I've been working on it in a test repo and can't seem to get the database to update. Either Actions says it failed on #set -e or that worker.sh can't find the release page for the AppImage even though it obviously exists. I made pretty minimal modifications to the repo (search for changed files in data/* instead of data and updated worker.sh to add a key if the AppImage is under data/official) any ideas as to why this may be happening?

[mgord9518]

Nvm, it apparently works with Yuzu, which has a direct link to the AppImage, but not with AppImageUpdate, which links to the GH page. I'll see if I can fix it and clean it up a little, then push it here. There'll be a couple extra commits from testing but nothing too much to read through

EDIT: After some tinkering in my terminal, I believe it's an access token thing. In this line it uses an access token variable, but doesn't appear to be necessary in order to use the API (I know there's a limit, but it's pretty high -- around 1000/hr). The code works perfectly when the access token variable is empty or if the question mark and beyond in the URL is removed. Is it really necessary?

[probonopd]

You might run into rate limits earlier without a token:

mgord9518@0e9aa20

[mgord9518]

@probonopd what about having it try with the key and if it fails then gets the info without using it?

Otherwise I don't think there'll be any way I could test it before submitting

[probonopd]

Could be done that way, yes.

[mgord9518]

@probonopd Sent in a PR, it looks like a lot of commits but most of them are just deleting/making/renaming files so it should be pretty fast to read through

[Drsheppard01]

I'll help with that. @mgord9518 Is the work in the repository up to date?

[mgord9518]

@Drsheppard01 Not currently, I'd be happy to update it though