comit-network / create-comit-app

Set up a local development environment for COMIT apps with one command.

---

COMIT is an open protocol facilitating cross-blockchain applications. With COMIT you can for examples exchange Bitcoin for any Erc20 token directly with another person.

This repository contains everything needed to do an atomic swap (locally) on your machine.

If you wish to do an atomic swap on your machine or to integrate COMIT into an application (e.g. a DEX) please take a look at the Getting Started section of the COMIT documentation. If you have any questions, feel free to reach out to the team in our Gitter chat!

Create Comit App

Getting Started

create-comit-app enables you to setup a local development environment for running and developing Javascript apps on top of COMIT. create-comit-app comes with demos and examples to demonstrate how to use the comit-js-sdk.

If you already have Docker, npm and yarn installed you are ready to run a demo-swap on your machine:

For more details please check the Detailed Guidelines and the Getting Started section of the COMIT documentation. If you have any question feel free to reach out to us on Gitter!

---

Detailed Guidelines

1 - Install Docker

Unix

Install docker through your package manager. Make sure the unix-socket of the docker daemon is accessible.

Windows

Windows users have the choice between Docker Toolbox (the "old" docker) and Docker for Windows (the "new" docker). Docker for Windows requires Windows 10 Pro, whereas Docker Toolbox also works on older versions of Windows and Windows 10 Home.

Docker Toolbox

Install Docker Toolbox and start the virtual machine. Double check that the environment variables DOCKER_HOST, DOCKER_CERT_PATH and DOCKER_TLS_VERIFY have been set.

Docker for Windows

To use create-comit-app with Docker for Windows please follow these steps:

1. Set the DOCKER_HOST variable to the docker daemon endpoint. You can find that in the docker control panel, should be something like tcp://127.0.0.1:2375.
2. Disable the TLS verification of the docker daemon endpoint: In your docker control panel: Settings > General > Expose daemon on tcp... without TLS

2 - Install yarn & nodeJS

Install them either from the website or through your package manager.

3 - Create your first project!

create-comit-app contains demos and examples. Demos demonstrate how a swap works in a very simple manner, whereas examples go more into details and add maker, taker and negotiation.

Here is how you set up a project and run demos and examples:

1. yarn create comit-app <your-app-name>,
2. cd <your-app-name>, yarn install and yarn start-env to start blockchain and COMIT nodes,
3. Run the btc-eth demo
   1. Navigate to the separate-apps demo directory cd ./demos/btc_eth,
   2. yarn install to install dependencies,
   3. yarn swap to execute the swap,
4. Run the btc-eth example (in separate terminals for the taker and maker):
   1. Navigate to the separate-apps example app directory cd ./examples/btc_eth,
   2. yarn install to install dependencies,
   3. yarn run maker to run the maker app,
   4. yarn run taker to run the taker app,
   5. Follow the steps be hitting Return to complete the swap.

---

Appendix

Important: You don't have to follow this section, the above section is actually sufficient.

Appendix A: Build the project yourself

create-comit-app is a rust project separated in two modules:

1. create: Contains the logic for setting up a new comit-app project through yarn.
2. scripts: Contains the logic of starting a local dev-environment.
   1. Starts up parity Ethereum node
   2. Start up bitcoind Bitcoin node
   3. Starts up two cnd nodes.

To build the project yourself:

1. Install Docker,
2. Install Rust: curl https://sh.rustup.rs -sSf | sh,
3. Checkout the repo: git clone https://github.com/comit-network/create-comit-app/; cd create-comit-app,
4. Build and install: make install.

create-comit-app's Issues

Replace unwraps with expects/panics and Errors

Ensure there are no unwrap() left.

panic!() and expect() are ok but should only be done in start_env.rs and new.rs files. Bubble up errors elsewhere to start_env and new.

Setup dependabot

Problem

ATM, we have to update dependencies manually, which we practically never do.

Goal

Don't be bitten by a lot of painful dependency updates at the same time.

Recommendation

Setup dependabot.

No automatic tests

Problem: nothing is tested automatically. To check if something works we have to try it out manually.

Goal: to be able to verify that the code that we write works as intended.

Ideas:

• Test start_env and new in isolation.
• Maybe write one big integration test that checks that start_env and new work together.
• See if there are any functions that can be unit tested.

Example strategy

Goal

Improve the consistency of the examples to improve the learning speed.

Problem

