User experience on different deployments

[thomaseizinger]

We have been talking about providing various deployments of the taker. The three most recent ones are:

1. Docker container, optimized for umbrel
2. A desktop client, likely bundled using tauri
3. Standalone service (homebrew, AUR package, etc)

These environments are fairly different in how they need to be configured. For example, umbrel provides us with a seed that we can use to initialize our wallet, whereas in a desktop environment, we need take care of this ourselves by either providing a seed file, integrating with OS-native keychains or the like.

This discussion thread is about designing the user experience on how we the product to behave on these various platforms. The goal here is to eventually do #984 but for that we need decisions on desired experience on these platforms.

Umbrel experience:

• Integrate with umbrel APP_SEED env variable either by reading the env var directly or by having a binary that accepts an argument (as currently done)
• Commandline parameters work fine from within the docker container
• Generally, the design philosophy here is likely centered around being docker friendly and avoid any umbrel specific things. What will work for docker will work for umbrel and by avoiding umbrel specific things, we allow people to use the docker container outside of umbrel.

Desktop experience

We cannot rely on commandline parameters for desktop apps because they are not launched from the terminal.

• Network: To keep things simply, I'd suggest to hardcode the desktop app as mainnet. For internal testing, we can provide a build-flavour for testnet.
• Data-dir: Being a desktop app, we can choose sane platform defaults and get rid of the config option altogether
• Maker: I think hardcoding would be the best option. If we only allow mainnet, then there is only one maker to connect to anyway.
• Seed: This is probably the trickiest part. A seedfile is great because it allows the user to control access to it via standard filesystem ACLs (Also see this article on this topic: https://smallstep.com/blog/command-line-secrets/). There are also possibilities of integrating with OS-specific things like Linux's SecretService to store secrets in a secure way.

Standalone service

• Need to rely on commandline parameters
• Some overlap with desktop in regards to the seed file, although we can likely simplify things here because we know the target platform (i.e. homebrew is always MacOS, etc)

---

The big problem to solve here is deciding, how many different binaries do we actually produce and what do we supply as configuration to via parameters.

To start the discussion, I would suggest the following configurations:

1. Produce a taker binary that is specific for use within docker (and thus umrel). Configuration takes place via commandline parameters. Use of file system should be avoided as much as possible because it is not particularly docker friendly. For example, it would be nice if users would supply a DB connection string here instead of us assuming SQlite so they could use a dedicated postgres for example.
2. Produce a taker binary via tauri for each OS. Minimize configuration altogether. Biggest unknown here is how to handle the seed, also in regards of how users do backup / restore.
3. Produce a taker binary for each OS that is optimized towards running as a background service. Configuration can take place via commandline parameters. Use of filesystem is okay. We can expect users to do backup / restore via filesystem.