Comments (2)
The output is from the specification used for rippleAPI https://ripple.com/build/rippleapi/#order, where direction is determined solely by the tfSell flag https://ripple.com/build/transactions/#offercreate-flags - if this flag is not set, its considered a buy. Note that some offers here have XRP as the quantity and totalPrice in USD, while others have the quantity in USD and totalPrice in XRP. One or the other is probably what you are thinking of as a sell, as they'd show up on opposite sides of the orderbook.
from rippled-historical-database.
In this case, the "direction" should not be included. It is misleading and provides no useful information. The correct implementation of the current behaviour would be to include a "tfSell" boolean in the responses (but it's doubtful many would be interested in the state of this flag anyway).
As I understand it, the tfSell flag does not relate to the users perceived "direction" of a given trade. That is determined by the users arbitrarily-chosen perspective on the two currencies about which they are requesting information. Unfortunately, for a response that may include a variety of currency pairs, returning "correct" results may require some kind of widespread architectural change.
What users would generally expect of a "direction" field would be as @ihomp described - the "buy" or "sell" would be reported as relative to the user-attributed "order" of the base/counter pairing of the supplied currencies. In this case however, a discrepancy between the way rippled internally stores transactions, and the way most users expect to see them would need to be addressed in the historical database (and presumably also the rippleAPI, though I am not familiar with if/how it does that as I don't use it).
What I'm meaning, is something such as an array called "trade_perspective", that contains the two currencies involved in the request, that could be used to determine the "buy" or "sell" direction returned to the user: { trade_perspective: [ "XRP", "USD" ] }
However, a simpler solution that could work for all cases is to simply rely on a canonical "order", and provide a user-requestable "flip" for such default results that do not match user expectation. Eg, resort to "alphabetise" as the system-wide canonical/default "order" for base/currency pairs, and enable the user to specify "flip"'s of either single currencies (to affect many results), or currency pairs (to affect specific results) in request headers to return whichever don't match their expectations to the order they expect.
It's arguable however that almost everyone expects XRP to be the base in most requests, so perhaps pairings involving XRP could be the only exemption from the base/counter alphabetising rule, and "flip" could default to on for XRP paired currencies.
This is an unfortunate situation - but I can't see how a "direction" can be established usefully without involving the user to determine their perspective in order to provide meaningful results.
from rippled-historical-database.
Related Issues (20)
- offline version of historical database HOT 2
- Pagination Fails: "unable to retrieve transactions" HOT 2
- npm install, not installing configuration files. HOT 3
- TypeError: Cannot read property 'max_sockets' of undefined HOT 1
- Can I run the application in a container? HOT 2
- Rippled historical database hbase raw ledger data HOT 2
- How to make batch/bulk get rest api calls?
- DestinationTag:0 getting stripped to destination_tag=undefined HOT 3
- Erroneous "counterparty" field included for XRP in GET balance_changes response
- Balance change of 10 XRP attributed to "exchange" that hasn't appeared to occur
- Config DATA api for local ripple network HOT 6
- testnet.data.api.ripple.com has stopped syncing for 2 weeks HOT 3
- /v2/accounts/{address}/transactions fails to return if descending=true HOT 1
- Get Single Validator Report is showing unexpected data
- "exchanges" option: interval=1minute
- exchange_volume reports total volume of 0
- data.ripple.com cannot retreive data
- reports endpoint giving wrong results HOT 4
- I got "Error calculating ledger hash: 11 Error: `8G` is not a valid hex representation of a byte" error
- Testnet rpc end point not working correctly
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rippled-historical-database.