With 2 different examples we can already see that examples can be quite different in behaviour and implementation detail. At the moment there is no strategy for adding more examples.

Proposal (list of questions and answers)

Multiple example testing against the same environment:

• If the environment changes, is it ensured that all the examples can still be run?
  • Covered by E2E tests
• Can the examples be run in any order?
  • Probably not that important for now, ensure that each example works with a fresh environment given.

Output of the example is similar

• Always use colours when logging (or never or sometimes)?
  • Always use colours
• Always have log-levels?
  • Always use log-levels (error, info, trace (technical))
• Always split between functional output and technical details?
  • Yes, like in the original hello swap
• Always return transaction hash?
  • Yes (the complete transaction is not useful in the console)

Behaviour proposal:

• Maker-Taker bounce vs. all in one?
  • Change all the examples to have separate maker and taker (e.g. 2 terminals)
• Stopping after each step vs. going through?
  • Add a flag to allow that ALL examples can be manually stepped through by user.
    • Without the ability to step one cannot check anything in between (e.g. transactions, current balances...), so there is not much value to automatic steps.
    • For testing we should be able to turn the steps off.
• How to exit an example?
  • Always with 0 or 1

Example naming:

• Functional names instead of names driven by assets
  • Rename btc-eth to peer-to-peer (or hello-swap)
  • Rename erc20-btc to using-orderbook (or simple-orderbook or auto-execute-with-orderbook)
    • The name does not have to be overly complicated, each example has a README where we can specify details of what the example is about.

Delete temp folders used for docker volumes

the folders used to create docker volumes in /tmp/create-comit-app are not cleaned up.

They should be deleted.

#32 may help (close this one if done in #32)

Create a new release where btsieve is already integrated in cnd

Problem: btsieve is hard to explain - now that it is integrated in cnd we should not have to mention it.

Goal: Not have to explain btsieve in Osaka

Proposal: After cnd remove btsieve from startup. Adapt the cnd config creation if needed.

Bounce between maker and taker example

Problem

At the moment Hello-Swap contains both maker and taker and the user sees how they interact but cannot control much. It is difficult to understand

Goals

• Be able to understand more clearly that there are two sides.
• Be able to focus on one side.
• Be able to "just run one side" of a trade.

Proposal

Split the example so one has to run it in two terminals. One terminal is the maker and one the taker.

Additionally it would be cool to, once/if we have testnet support, be able to run the example with another person. (One person running maker and one person running taker side.)

Setup testnet environment

Problem

For now, create-comit-app allows setting up regtest nodes for Ethereum and Bitcoin. While this is suitable for a developer environment it is far away from a real-world setup.
Especially for workshops a testnet setup is more suitable as it enables participants to trade against each other.

Goal

Enable create-comit-app to setup a testnet environment with:

• cnd config that uses online blocksources
• for Ethereum: use infura.io
• for Bitcoin: use our bitcoind note running on bobtimus.coblox.tech for now. In the future we might want to change this to an online blocksource.

Remarks

• Ethereum:
  • We will either need to provide an API key for infura.io or tell the user to get one herself - I opt for the second option
• Bitcoin
  • We currently rely on bitcoin-rpc in create-comit-app and comit-js-sdk (?) - we can provide the authentication details for our testnet node for a first version and rethink how to handle this in the future;
• Funding of Maker & Taker can be an extra manual step, e.g. we can print their addresses and some faucets which we recommend. The user can then get coins themselves;
• ERC20 funding: I'm not sure how this can look like, but I would propose to deploy a fake ERC20 contract with a mint function which is open to the public and when passed in an address, it just mints X tokens for that address.

Initialize project correctly from name given by users

Problem

Currently, the name of the project that is initialized for the user is hardcoded in the package.json:

create-comit-app/new_project/package.json

Line 2 in 0a64066

"name": "new_project",

Goal

Create a project that is consistent with the users input.

Recommendation

Search and replace all uses of new_project after it is has been initialized with the name the user passed on the commandline.

If the user types: yarn create comit-app my-cool-app, the package.json should say: "name": "my-cool-app".

Windows release

Problem

For the Hackathon in Dez. we might have Windows users. Windows is currently not supported.

Goal

Release create-comit-app for native Windows.

Proposal

Time-box this. Since create-comit-app is reasonably small we don't have to use github-actions.

Location of env file during start-env is unknown

Problem

