Skip to content

Latest commit

 

History

History
119 lines (115 loc) · 6.89 KB

TODOs.org

File metadata and controls

119 lines (115 loc) · 6.89 KB

TODOs

Tasks

Get react-native-navigation to work.

Choose Tech Stack

Vision

Mobile App

The UI should present the following inputs:

A way to pick how much bitcoin they want to buy.

A way to input a bitcoin wallet address.

Pasting into a text field
Scanning a QR code with the camera

A way to input card information for payment.

A big “Buy” button to start the transaction.

The user should know the status of his transaction as it happens.

User accounts should be optional.

How could past transactions be displayed securely?

Maybe we could use the phone’s local storage to maintain a private list of past transactions.

That way the app won’t have to talk to the server for this info.

Server

It should provide an endpoint that accepts the inputs the mobile app sends.

Since the buying process takes time, it should be able to send updates to the mobile app on its progress.

Received money

Bought bitcoin

Transferred bitcoin to address

At this point, our end of the contract is complete, and we could even give them a link to https://blockchain.info/ that confirms to everyone that we held up our end of the deal.

Implementation Questions

How do I manage many long-running and stateful tasks that might crash?

Crash Recovery

I am tempted to delegate crash recovery to runit with user-level (non-root) services.

What if starting a new transaction could be as simple as creating a symlink?

I wonder if we could encode a tiny bit of state (like a transaction_id) in the symlink name and have the service read it.

Ideally, I’d like to have a generic `buy-bitcoin` task and create a symlink like `buy-bitcoin+12345` where 12345 is a transaction_id.

If I wanted to start another `buy-bitcoin` transaction, I’d create another symlink with a different transaction_id.

After some investigation, I now know that symlinks aren’t enough.

I have to create service directory for each transaction, because
runit needs to create its own distinct control directories for each service it’s managing.
These control directories cannot be shared.
I can still use a naming scheme for the tasks that encodes the transaction_id.

Error Handling

A distinction must be made between errors that are temporary and can be retried and errors that stop the transaction.

Precision and diligence is important here, because we’re handling other people’s money now.

State Management

To be expedient and practical, I think I’m going to go with PostgreSQL as my database.

Every step of a transaction needs to have its own row.

Transactions have many Steps.

Each step should have a status so that if the program stops and needs to be restarted, the transaction can be resumed where it left off.

A task starts up by loading its transaction state first.
Then, it tries to move to completion one step at a time.

Wait. What would Rich Hickey do? I know he wouldn’t approve of a mutable status field.

To make this “immutable”, the task that needs to be done and its execution state (status) need to be separated.
A transaction has many steps. A step has many iterations.

The Elixir Question

Instead of relying on runit for OS process supervision, we could use Elixir and build around its BEAM process supervision.

I’d have a lot of new things to learn before I could be useful.

The architecture would be different from what I described above, but it would be more “natural”.

Questions about which library to pick for certain tasks get significantly reduced if we pick Phoenix and use its defaults.

Interop with exchanges may take a little extra work, but it shouldn’t be too bad assuming most of them use REST APIs.

If we ever need to scale out beyond a single machine, Elixir provides a better story.

Log

<2017-06-24 Sat> Let’s Pivot

Coinbase may not be cooperative when it comes to allowing us to resell coins.

So let’s try something different.

Traders want to know what coin to buy so they can make the most profit.

I want to know this.

It’s very difficult to answer this question in a timely manner, because

there are so many markets and

it’s impractical for a human to manually track them.

What if we programatically monitored market data across exchanges and sent notifications when potential buying opportunities arose?

We can notice artificial pump and dumps due to sudden intense volume and price increases.

We can notice more organic pumps also.

Arbitrage opportunities between exchanges are easy to find.

There must be bots that take care of this already.
But it all starts with recording and analyzing market data.

<2017-05-30 Tue> The Elixir Question

<2017-05-28 Sun> Thinking about the management of many long-running tasks

<2017-05-22 Mon> Making it build on Android

What a pain in the ass that was.

I had to install extra Android SDKs, because rnn wanted version 25.0.1 of the SDK.

I had to change some Java code as described in https://wix.github.io/react-native-navigation/#/installation-android .

The number of open issues worries me https://github.com/wix/react-native-navigation/issues .

<2017-05-20 Sat> Made Tasks and Vision their own sections in this document.

I also added a checkbox list for choosing our tech stack.

Hit C-c C-c to toggle a checkbox in a leaf node.

<2017-05-19 Fri> Started the project.