[Feature Request] Own repository of AppImage

[Drsheppard01]

AppImageHub stored 1303 AppImage, appimage.github.io has 1404 apps, portable-linux-apps.github.io has 1801 apps. I think it makes sense to make your repository via a json file with applications like as https://github.com/simoniz0r/spm (my fork with first commits https://github.com/Drsheppard01/spm)

• choose a repository format
• develop a method to update the repository (preferably through constant access, but then you can't use github)
• develop method for automatical grabbing software from site or github

[UriHerrera]

I'm sorry for not getting back to you sooner.

If I understand correctly, are you proposing we create a repository for AppImages?

I'll move this to a discussion.

[Drsheppard01]

Yep. I mean not repository like virtual storage with appimages, i mean JSON-file with links and other metadata for parsing in NX Software Center

[UriHerrera]

Creating a store from scratch is impossible for us; we're already a small team. It'd be faster and simpler to upload the AppImages to AppImageHub.com instead, which the software center already supports.

If that were the case, we could support the effort of a community member. We could add a filter in the software center to display only the files from that community member; let's imagine it's an account called "NX Community AppImages," and another filter to display all the files from AppImageHub.com.

[Drsheppard01]

Запись экрана от 2023-11-13 10-25-59.webm
Proof-of-concept
All files there: https://www.figma.com/file/2jBTp56e4iqW3QkS96XX0g/GUI-for-aip-man?type=design&node-id=0-1&mode=design&t=r6wvyTmlAaEHMier-0

P.s. sorry for shitty quality

[UriHerrera]

It reminds me of 0install. With 0install, one uses an XML file in their client (GUI or CLI) to install an application. We include it in the distribution.

[Thatoo]

Hello,

Have you heard of "AM" Application Manager, a database & solutions for all AppImages and portable apps for GNU/Linux ?
AppImage manager/installer/updater and AUR-inspired database, now including 1900+ AppImage packages and official standalone apps for GNU/Linux. "AM" Application Manager also provides scripts to manage AppImage creation tools and templates to create your AppImages. Easy to use like APT and powerful like PacMan.

I guess it would answer your need for an appimage store, wouldn't it?

https://github.com/ivan-hc/AM

The only thing missing is a GUI but I guess this is your thing, making nice and beautiful UI/UX design.
You could bring your knowledge to this project and theb add it to nitrux.
ivan-hc/AM#8

[UriHerrera]

Its author had already created a discussion about the use of this software.

https://github.com/orgs/Nitrux/discussions/125

[Drsheppard01]

Getting back to our topic, I suggest removing the api for accessing appimagehub and using a custom json api instead

Advantages:

• Own list of apps (no storage required, download links are sufficient)
• Control over this list (removing outdated apps, replacing non-updated apps with forks)
• Ability to add your own things like community and official separation

[UriHerrera]

Thanks for making a suggestion. Back in January, we announced an initiative called NX AppImage Build Hub. The initiative covers all your points.

So as mentioned in the announcement regarding the AppImageHub.com integration:

[...] as stated earlier, we don’t have the resources, i.e., available humans, to create, host, operate, and maintain a store on our own. Besides that, since we redesigned the application, the NX Software Center has long used AppImageHub.com as the one source to obtain AppImages. Hence, the API (OCS-API) integration already exists; otherwise, we’d need to invest time creating a new API for the application to interact with the purported new website.

[...] the issue remains the same: displaying those other AppImages in the NX Software Center requires further development that we’d rather spend elsewhere.

Additionally, AppImageHub.com, through its API, provides metadata we can use, like descriptions, ratings, uploaders, tags, screenshots, etc.