Support for AppImages hosted on Github.com

[misog]

Hi, afaik currently zap downloads AppImages from appimage.github.io

However github.com allows to host AppImages, even with check sums. For example, VSCodium (which is not included in appimage.github.io) releases AppImage and AppImage.zsync files:

...
codium_1.67.2-1652920424_armhf.deb.sha256
VSCodium-1.67.2-1652920338.glibc2.17-x86_64.AppImage
VSCodium-1.67.2-1652920338.glibc2.17-x86_64.AppImage.sha1
VSCodium-1.67.2-1652920338.glibc2.17-x86_64.AppImage.sha256
VSCodium-1.67.2-1652920338.glibc2.17-x86_64.AppImage.zsync
VSCodium-1.67.2-1652920338.glibc2.17-x86_64.AppImage.zsync.sha1
VSCodium-1.67.2-1652920338.glibc2.17-x86_64.AppImage.zsync.sha256
VSCodium-darwin-arm64-1.67.2.zip
VSCodium-darwin-arm64-1.67.2.zip.sha1
VSCodium-darwin-arm64-1.67.2.zip.sha256
VSCodium-darwin-x64-1.67.2.zip
...

How could it work? zap install and zap search could search for the package on github.com and offer AppImage files of different github users sorted by number of stars. This does not need package repository and this does not need caching because github allows to make 10 request per minute for unauthenticated users. If Github.com changes API rates, zap could route requests to a server which could forward them to github.com and cache them. Or it could allow users to enter their Github credentials.

One advantage is that software publishers do not need to publish AppImages on their websites or submit them to package repositories such as appimage.github.io. One Github.com integration could make available many AppImages in zap.

Another advantage is that the community does not need to specially verify or process AppImages files because it already has reputation based on number of Github.com stars of the project and this helps users to decide what software they want to install.

Github.com offers build services, so in the future it could be very feasible to build AppImages automatically for many open-source projects and Github could be known as THE most popular release platform with API access. This could make AppImage ecosystem really big and AppImage files very accessible and widespread. Github.com also allows free private repositories, so even non-open-source software publishers could possibly release and host binaries wrapped as AppImages.

Summary The traditional model has three parties: a. Software maker (ex. company owning Firefox*) b. Software publisher (ex. Debian or appimage.github.io) c. Software user (you or me)

With zap and Github.com integration the model has just two parties: a. Software maker (ex. company owning Firefox*) b. Software user (you or me)

*yes, Firefox does not use Github.com... yet!

Edit: This would also solve issues like this: https://github.com/srevinsaju/zap/issues/62

In the future, zap could make integration not only with Github.com but also Bitbucket and other popular build/release/host platforms with API access. As stated above, zap team can create server as a cache layer if the platforms decide to make their API too limited.

The user story behing AppImage is:

"As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application." https://appimage.org/

From user perspective, successful software discovery nowadays relies on SSL and manual domain verification (with the help of SEO ranking). Command line utility zap acts just like AppImage search engine, replacing the need to open web browser by users. Ultimatelly, it is not about the quality of software repositories - it is all about how well search engines / zap will discover and sort/rank search results.

[trymeouteh]

Would like to also suggest supporting self hosted repositories and if github.com will be supported, please also support gitlab instances and gitea instance also.