misog

@srevinsaju Github.com could be used as the **index** because it offers **structured releases**. AppImage trust/reputation could then be implied from Github stars. It could be similar model how people install...

In other words, AppImage.github.io is very expensive list of "verified" flags. Unverified projects are not available, they are not discoverable in Zap. For example, VSCodium is not available in AppImage.github.io...

The `--from` flag and its short alternative is very nice, however it does not solve discoverability. Discoverability is very important and it is the main aspect that package managers solve...

@trymeouteh Sorry for spoiling the thread but if Zap supported Github.com integration then this would make all AppImages hosted on Github.com available in Zap and maybe it would be sufficient...

@trymeouteh Are there other AppImage repositories in addition to appImage.github.io ? It should be defined what repository means here. In general (as understood in Linux distros), repository includes maintainers that:...

I do not think so. Even if it did then there would need to be official or verified hashsum placed somewhere and Zap would need to discover it and understand...

That issue is real but it is general issue present also in repositories managed by maintainers and index like Github.com or appimage.github.io. Someone needs to be responsible for keeping the...

It may look like AppImage is suited for regular OS users, however that is not true. Regular users just use Ubuntu with Snap/Snapcraft/Snap Store or Flatpack/Flathub and they do not...

Quote: > https://download.kde.org/stable/krita/4.3.0/krita-4.3.0-x86_64.appimage > This is clearly not an ideal URL since it is specific to one version. > Instead it should be specific to one channel, e.g., "release", "continuous",...

> Hmm, good point on kde.org as a standard publishing format. To clear possible misunderstanding, I meant that kde.org could be also integrated with AppImage discovery tools such as Zap...