Skip to content

[docker] Configurable Docker Compose #652

@mojoX911

Description

@mojoX911

Problem Statement

Create a configurable shell script that runs a templated docker-compose.yml to set up the coinswap backend stack for all users, whether casual beta testers or seasoned devs.

The Configurations should include all possible combinations of bitcoind, tor, makerd, and maker-cli with variable configurations. It should have a default path that quickly starts the default configs with everything connected and ready to go. It should also have options for user to connect to their self-hosted setups too, if they have it.

The infrastructure should be optimized shell script + templated docker-compose with variables. The configuration should be optionally saveable in a file. Users should be able to load previously saved configurations and get started immediately.

The flow should be carefully designed to nudge users towards the most suitable directions. Described below.

The setup steps should have enough instructions to clearly explain what's happening, the nuances of each option. Not all options are very good, and one of them is "very bad". They should choose carefully.

Tor:

  • Prevent users from connecting to the existing Tor. Even if they are running Tor, it might not be configured properly for makerd. Give them the option, but include a BOLD warning: "Are you sure your Tor is configured properly as per this doc?"
  • If not, run the default Tor with default configs and show which defaults are being used.

Bitcoind:

Same as Tor. Detect existing systems, but prioritize as per the following list:

  • Option 1: Connect to your existing bitcoind node. But it should be configured correctly with these instructions. This is the most recommended way. Every user should have their sovereign node set up. But if they don't have it and wanna try out quickly, they can choose the following 2 options:
  • Option 2: Use our pre-configured bitcoind Docker image.
    • Option 2.A: Sync from scratch (~8GB download, ~1 hour IBD time).
    • Option 2.B: Start from a pre-synced image (~8GB download, no IBD needed, ETA depends on network speed).
  • Option 3: Connect with the public Mutinynet node (not recommended). Explain the privacy risk here. This should only be used for quick testing by developers, not by any meaningful user wallets.

Makerd

  • Configure the final makerd to connect with bitcoind and tor as per the above configs.
  • If they select our public mutiny node (no local bitcoind), create a random wallet with a random name. BUT DO NOT Randomize at every run. If a random wallet already exists, load that one. If not, create and load the first random wallet. (we should later deprecate this node option entirely and use electeum/explora APIs).
  • For any other local bitcoind options. Force users to give a wallet name. Show them the list of existing wallets. And let them choose one. Or if they give a new name that wallet will be created and loaded. The "default wallet" concept is more confusing than helpful.
  • Immediately switch to the makerd log after docker-compose up. If that's not possible, give a bold instruction to open the makerd logs immediately. Give the shell command they need to run. That's the only way for now for anyone to fund and fully start the makers. So make sure the user doesn't miss this part.

Maker-cli

  • Set an env alias or something similar to give a very quick maker-cli access to the user. Give them the instruction like makerd above, to use masker-cli --help to explore how to operate the maker server.

After Boot Report.

Give a nicely structured after-boot report, listing all the current configurations used, relevant ports and access information, and relevant data directory paths. In general, report to the user nicely (assume they are devs) for all the information about the full coinswap stack they need.

Optionally Save

  • Give the option to save configs with a user-defined filename.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

Status

No status

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions