Market data tab features/additions #168

Open
opened 1 month ago by fekt · 7 comments
fekt commented 1 month ago
Collaborator

Seems users may like to see different market data in the GUI. HACs are not fully supported to show any data, but basic support for DRGX was recently added in 3a160c1136

Connecting to CoinGecko's API is a source of meta leakage. Users should be required to opt in to fetch this data, rather than making API calls by default. I think this was already done via #106, but needs additional testing based on last comments. From what I checked briefly, the checkbox in GUI is disabled by default currently.

This tab does not contain much data and looks dismal. I changed from 2 to 8 decimal places, otherwise, with small numbers, it was showing 0. There are some other quirks with what data is displayed based on local currency setting, which seems to default to BTC.

Some ideas to improve this tab, which CoinGecko has calls for:

  • Line chart for historical price, market cap, and volume

  • Ticker data from exchanges (last price, volume, depth, etc)

  • An option to refresh or control refresh interval

Any other ideas?

I think there should be a vote or majority agreement on whether additional data is added here or if we remove the tab entirely since it's not very useful in its current state.

Seems users may like to see different market data in the GUI. HACs are not fully supported to show any data, but basic support for DRGX was recently added in https://git.hush.is/hush/SilentDragon/commit/3a160c1136af88303d4997590385f0290ba58daf Connecting to CoinGecko's API is a source of meta leakage. Users should be required to opt in to fetch this data, rather than making API calls by default. I think this was already done via https://git.hush.is/hush/SilentDragon/issues/106, but needs additional testing based on last comments. From what I checked briefly, the checkbox in GUI is disabled by default currently. This tab does not contain much data and looks dismal. I changed from 2 to 8 decimal places, otherwise, with small numbers, it was showing 0. There are some other quirks with what data is displayed based on local currency setting, which seems to default to BTC. **Some ideas to improve this tab, which CoinGecko has calls for:** - [ ] Line chart for historical price, market cap, and volume - [ ] Ticker data from exchanges (last price, volume, depth, etc) - [ ] An option to refresh or control refresh interval Any other ideas? I think there should be a vote or majority agreement on whether additional data is added here or if we remove the tab entirely since it's not very useful in its current state.
fekt added the
feature
label 1 month ago
Owner

@fekt I like your ideas to add more data to the tab

@fekt I like your ideas to add more data to the tab
Owner

@fekt one small idea I have for less metadata leakage is to always request both hush+dragonx data (the coingecko api key is ids which looks like it will accept multiple values). That means that instead of coingecko knowing you are using a Hush or DragonX wallet, they only know you are using one of them, but not exactly which. It's not much but it's something.

@fekt one small idea I have for less metadata leakage is to always request both hush+dragonx data (the coingecko api key is `ids` which looks like it will accept multiple values). That means that instead of coingecko knowing you are using a Hush or DragonX wallet, they only know you are using one of them, but not exactly which. It's not much but it's something.
Poster
Collaborator

@duke It looks like their API calls for this data require a single ID for the coin.
https://www.coingecko.com/api/documentation

Their prices endpoint is a little different and accepts multiple ids to obfuscate what we're after a little more, but doesn't return everything for more market-specific data. In recent commit, I copied the existing API call and modified for DRGX, but they could be merged with specifying multiple IDs and parse what we want.

I am using their market_chart endpoint to grab price, market cap, and volume history. I have it generating a chart now only for the price like this. The x-axis doesn't make sense and is only a count currently because a unix timestamp is returned and QT seems to be converting it to a double like 1.709485303342. I need to figure that out or just hide the x-axis entirely.

The placement of this data can be moved around and there will probably be a dropdown or something to switch between different charts.

@duke It looks like their API calls for this data require a single ID for the coin. https://www.coingecko.com/api/documentation Their `prices` endpoint is a little different and accepts multiple ids to obfuscate what we're after a little more, but doesn't return everything for more market-specific data. In recent commit, I copied the existing API call and modified for DRGX, but they could be merged with specifying multiple IDs and parse what we want. I am using their `market_chart` endpoint to grab price, market cap, and volume history. I have it generating a chart now only for the price like this. The x-axis doesn't make sense and is only a count currently because a unix timestamp is returned and QT seems to be converting it to a double like `1.709485303342`. I need to figure that out or just hide the x-axis entirely. The placement of this data can be moved around and there will probably be a dropdown or something to switch between different charts.
Owner

@fekt thanks for looking into the API. The chart looks really good! Very nice to see the market tab getting some love

@fekt thanks for looking into the API. The chart looks really good! Very nice to see the market tab getting some love
Poster
Collaborator

I figured out the issue with the the timestamps being converted to a double. It's a bug in QT that affects QJson only and think it was only fixed in QT 6, but not sure: https://bugreports.qt.io/browse/QTBUG-28560
https://forum.qt.io/topic/66153/qjsondocument-loses-accuracy-on-long-long-int64-data

A conversion worked so I should have a commit soon. Marketcap data for DRGX doesn't seem to be available yet so I need to do some more testing with HUSH instead.

I have a dropdown to switch between different charts. The API seems to get rate limited fairly quick though if switching between charts very fast. Seems like somewhere around only a dozen calls/minute.

Some of the data like volume may not be represented the best because it's returning hourly data instead of a 24 hour volume. This is based on the number of days specified below so I may let users change that eventually. For now it's better than nothing and nice to see a quick representation without having to check exchanges or aggregators.

1 day from current time = 5 minute interval data
2 - 90 days from current time = hourly data
above 90 days from current time = daily data

I figured out the issue with the the timestamps being converted to a double. It's a bug in QT that affects QJson only and think it was only fixed in QT 6, but not sure: https://bugreports.qt.io/browse/QTBUG-28560 https://forum.qt.io/topic/66153/qjsondocument-loses-accuracy-on-long-long-int64-data A conversion worked so I should have a commit soon. Marketcap data for DRGX doesn't seem to be available yet so I need to do some more testing with HUSH instead. I have a dropdown to switch between different charts. The API seems to get rate limited fairly quick though if switching between charts very fast. Seems like somewhere around only a dozen calls/minute. Some of the data like volume may not be represented the best because it's returning hourly data instead of a 24 hour volume. This is based on the number of days specified below so I may let users change that eventually. For now it's better than nothing and nice to see a quick representation without having to check exchanges or aggregators. 1 day from current time = 5 minute interval data 2 - 90 days from current time = hourly data above 90 days from current time = daily data
Owner

@fekt great to hear. As for dealing with rate limits, one idea I have is to cache data returned from the API on disk, with a timestamp. If a user switches between charts very quickly, the code would look for the data on disk first and if the timestamp is new enough, use that, else request from the API.

@fekt great to hear. As for dealing with rate limits, one idea I have is to cache data returned from the API on disk, with a timestamp. If a user switches between charts very quickly, the code would look for the data on disk first and if the timestamp is new enough, use that, else request from the API.
Poster
Collaborator

Initial commit is in dev branch now. No caching yet. Has new requirement to install libqt5charts5-dev. Probably good to test DRGX version while mining to see if it breaks anything.

Initial commit is in `dev` branch now. No caching yet. Has new requirement to install `libqt5charts5-dev`. Probably good to test DRGX version while mining to see if it breaks anything.
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.