Running create-comit-app start-env creates an env file somewhere in the file system, but the location is not indicated when running this command. If a user wants to locate the file in order to look at values such as comit node HTTP API endpoints for manual debugging they have to look at the source code.

Goal

Not require users to read the source code if they want to manually debug or inspect the environment.

Recommendation

Log its location after start-env has finished writing to it.

Setup bors

Problem

We work a lot on create-comit-app and merging PRs manually is cumbersome.

Goal

Make work on CCA as efficient as possible.

Recommendation

Setup bors.

Experiment with snafu for error handling

Problem

CCA is a user-facing CLI and should therefore have good error messages. Currently, we simply Debug-print our error enum variants to the user if something fails.

Goal

1. Provide good and meaningful error messages to the user.
2. Gain experience with other error handling libraries so that we can also improve the situation in cnd.

Recommendation

Take a look at snafu and use it in CCA.

Remove `starting two btsieves` from log output

Problem: btsieve is confusing for people to see it without explanation.

Goal: Don't have to mention btsieve during presentation (it is re-integrated in cnd now anyway)

Recommendation: Just remove the log output until we actually remove it from the startup.

Build a Mac OS release binary automatically

Problem

We need to compile the Mac OS Binary locally when releasing a new version of create-comit-app

Goal

Avoid manual steps for a smoother devex.

Recommendation

Use GitHub Action on a mac os environment to produce and attach the binary.

Copy-pasta/see #33.

Use CircleCI for... CI

Since this repo is open source, we should go for circle-ci.

This should only replace the current Travis config.

Originally posted by @bonomat in #2

Improve create-comit-app UX

Problem

create-comit-app usage is still a bit cumbersome as there is the new and start-env command. Knowing that start-env needs to be done in a different repo.

Goal

User types the following commands to run an example:

yarn create comit-app foo
cd foo/examples/bar
yarn # Install dependencies
yarn run env # Does create-comit-app start-env and hog the terminal
--- open new terminal
    yarn run swap # Run the example, name of the command is example specific
    # OR
    yarn run taker
    ...
    CTRL-C
--- back to "env" terminal
CTRL-C

User types the following commands to run their app:

yarn create comit-app foo
cd foo
yarn # Install dependencies
yarn run env
--- open new terminal
    touch bar.js
    yarn add some-deps
    <update package.json with a start command>
   yarn start
   ...
--- back to "env" terminal
CTRL-C

Reduce the number of manual steps when releasing

Problem

When releasing, once the binary are attached, we need to run npm publish locally to upload the latest binary to npmjs.com

Goal

Reduce the number of manual steps for smoother devex.

Recommendation

Add a GitHub Action to automatically publish on npm once mac and linux binary are attached to the release.

git somehow expects the `user.name` to be set when checking out `Hello-Swap`

during the workshop we had one participant running into this issue:

./create-comit-app new my-cool-app
thread 'main' panicked at 'Failed to create initial commit: Error { code: -3, klass: 7, message: "config value \'user.name\' was not found" }', src/new.rs:25:22
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace.

seems to be related to the git configuration

Strong recommendation: Do git init but do not do an initial commit.

Redesign using async/.await

Problem

CCA has a quite some complexity because it is basically a composition of a lot asynchronous tasks (Futures).

Goal

An easy to maintain and understand codebase.

Recommendation

Move the whole codebase to async/await and async-std.
As part of this re-design, consider problems like:

• #41

Build a linux release binary automatically.

Problem

We have to build release binaries locally to when releasing a new version.

Goal

Have a binary built automatically when releasing

Recommendation

Try to do it with GitHub actions.

Improve ergonomics & feedback

Problems

1. User must run new then cd the new folder and then run start-env. Failure to do so will return unclear errors.
2. If a user tries to run start-env twice, he gets unclear errors.
3. The folders used to mount docker volumes, currently stored at /tmp/create-comit-app are not cleaned-up.

Goal

1. Remove the cd step.
2. Explicitly stop the user to run start-env twice on the same machine.
3. Clean-up the folders used for volume
4. Update hello-swap if needed (open new issue)

Recommendation

As per the Linux Information Project:

Among the various subdirectories within /var are /var/cache (contains cached data from application programs), /var/games (contains variable data relating to games in /usr), /var/lib (contains dynamic data libraries and files), /var/lock (contains lock files created by programs to indicate that they are using a particular file or device), /var/log (contains log files), /var/run (contains PIDs and other system information that is valid until the system is booted again) and /var/spool (contains mail, news and printer queues).

