search

FollowMyVote / StakeWeightedVoting

An application to vote on proposals where votes are weighted proportional to the voter's balance of a coin
Other
107 stars 30 forks source link

Coin list page backend #78

Open kalli8 opened 8 years ago

kalli8 commented 8 years ago

Create backend support for a specific coin:

nathanielhourt commented 8 years ago

So the first four data points are provided by the server, the last is provided by the app.

The issuer is a field that rarely if ever changes and is a permanent value stored by the blockchain. This can be added as a field in the Coin capnp struct.

The icon will probably be stored on the server. It may come from the blockchain, but there's no guarantee that the chain will support icons for the coins, nor is there any guarantee that an icon will be available even if supported. Ideally, the server could store the icon, but if no icon is available, the app would generate a canned one (sort of like how GitHub does with user avatars).

The next two are stats tracked by the server. These could be added as fields on the struct, but that would mix the struct fields: some are permanent records, others are live stats. I'd rather avoid this, but it means more complexity in the protocol (where do those values come from? Do they need to be updated in real-time?). I think it's worth the protocol complexity to keep the data structures cohesive, though.

The user eligibility is just a question of balances. The ChainAdaptorWrapper::getAccountBalances() call can be used to resolve this in the GUI already, but a stateful API is probably warranted to minimize the amount of logic pushed into javascript.

nathanielhourt commented 8 years ago

Note that I'm using the term "creator" instead of "issuer" as 'issue' is a regulated word and can make people think you're dealing with securities.

nathanielhourt commented 8 years ago

More thoughts on the statistics... The coin capnp struct is made by the chain adaptor, so it can't know the statistics anyways and so I can't add the statistics to the coin capnp struct. The statistics have to come from the backend.

So the question remains: what's the best way to get the stats from the backend and communicate them to the frontend? One way is to add the statistics to the CoinWrapper and then have the BackendWrapper populate those fields (so BackendWrapper needs to know about CoinWrapper) based on some protocol with the backend that the GUI is agnostic to. Another way is to just add an API call on backend and BackendWrapper that fetches the statistics (returns a promise) and have the GUI call it directly.

I prefer the first option, since that exposes a stateful API to the GUI, which is far easier for the GUI to work with. The question is, do I want to expose two coin objects to the GUI (one for the on-chain data and one for the stats) or merge these two concepts in the CoinWrapper? I'm leaning towards putting it all on CoinWrapper since that makes the simplest API for the GUI, and mixing these two concepts in a wrapper for the GUI (which needs both) is, IMHO, less dirty than mixing them in a coin object handled by the chain.

nathanielhourt commented 8 years ago

OK, here's my plan for the statistics:

nathanielhourt commented 8 years ago

For component 4: We're looking for an hourly snapshot of how much stake in the specified coin has voted/changed its vote. The idea is to create a volume chart, which visualizes stake activity over time.

As an aside, we want to track the same on a per-contest basis, but for each contest we also track the total amount of stake which has voted on that contest.

kalli8 commented 8 years ago

It is possible to make the lists sortable? The article below indicates that making something sortable requires backend support. http://stackoverflow.com/questions/20969261/how-to-sort-qml-tableview-in-qtquick-2

nathanielhourt commented 8 years ago

In theory, sorting coins should work as of dcd152801fff2740e604dc669e54604ea6c6eb64

nathanielhourt commented 8 years ago

The only remaining component here is the voting volume history, which is a chart data series. I can't finish this until we integrate Qt Charts, and I'm not planning to do that until Qt 5.6 goes stable and V-Play updates to include it, which will probably be in a week or two. I'm tabling this issue until then.