Consider multiple form factors for Bisq app like AppImage

[gnrlus]

I'd like more developers of apps such as Bisq, to consider. Please forgive (and correct) anything technically ignorant I've said.

Check this out:
https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others

As a Linux user who needs to maintain a ship-shape file system I prefer to avoid installing packages that will potentially override system dependencies with incorrect versions for the system, and to use existing packages on the system since each system may have certain package versions for security/compatibility reasons. Linux Mint forum advised me against installing .deb packages because of this risk. Of course, it looks like your app is already mostly self-contained and only /opt and /home are populated with files- so that's great!

I like that AppImages require no installation, everything is self-contained and there is no clutter in the file system; just one file, one app; this works well for me so far. They're also a surer bet that there won't be any uninstallation problems. I was unable to remove the Bisq .deb installation using either the command line or my distribution's software management tools, and I had to revert my whole OS to a prior save state (though this might be a problem with my system, I wouldn't be having it with an AppImage. An AppImage is just a file; delete it, and it's uninstalled.)

I don't know if having a compressed source makes much difference; that's outside my areas of expertise.

Self-updating capability can be handy, though I request if implemented to consider the ability to select the version from a menu in case any one version doesn't work with a given OS installation, whether due to an inherent incompatibility in the app or something broken in the OS that doesn't like a particular version, but maybe can't easily be found and fixed. Also, I'd like to keep everything backward compatible as possible so no user ends up stuck without a working app, in case they can't update for some reason. Maybe it's a LTS distro that doesn't upgrade for years or something broken in the system.

The link implies AppImages execute fast.

The article doesn't seem clear if an AppImage can be sandboxed. Surely
by now they can. I don't know anything about Bubblewrap. I use Firejail
and that works for me. By the way, I'm not an expert in sandboxes but I recall reading that anything uses 64-bit hardware virtualization breaks a boundary between hardware and software that otherwise can be used to prevent an app from accessing the hardware in a bad way (i.e. due to a bug). Albeit, everything is 64-bit now pretty much, and I'm not sure if this is applicable to this kind of sandboxing. I recall discovering Dockers used something like this which meant it wasn't really a "container" as the form factor suggested (if I understand correctly).

AppImages can't assume the system color theme so do please keep the dark theme and maybe add full color customization. Perhaps this function can be copied and adapted from another app.

I notice it says Flatpaks are linked to some "dominant company's business case" (e.g. Snaps are central to Canonical). I definitely prefer something with
ideally no corporate dependencies.

It might be best to offer both .deb and AppImage depending on what works best for each user. I have a feeling AppImage will be a choicier deployment option for IT pros and users in general. /opt is a good spot for them of course.

Thank you for reading and considering.