Binaries and config distribution

[Jabster28]

Before v1.0.3 came out, I made a branch on my fork 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 .flatpaks 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 .debs and .rpms 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

[shortwavesurfer2009]

I see one potential issue and that would be the management of the wallet files. Say I am a user of Alice Network, and I decide to switch to Bob Network. When I make that change, at least right now, the folder would change its name from "Haveno-alice to " Haveno-bob". This, at least as of now, would cause me to lose all of my settings, such as dark mode, my accounts that I've created for fiat and crypto, and my wallet with its balance. I still think this could be done, but I would add a big warning to the process. And if the user doesn't read it, it's on them, not us.

Edit: I like your idea that the network can be included with the binary, but that the user can overwrite the default configuration by supplying their own network file of some sort.

[chefnaphtha]

@shortwavesurfer2009 agreed, i think making the non-network-specific configs global is a good idea

otherwise, yeah, i don't like having the only option of network configuration be at compile time. the official testnet should be the default network, hardcoded as a fallback if no network file is specified

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.

i also don't think anyone would do integrity checks like that, what would they compare to?

[Jabster28]

@chefnaphtha i also don't think anyone would do integrity checks like that, what would they compare to?

Yeah, you may be right. Now that I think about it, someone who can understand how to switch networks would probably know not to check the sums until they update the actual application. I'll edit that bit later.

[Jabster28]

@shortwavesurfer2009 Yeah, your example does sound like a problem. Perhaps instead of editing a file, the "proper" way to switch networks should be to select the file using a menu in the interface? That way the app could do some things automatically like throw up some warnings, copy the wallet files, archive the previous orders etc.

If we're doing it that way, I guess editing the file manually should be advised against.