1. Hence, the proposal would be to replace ./.env with /var/run/create-comit-app/env.

2. This could then be used as a lock file, meaning, if the file exists and a user runs start-env then an error should explain that it seems like an instance is already running:

▶ create-comit-app start-env > /dev/null 2>&1 &
[1] 71840
▶ create-comit-app start-env
An environment is already running!
If you are sure that no other `create-comit-app start-env` process is running, delete the lock file at `/var/run/create-comit-app/env`.

3. Finally, move the temp folders under the same /var/run/create-comit-app/ so start-env can delete the whole folder at the end (instead of just the env file).

Create-comit-app can be started twice

Problem: Create-comit-app can be started twice.

a) This takes up unnecessary resources
b) It can be confusing to the user
c) It might actually cause problems because we use static names for docker containers and networks

Recommendation: Fail if we find a .env file in the current directory.

Restructure create-comit-app towards multiple examples and integrate hello-swap

Note: This is the outcome of the discussion with @bonomat and @thomaseizinger 04.10.2019.

Problem

Having multiple repositories as starting point is difficult to understand.

Goals

• Have one repository.
• Be able to have multiple examples.
• The examples are not there to be changed (to build on) but just to take a look at.

Proposal

Idea

The idea is to integrate all examples into cca so there is only one go-to project as starting point. There will be multiple ones. The examples should be functionally driven (e.g. eth-btc, erc20-btc, ...).

When creating a new comit-app you get a template and all examples to look at. The examples can be run through create-comit-app. The examples are not meant as templates to build an application on, but help to understand functional parts.

For a workshop it has to be able to write a new examples (basically re-create one of the simple ones in the example folder) within 30 minutes. We can measure how good the sdk is by that measure.

Folder structure

cca
|- src (1)
|- new_project
--|- index.ts (2)
  |- package.json (3)
  |- examples
  --|- eth-btc (4)
    --|- src
    |- ...

(1) cca rust code
(2) start point for creating a comit-app, an "empty template"
(3) presets all dependencies (comit-js-sdk ...)
(4) contains one self-contained examples, in the future we can create more packages to share between examples (like e.g. wallets)

Commands

• new
• run app
• run example [example_name]

To be discussed:

• start-env still separate?

No hard-coded credentials inside code

Problem: we have hard-coded username and password used to instantiate a bitcoin RPC client.

Goal: have no hard-coded credentials inside code.

Suggestion: use the cookie file instead.

Improve error handling

Problem

At the moment, the error handling in create-comit-app is pretty verbose.

Goal

Minimize the code that is needed for robust error handling.

Recommendation

Out of the experimentation here, I recommend using anyhow and thiserror.

bitcoincore-rpc client is not async

Problem:

The bitcoincore-rpc client we are using is not async and hence blocks the current thread during execution. This is not good because the remaining code is based on futures and hence the executor cannot do its work.

Goal:

Don't block the executor thread.

Recommendation:

We only use the client to generate blocks and fund.

Remove the dependency on the client and handcraft the JSON-rpc request with an async HTTP client like reqwest.

Look into building an image on the fly using shiplift crate that:

• Generate 101 blocks
• Do the funding
• Update contrab to do regular block generation

Setup erc20 regtest environment

Problem

Create-comit-app only supports native assets on Bitcoin and Ethereum at the moment. There is a large amount of non-native assets (aka tokens) on Ethereum.
Cnd supports ERC20 tokens already but it's a non-trivial job to setup a test environment for executing an atomic swaps from ERC20 on Ethereum to BTC on Bitcoin.

Goal

Enable create-comit-app to setup a (reg)test environment with:

• an Ethereum node
  • ERC20 token contract deployed
  • X amount of tokens minted for Maker and Taker
  • X amount of ETH for Maker and Taker
• a Bitcoin node
  • with X amount of BTC for Maker and Taker
• corresponding cnd config
• add contract address to env file

Recommendation

I would recommend to build this directly into the existing start-env command and not create a new one specifically for ERC20.

Image trait is doing too much

Problem

Image trait is implemented for both blockchain nodes and cnd, but it has a method new which instantiates clients for the blockchain nodes yet does nothing for cnd:

create-comit-app/src/docker/cnd.rs

