atomiclabs / hyperdex Goto Github PK

We can with our own electrum client integration, but not currently without extensive polling.
- @lukechilds

From the Figma design:

Could be useful to have some common actions in the Touch Bar.

Currently there is just a single database.

This means if you have multiple portfolios you'll see the same swap history in all of them.

We should change this so each portfolio gets it own isolated swap database instance.

We want to ship with a dark theme by default, but also have an option to use a light theme for users that prefer that.

A failed withdrawal will return:

{"txid":"0000000000000000000000000000000000000000000000000000000000000000","complete":false}

Currently this goes unhandled and the withdraw button will be disabled until app restart.

Unfortunately we don't get any information on what went wrong from marketmaker.

This could be very beneficial for quick security patches, not just for HyperDEX but also any binaries we bundle.

However could also have security implications, if the update process was compromised then an attacker could instantly gain access to all HyperDEX users funds.

We could make an attack like this extremely unfeasible by also requiring the updates to be signed with one (or maybe multiple PGP keys). These could be owned by trusted developers, members of SuperNET etc.

An attacker would have to compromise the update process as well as all of the required PGP keys to successfully push an update.

Currently if an electrum server fails for a single currency, the entire login process fails.

We should allow them to login but notify them that the electrum servers are down for that currency.

We should show the percentage savings of the executed price over what the asked for.

Right now, we just show the current price.

Context: #150 (comment)

Currently there's no way for the user to enable/disable coins via the UI.

We should enable some popular currencies by default and give the user the option to enable/disable all the currencies we support.

@sindresorhus Do you have any experience setting up HMR?

I normally use CRA for React dev and it has it configured by default, I think it would be really beneficial if we had HMR for this project. It'd allow us to remove the persistent state code we've got currently in dev mode and means we wouldn't have to do weird hacks like re-instantiate the api instance.

Also means any hooks we run at login and all other component state will persist throughout reloads, and reloads are basically instant.

Alternatively, could we integrate CRA into our build system, you get a huge amount for free; HMR, simple cli build scripts, pretty error/lint HTML output. Also I think electron-builder now detects CRA and does some stuff automatically to make it easier to integrate.

It's confusing, it makes the user think the swap failed but in reality it never started.

We should show the status as unmatched.

Related: lukechilds/hyperdex-bugtracker#9

We need to make sure we follow the best practices for security before the public launch: https://github.com/electron/electron/blob/master/docs/tutorial/security.md#checklist

We can now do this with:

_api.debug({method: 'cancel', uuid: "c233ab1ebbb5e4b34341779923af19506f5714c512661394f5ea28c4d822a155"})

jl777/SuperNET@015b4ce

(at time of writing not yet in a marketmaker release version)

We should have a single collection of all supported currencies and any parameters they require throughout the app.

Supporting a new currency in the GUI should be as simple as adding the parameters to this single file.

Before we do a withdraw we should do a request to:

{
  method: 'getfee',
  coin: 'BTC',
}

And display the txfee to the user in the confirmation dialogue.

We then specify a txfee property in satoshis to the withdraw command.

This is a new method I just got James to add for us. It's probably not in a main build yet. And not important right now. Just documenting it here.

We're using the https://min-api.cryptocompare.com/ API, so we need to give credit:

Our API is under a Creative Commons - Attribution Non-Commercial license. This means that it’s free as long as you attribute it to us and you are not making money from the data. If you are selling a product that uses our data we charge a fee. The idea is that if you start making a lot of money using our data, we would like something in return. If you are just providing a free service, you can use our data freely. Please make sure you credit us with a link if you use our data on your website or app.

We should either give credit on the HyperDEX website or in the about dialog in the app.

https://modulelab.slack.com/archives/C8ADPSWTB/p1525328006000031

Sindre Sorhus [1:13 PM]
@Luke Childs https://github.com/jl777/SuperNET/commit/8725909b3c12f8df17de0b075422ad3676cc5195 

Have you thought about how the kickstart thing will work? I assume it's just a temporary workaround until mm does this automatically?

Luke Childs [1:14 PM]
no we’ll need kickstart long term
so if they quit the app with pending trades
or in process trades
then restart
we need to filter all the in progress trades and tell mm to resume them
I think it will be a fair bit of work to integrate
mm will most likely give us no helpful feedback in the event that:
- the trade doesn’t exist 
- exists but can’t be restarted
- was already automatically restarted
- is in the progress of being rolled back (edited)
we need to handle all those cases
and we probably won’t get enough information to
and we also need to re-attach event listeners so we get socket updates on restarted trades
if mm auto restarts them without telling us we’ll miss them
so many things that can go wrong
this is exactly why we shouldn’t have two separate swap DB instances…
😞
For v2 we need to push for a built in swap DB in mm that actually works and scales
so we have no internal copy
we just query mm as the single source of truth
They could use sqlite or LevelDB or something light weight

If someone else gets access to your backup they shouldn't be able to view swap info. It contains TXIDs which someone could easily derive the users addresses and balance from.

Currently unmatched swaps stay pending forever

It just needs a few more tweaks. I'll be working on this today.

#4 (comment)

Like REVS and SUPERNET coins.

It was suggested we use http://dexcharts.com or https://dexstats.info, but none of those have official APIs. I don't think it's a good idea to use the internal API they use, unless we can get the guarantee from the ones running them that they will stay up and not change under our feet.

This is not important though, so we can look into it after the publish launch.

Not yet, as it will slow down development.

