Binaries and config distribution 
Before v1.0.3 came out, I made a [branch on my fork](https://github.com/Jabster28/haveno/tree/flatpak) for adding Flatpak binaries, since they have a lot of safety features like sandboxing and filesystem access. However, now that Haveno's going for a more decentralized approach with separate networks, I'm unsure of how we should deal with distributing the Flatpaks (and other binaries).

Flatpak software managers will let you install `.flatpak`s if you open them, but the way they're intended to work is similar to most other package managers. They expect to have a repository hosted somewhere that contains the files and update data, so that they can update automatically in the background and do any other tasks that need doing. The same can be said for the `.deb`s and `.rpm`s that our CI builds. But the decision of what repos and what to upload to which repos depends on the way we decide to implement the network configs.

Whatever choice we make in sharing binaries should be kept consistent, in my opinion. I'm building on the ideas from #911 and #903 in their thoughts on ways implement to this, and I feel like this decision shouldn't be taken lightly. I think the different ways of sharing them come down to these two questions:

- [ ] Should the "network configuration" (arb keys, seed nodes, fees, appdir, etc.) be configurable at runtime?
	- This is currently not possible, and as such all Haveno networks must build their own binaries and distribute them themselves if they want to have compiled artifacts. This could be confusing for some, as downloading an exe from the "official" Haveno repository will simply not work.
	- If this was the case, virtually all Haveno users could use this upstream repositories (or anywhere else) for their app downloads, and simply download the config from the network(s) they choose. This would also make verification and scam checks easier, as all the binaries should have the same checksum.
- [ ] Should a "network configuration" be configurable at compile time?
	- If configs can be set at compile time, and can't be overridden, we end up with a similar situation with how it is now; users can opt to get their binaries from their specific network via whatever means the network offers. However, they can also download the "official" Haveno binaries and download a JSON/TOML/whatever to use their network.
	- Allowing a "compile-time config" to be overridden by a runtime config would result in a bad UX in my opinion. ~~A user could potentially try to check the integrity of what they think is an installation of network A (since, to them, it runs on network A) while the compile-time config inside the binary defines it as a network B installation, resulting in a failed integrity check.~~
Edit: After some thought, I'm sure this would be fine as most would be able to simply not check their sums again until they update their binaries.
	- Disabling compile-time configs would mean that every binary running a non-forked version of Haveno could be checked easily, and you would never need to re-install the application to change networks. This would, however, force users who arrive at a network to download two files - the official build and a network config.

_The second bullet point assumes the first in these examples._

From the (little) thought I've put into this, I think allowing an overridable (but still optional) compile-time configuration - while also allowing for a file to be read if there's no config present - is the best way to deal with configs. This would allow for the Haveno group to distribute binaries and upload them to Flathub and other centralised software repositories and making integrity checks easy, and it would also allow for networks to set up their own Debian PPAs/Flatpak repos for a more trustless design.

## Appendix

"Compile-time" and "Runtime" are used in this to refer to whether a specific config is included into the binaries when compiled or not. By compile-time, I mean the time when the resulting binaries are built (and as such the contents of such binaries). Runtime implies that the configuration can change while the application stays installed by, e.g., moving a file, restoring a different backup, resetting the config, etc.

cc @woodser @chefnaphtha @mcneb10 for their thoughts