Lines 28 to 30 in 57fe0c7

	fn new(_: Option<String>) -> Self {
	Self
	}

This is dead, useless code.

Goal

To not have dead, useless code.

Recommendation

Move new function from Image to BlockchainImage as @D4nte suggested below.

Run `start-env` even after dev `panic!`

Problem

When developing on create-comit-app and often running the start-env, the new changes may lead to a panic.

Which means that they may be some artefacts not properly cleaned up such as the ~/.create-comit-app folder, the docker network or containers

Goal

Make it possible to run start-env after a panic! that is due to new code when working on create-comit-app

Recommendation

A. Add a panic hook that catches any panic and process with clean up
B. Somehow make it possible to start-env on a dirty environment (while yet not impacting the case where a user do 2 start-env by mistake)

Intercommunication between participants of a workshop

Problem

When we do a workshop people cannot communicate with each other at the moment. Everything is just on the local machine.

When we did our first workshop in Singapore using comit-i we had a lot of dynamic resulting from the fact that people could interact with each other on the UI. The current workshops don't allow that.

Goal

Be able to have interaction between participants for workshops.

Proposal

Grab a mate and a room and come up with an interactive example first. Then decide on the technical requirements.

Network ideas:

• Add a --network flag to create-comit-app's start-env command.
• Setup regtest network somehow.
• Provide another docker image that enables communication through regtest network that we set up.

Move writing of .env file to the main thread

Problem

Currently, many threads try to write to .env file, which can lead to race conditions if not handled correctly.

Goal

Instead, those threads should bubble up the information that needs to be written and the writing should be by the main thread. This would also remove the .env file dependency on starting Docker containers for cnd and blockchain nodes.

Definition of Done: env file path stays in start_env and not be passed

ERC20-BTC example cannot be automatically tested

Problem

The ERC20-BTC example cannot be easily tested as part of the CI as it requires shell interaction.

Goal

Automate run of all examples to ensure our user can always run them

Recommendation

yes | command during tests, @D4nte.

Priority Justification

As it is not tested, we could end up with a non-working example in the repository which could impact COMIT App devs or comit workshops.

Funding problem

Problem

Currently the environment is static, there is no configuration possible to add funds to a certain account/address.

Goal

Be able to fund somehow.

Proposal

Add commands in create-comit-app to allow funding of a running environment. (configuration files are an alternative, but make things even more complicated).

In the long run we should work on the infrastructure in general (like providing faucet, testnet setup and similar for workshops - this needs more thought though), see

Not eagerly fetch docker images from `https://registry-1.docker.io` on every `start-env`

Problem: We always fetch the images. I ran into several timeouts with 500 errors against https://registry-1.docker.io - just could not start the environment then.

Goal: Be able to reuse the images already pulled and not pull on every startup.

Proposal:

1. Find out how/if we can reuse images
2. Define a strategy for reuse vs. a fresh pull (e.g. upon version upgrade)

Allow swapping ERC20-BTC

@bonomat commented on Wed Oct 02 2019

Problem

Hello-swap currently only supports BTC-ETH (or vice versa). The assets are taken from the offer but the ledgers are hardcoded.

Goal

Try to do a swap between ERC20-BTC (or vice versa) and modify hello-swap accordingly to make this easier. Keep ETH-BTC as the main example.

Remarks

We need to think about how we want hello-swap to evolve and how to support different use cases in the future.
@da-kami proposed to create something similar to truffle unbox https://www.trufflesuite.com/docs/truffle/advanced/creating-a-truffle-box
Imho, ERC20-BTC is an essential feature and I would not create an extra box for this but would build this directly into the main example, however, keep the flow as is, i.e. still have the swap of BTC-ETH swap hardcoded.

[JavaScript/NodeJS] Do not release prompt until create-comit-app is terminated

Problem

When starting create-comit-app start-env via the npm package, when CTRL-C is received, node gives back the terminal handle before create-comit-app finishes to shutdown:

▶ cd create-comit-app/.npm
▶ yarn install
▶ yarn start start-env
yarn run v1.17.0
$ node cca.js start-env
Creating Docker network (create-comit-app)...✓
Starting Bitcoin node...✓
Starting Ethereum node...✓
Writing configuration in env file...✓
Starting two cnds...✓
🎉 Environment is ready, time to create a COMIT app!
^C
Signal received, terminating...

