Brainstorming

Brainstorming on type-3 images

This page is for brainstorming about a hypothetical type-3 image format that may be introduced at some distant point in the future. Currently there are no current plans yet since this is in the very early requirements gathering stage, and we don't want to bring out new image types frequently (since this always causes a lot of work for everyone). So we'd rather like to take all the time to get the next format "right".

Filesystem

• Consider the claims made in https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-format/9466 and think about how the situation can be improved

zstandard

Investigate and decide on using zstandard

Delta updating and P2P distribution

• Chunking and hashing with knowledge of the content. Same algorithm should be used for both Delta updating and P2P distribution for the sake of simplicity and code reuse. May well need a filesystem that is specifically optimized for this

Metadata

• Make it easier to extract metadata and data needed for system integration. E.g., only allow png as .DirIcon, disallow svg, disallow symlinks, etc.

Container format

• Is there a container format that could be extracted by unarchiving tools, and that could still be a valid AppImage at the same time?
• Can we provide an easier way to determine the offset at which the filesystem image starts, without having to parse ELF? E.g., wrap everything in something like .ar?
• Can we embed the .zsync file somewhere before the filesystem image starts? This way, we would need only one file on the server rather than two

Full ELF spec compliance

Currently we are using "reserved" bits which does not work in all cases, e.g., ldd gets confused by this.