Define creation metadata of the AppImage instance

[kossebau]

As there can be not only one, but multiple people creating AppImage bundles for a given application software of the same application version (e.g. with certain features added/removed, using different AppImage creation systems or a different base system), it would be helpful to have some more specified metadata entries about the entity which created the given AppImage instance.

Fields which might be handy here (looking also losely at Dublin Core metadata terms):

• publisher - the person/organization which releases/offers the original AppImage instance
• creator - the person/organization who maintains the creation of the AppImage instance
• creation-date/created - the date/time on which the AppImage instance was created/build
• UUID - some id which could be used to reference a certain AppImage instance, independent of any hash-based strategy, perhaps with some semantic pattern (e.g. including string of publisher, application name, version etc.)
• generator - the software system which generated the AppImage instance, if it can be named
  All such fields might be optional.

As consumer of AppImage instances such information would be handy if I am to manage multiple AppImage instance variants of some software, e.g. when testing which one works best for me.

[probonopd]

Should this describe the AppImage itself (the self-mounting compressed filesystem - e.g., ISO9660 files have metadata embedded about what software was used to create the ISO file), or should this describes whatever happens to be inside the AppImage?

From your description above, I can see aspects of both. E.g., what features are enabled in the payload application is a function of the payload, not the AppImage itself. Whereas the creation date is a property of the AppImage itself.

Who created the AppImage should ideally always be the same entity as the application developer (as we would like to promote "upstream packaging"), and can be verified by checking the signature that is optionally embedded inside the AppImage.

[kossebau]

Should this describe the AppImage itself (the self-mounting compressed filesystem - e.g., ISO9660 files have metadata embedded about what software was used to create the ISO file), or should this describes whatever happens to be inside the AppImage?

From your description above, I can see aspects of both. E.g., what features are enabled in the payload application is a function of the payload, not the AppImage itself. Whereas the creation date is a property of the AppImage itself.

To separate concerns, I am happy to restrict this very issue to the metadata about the container instance itself. Though I am also a bit unsure where to make the cut when it comes to the description on the container what is inside the container ;)

Who created the AppImage should ideally always be the same entity as the application developer (as we would like to promote "upstream packaging"), and can be verified by checking the signature that is optionally embedded inside the AppImage.

While upstream packaging surely would be ideal, reality though might be that things will be distributed and there might be competing (for the good) instances of people doing AppImages for given application sources. After all, CopyLeft software encourgages that also a bit, there might be a scene of people remastering software and enriching things e.g. with custom plugins (ideally with good ones ;) ).
Or there could be variants of AppImages depending on the legal background (compare what http://packman.links2linux.de/ does for openSUSE (& else?)). Or people do their home-brewn versions, as dedicated for their target group (family, company), where one also wants to properly mark the creator, to be able to set things apart.

[probonopd]

I am also a bit unsure where to make the cut when it comes to the description on the container what is inside the container

When you run the AppImage with --appimage-extract, then what you get in squashfs-root/ is what is inside the container, and has nothing to do with the description of the container as such.

While upstream packaging surely would be ideal, reality though might be that things will be distributed and there might be competing (for the good) instances of people doing AppImages for given application sources.

True, but for "normal users" it's safest to only run AppImages that are coming from the application project's official download page.

[kossebau]

I am also a bit unsure where to make the cut when it comes to the description on the container what is inside the container

When you run the AppImage with --appimage-extract, then what you get in squashfs-root/ is what is inside the container, and has nothing to do with the description of the container as such.

I fear you lost me here, I mean as in metadata/description. Not the actual bits and bytes and how they might be arranged by file blobs. But like you write content listing on a box, so it's obvious what is inside. Including production date, best-before date, perhaps production cycle. Or the color, if color is an option for the content. So anything which keeps this instance separate from others or might be otherwise interesting for the consumer.

While upstream packaging surely would be ideal, reality though might be that things will be distributed and there might be competing (for the good) instances of people doing AppImages for given application sources.

True, but for "normal users" it's safest to only run AppImages that are coming from the application project's official download page.

I might not make friends with application projects, but for normal users it's securest to only run AppImages coming from qualified AppImage creators ;)