src/create-comit-app/.npm  npm-packaging ✔                                                                                                                                                           21m  ⍉
▶ ✓ # This tick is emitted by create-comit-app
 # as is this new line

Goal

Make it so that node does not terminate until create-comit-app has

Recommendation

Not sure, the signal handling code is in .npm/cca.js

Better handling of docker network errors

Problem

If a previous run of start-env did not clean up properly the docker network create-comit-app then there may be issues.
If only one network is remaining, that is fine.
But if 2 or more are remaining (the network name do not have to be unique) then some strange error such as:

Starting Bitcoin node...Error encountered when starting container: Fault { code: 400, message: "network create-comit-app is ambiguous (3 matches found on name)" }

is displayed to the user (and start-env fails).

Goal

Make it seamless for the user if a previous start-env run did not clean-up the docker network.

Recommendation

Up to you!
A. abort and tell the user how to clean-up the networks: docker network prune if the user has no other relevant network or clean-up manually any create-comit-app network if the user knows what to do.
B. Go in a failure path where the app will try to clean-up all the create-comit-app networks.

1. then continue as expected with our without showing a warning
2. then error out and tell the user to run the command again.

Make it easier for users to run the application

Goal: Make it easier for users to run the application

Problem: The binary name is very long.

Recommendation: Rename the binary name to cca so that people only have to type cca start-env.

Better feedback on `new`

Problem

No message is displayed when new is successfully done.

Goal

1. Let the user know once new is successfully done (or failed).
2. Possibly, indicate to the user the next step to be done (start-env)
3. Possibly, indicate to the user the following step to be done after start-env.

Recommendation

Print a message once new is done, for example:

> create-comit-app new foo
Your project `foo` has been created!
Now, start your development environment by running `create-comit-app start-env`

Relax tslint rules or use Javascript

@D4nte commented on Fri Sep 27 2019

Problem

During a workshop/live coding, the linter is cumbersome, especially around unused imports and variables/arguments.
However, we want to keep the hello-swap codebase to a high quality level.

Goal

Only apply linter when we modify the hello-swap codebase, not when it is used as part of a new project

Recommendation

Steps:

1. Relax the rules in the default/shipped tslint.json.
2. Create a new tslint-strict.json file that is used during the CI and commit hooks

---

@D4nte commented on Wed Oct 16 2019

Findings: none because tsc uses options in tsconfig.json so both tsconfig and tslint files should be modified.

Give feedback to the user when images are being pulled

Problem

The user knows that an image in being pulled but does not know the progress.

Some docker images being bigger than other, it would be great to have some feedback.

Goal

Give useful feedback to the user of create-comit-app start-env.

Recommendation

This can be done by adding an .inspect on the stream pulling the image:

create-comit-app/src/docker/mod.rs

Line 121 in 2878009

.pull(&PullOptions::builder().image(I::IMAGE).build())

That prints some progress.

Or something better/more clever :)