Related issue: lukechilds/hyperdex-bugtracker#12

Active trades will end up with a lot of swaps there and it could be useful to sort each column and to be able to filter.

Just the error code for now.

But should show descriptive error messages as we get more info on them.

Complete list here: https://docs.google.com/spreadsheets/d/1blgmrJCZ-SfYaJdTTVdk717kZ43R4yzm9YIW2Bt--EM/edit#gid=0

The architecture, how to work with marketmaker, etc. For new maintainers/contributors.

How to update dependencies (We must be careful and review changes).

Currently if any of the 3rd party centralised APIs go down you can't login to the app. This is because we're depending on the USD values we get from the API in a lot of places for convenience in showing/calculating balances.

We should handle the case where some of these APIs may be deprecated or go offline, we don't need to go to great lengths to make sure the app looks perfect in this scenario, but it should still be fully usable.

• Showing empty graphs is fine, or just an error saying no graph data.
• USD withdraw input should probably be disabled.
• Dashboard USD balances are probably fine just all being $0.

Maybe show a modal if the APIs are inaccessible saying we can't get USD price data. This should help prepare the user for any strange USD related behaviour.

We need to write tests.

Especially for the Marketmaker API wrapper and the portfolio utils.

Show detailed swap info in modal

On smaller screens with a high resolution some of the text is quite hard to read.

Related: lukechilds/hyperdex-bugtracker#4

The app should be localized into some popular languages to be more user-friendly to those users. We have not yet decided which languages.

Drop iocane for our own async encryption lib. iocane is good but it's a bit bloated and isn't async so blocks the thread during encryption/decryption which can take a while.

If you call the returned cancel function during the async execution of the callback, the timeoutId will reference the current timeoutId which has already started, not a future id.

We need to not only clear the timeoutId but also flip a local boolean variable and check this before we call setTimeout again.

It would be nice to have a connection indicator showing how many peers are connected in the title bar.

Maybe a green circle that says Connected to n peers. If there are no connections a red circle that says Not connected.

Or something along those lines.

It would be great if the concept of enabling/disabling coins is completely hidden from the users.

We should test enabling all coins (in Electrum mode) by default and giving the user an option in advanced settings to switch between Electrum or full node.

This may result in excessive memory use and be unfeasible. In that case we might be able to get clever and enable all coins on startup, check the balance and then disable them.

Alternatively we could implement balance checking completely on our end with Electrum and just query marketmaker for the address to check. Although this could lead to inconsistencies between what marketmaker thinks the balance is and what our code thinks the balance is. (e.g if one is connected to a more up to date electrum node than the other)

Some entries in the order book have 0 values. They are confusing and it's unclear whether they can be filled or not. We should remove these so we don't confuse users and they aren't included in price calculations.

We should allow users to time lock KMD as collateral to get "zcredits". They can use these zcredits to do 0-conf swaps which should complete in under a minute.

https://komodoplatform.atlassian.net/wiki/spaces/KPSD/pages/87457793/What+are+Zcredits+or+Zero+conf+Deposits?focusedCommentId=96927770

Some people have commented some of the text size is too small in some places in the Exchange view. We have a space problem there, but should be able to slightly increase the text size.

Related: lukechilds/hyperdex-bugtracker#4

The API responses we get from marketmaker or often not that well formatted.

Currently, sometimes we are using them as is and pluck out the properties we need, sometimes we format them into a more usable structure.

We should really refactor the API client to format every response in a clean structure and use that structure everywhere.

This will also have the benefit of meaning we can use the API client as an API reference/documentation. The official docs are lacking and sometimes incorrect.

We should discard any order book responses if the pair doesn't match the current pair. Otherwise if the user changes the pair we can apply the wrong order book or even try and apply the order book for disabled coins.

Also, we should instantly clear the order book state when the trading pair changes. Otherwise it seems quite laggy because the old order book data will stay visible until we get a new response from marketmaker. It's also confusing for users, they may not realise and think it's the correct values for the current pair.

This will only work for pending trades, once they're matched they can't be cancelled.

If marketmaker adds support for cancelling in-progress trades we can support it to.

We can use the Travis cron feature. We have to wait until the repo is public, though.

We are limited to what we can do at the moment because marketmaker is inconsistent with how it reports errors and when when it does report error we very rarely get an error code to reference.

But we should do as much as we can to make the errors clearer wherever possible.

We're waiting on documentation for failed swap error codes: https://docs.google.com/spreadsheets/d/1blgmrJCZ-SfYaJdTTVdk717kZ43R4yzm9YIW2Bt--EM/edit#gid=0

Related:

• lukechilds/hyperdex-bugtracker#6
• jl777/SuperNET#717
• lukechilds/hyperdex-bugtracker#7
• #194
• #404
• #253
• #280

We should validate the currency addresses where we allow users to input them, like in the Withdraw view.

We can't really use a regex as we need to validate the currencies individually to, for example, prevent a user from sending something to a KMD instead of a BTC address.

Resources:

• https://github.com/ognus/wallet-address-validator

marketmaker doesn't have any concept of sell orders due to the any/any order book combinations.

If you are on the CHIPS/KMD pair and place a sell order, marketmaker will place a KMD/CHIPS buy order.

This works but it's not very clear in the UI. We need to clearly show buy and sell orders.

One potential solution here: lukechilds/hyperdex-bugtracker#15

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

We need a tooltip solution that use Portals and doesn't require any state handling or lots of boilerplate. It should be easy to wrap existing content with a tooltip.