Two ways to go:
A. Have a generic visual aid that moves everytime there is some progress (for example, something like |/-\|/-|... so it looks like it rotates when it's pulling
B. Actually decode the data provided by the docker api to show percentage completion.

Inform users what is going on when using the application

Currently, the application doesn't print any output until the blockchain nodes have started up.

Problem: The user has no feedback for about 5 seconds on whether or not anything has happened.

Goal: It should be clear to the user, what the application is doing.

Recommendation:

Light-weight solution: Log something before and after an asynchronous task, like:

> Starting bitcoin node ...
> Done.
> Starting ethereum node ...
> Done.
etc ...

Long-term solution: Provide interactive output of what is happening, with animations etc.

btc-eth example returns bad status code

Problem

After CTRL-C or kill the btc-eth example, the command returns code 130.
It should return code 0 if no issue was encountered as it is the expected usage.

This creates issues to recognise healthy behaviour.

new_project/examples/btc-eth  53-e2e-tests ✗                                                   1h2m ⚑
▶ yarn run start
yarn run v1.19.1
warning ../../package.json: No license field
$ DOTENV_CONFIG_PATH=$HOME/.create-comit-app/env ts-node -r dotenv/config ./src/index.ts
[maker] Bitcoin balance: 10. Ether balance: 100
[taker] Bitcoin balance: 10. Ether balance: 100
[maker] Creating offer: sell {"coin":"ether","amount":10}, buy {"coin":"bitcoin","amount":1}
[taker] Taking offer: sell {"coin":"bitcoin","amount":0.5}, buy {"coin":"ether","amount":5}
[taker] Performing fund action for swap fd7c2de7-5ab8-4e92-8e29-89b7ca600b16
[maker] Performing fund action for swap fd7c2de7-5ab8-4e92-8e29-89b7ca600b16
[taker] Performing redeem action for swap fd7c2de7-5ab8-4e92-8e29-89b7ca600b16
[maker] Performing redeem action for swap fd7c2de7-5ab8-4e92-8e29-89b7ca600b16
[maker] Swap finished with status SWAPPED: fd7c2de7-5ab8-4e92-8e29-89b7ca600b16
[taker] Swap finished with status SWAPPED: fd7c2de7-5ab8-4e92-8e29-89b7ca600b16
^C
[maker] Bitcoin balance: 10.5. Ether balance: 95
[taker] Bitcoin balance: 9.5. Ether balance: 105

new_project/examples/btc-eth  53-e2e-tests ✗                                                  1h3m ⚑  ⍉
▶ echo $?
130

This also means we have to hack around it in the test as we do set -e:

create-comit-app/tests/run_example.sh

Line 101 in 8e60adf

wait $RUN_PID || echo -ne ""; # It always return bad code. See #108

Goal

Not return bad code if everything is good.
Remove this hack:

create-comit-app/tests/run_example.sh

Line 101 in 8e60adf

wait $RUN_PID || echo -ne ""; # It always return bad code. See #108

Recommendation

Check the signal handling and fix it.

Update instructions to use npm package

Problem

Current instructions tells user to download binary from github, there is a more practical way to install create-comit-app

Goal

The standard way of using create-comit-app should be descrived as using yarn create or npx

Recommendation

Reproduce the README.md changes done in https://github.com/comit-network/create-comit-app/pull/64/files
Be sure to test them before opening the PR.

Support release 0.3.0 of comit-rs - removal of btsieve binary/docker

Once comit-rs:0.3.0 is released there will be no need to run btsieve as a separate binary. This will speed up start-env and simplify the code.

Remove the libusb build dependency

Problem

With the introduction of the ERC20 environment (#79), we are also now locally signing transaction through emerald. Unfortunately, emerald brings in a compile-time dependency on the shared library libusb-1.0.

Goal

Have CCA be as easy to compile as possible: no dependencies on shared libraries.

Recommendation

Make a PR to emerald-vault-core to feature-gate whatever code depends on libusb.

Add automated tests for the env file generation

Problem

Currently, the serialization of the env file is not automatically tested. This causes regressions that are only caught once you try to run it against an example or an application.

Partly, this issue is caused by us not making good use of Rust's type system, hence the compiler cannot check certain things for us (like writing all the variables to the env file).

Goal

1. Ship stable software to users.
2. Catch errors as early as possible.

Recommendation

Model the env file as a struct that has a dedicated method for serializing. Write tests for serializing this struct and compare it.

By using a struct instead of the methods on EnvFile directly, we already get feedback at compile-time instead of cryptic errors during the e2e tests with the examples.

Publish create-comit-app on npm

Problem

User has to:

1. Find the create-comit-app repo
2. Select the right binary for its platform
3. Download the binary
4. unzip the binary
5. execute the binary

Goal

Reduce the steps above by publishing create-comit-app on npmjs.com as it is the one guaranteed package manager that a TS/JS dev uses.

I check https://www.npmjs.com/policies/open-source-terms#acceptable-use and https://www.npmjs.com/package/create-react-app and it should be fine.

Recommendation

Upload various binaries on npm (one for each platform) so that a user can just do:

npx create-comit-app
# or 
yarn add create-comit-app && create-comit-app

Similar example output

Problem

When running the btc_eth examples the output differs quite a bit from the erc20_btc example. This might be confusing when using create-comit-app outside a workshop where this can be explained.

Goal

When the user runs any example the output is similar so the user can relate to it.

Proposal

For now I would only fix the output, the behaviour of the examples CAN (should?) be different so that one can see what is possible.

In btc_eth:

1. Log the transaction-hashes instead of the transaction return values (on logger data level) Upgrade SDK to 0.4.0.
2. Remove it; delete it; bin it.

In erc20_btc:

1. Use the logger, so we can have colours as well.
2. Optional: Print more functional text (like in btc_eth example), move the transaction IDs to the data level.