followmyvote / stakeweightedvoting Goto Github PK

Right now the contest generator is an implementation detail of BackendWrapper, so expose a method BackendWrapper::refreshContests which destroys the old generator and fetches a new one from the server. Add relevant docs.

Currently the status of a decision (cast, casting, stale, etc) is a property of DecisionWrapper. Move this to ContestWrapper. Also create the new states NewPoll and Ended.

Add support for creating a contest and publishing it to the blockchain. Related: #19 (client-side equivalent), #40 (transaction creation). This is triggered by a call to ContestCreator->purchaseContest() in shared/capnp/contestcreator.capnp.

The server will calculate the final price for the contest, and return a purchase API to the client along with a list of price adjustments due to coupons or extra fees. When the purchase is complete, the transaction creating the contest should be created, signed and broadcast.

(load all into RAM, audit the entire trail, make it available to the UI)

The current network API of getting a contest list is unsuitable for the application, as we're really looking for more of an infinite feed of contests; therefore, the contest list will be removed and replaced with a new API which implements a generator of contests (i.e. it returns a new contest each time it is called). This should yield a much cleaner and simpler design for the feed list.

Make sure decisions are stored in canonical form (i.e. no opinions of zero) and that comparisons between decisions do not return false if the only difference is opinions of zero.

(copy apache/crypto)

The app needs a way to submit feedback. Typically this would go in the overflow menu on Android; no idea where iOS puts it (@kalli8 You use an iPhone, do you know where this would go? Haha).

Currently the GUI has no way of getting the list of contests which the current user has created. Add a call to VotingSystem or ChainAdaptorWrapper for this.

See related discussion in #9. This issue tracks the exposure of the contest generator to the GUI instead of keeping it an implementation detail of BackendWrapper. This greatly simplifies BackendWrapper and paves the way for reusing the ContestGenerator code across all the contest list use cases.

As #2 progresses, the application support for decisions increases, but the GUI tends to fall behind. Update the GUI to support the full decision lifecycle including displaying decision state, allowing decisions to be updated when stale, etc.

(verify after generation)

Implement the Backend API in the GrapheneBackend

• Contest Feed
• Contest search
• Contest result fetching
• Contest purchasing/creation
• Coin detail fetching

Show contest results as reported by server in VotingApp/qml/ContestPage.qml

First, determine how ID verification will be done and what the UI will look like, then create a UI taking the user through the ID verification. Also implement server-side stake allocation based on successful ID verification.

All matters related to creating a BlockchainWallet which connects to a real blockchain/wallet, and can sign/broadcast transactions (see: #40)

• Create websocket server in app which listens for web wallet to connect
• Send notification to web wallet specifying which IP/port to connect to
• Define API between web wallet and app
• Implement API between web wallet and app, connecting app infrastructure to wallet

All configuration required for connecting the app to a real blockchain wallet/client, including GUI settings and the connection establishment and maintenance.

PromiseConverter should take a task set as input; it should not create its own.

Several components here:

• Add data types and APIs to capnp schemas
• Add QML wrappers for new capnp data types
• Add support in BackendWrapper for getting and submitting contest creation request wrapper
• Add GUI support for filling out the contest creation request wrapper
• Add GUI support for making the purchase
• Add support in ChainAdaptorWrapper for making the purchase
• Add stub server support for fulfilling the request

In the data types and APIs section, we need a price schedule type which contains all of the prices for contest creation, and an API to fetch it; as well as a contest creation request type which specifies all of the necessary information for the server to create the contest, and an API to submit it in return for a purchase interface.

We need QML friendly wrappers for the contest creation request and the price schedule.

The information we are collecting to create the contest is the title, question/description, contestant list, stake coin, and sponsorship details. The sponsorship details include the number of sponsored votes to buy, the limit of votes to sponsor, the end date of vote sponsorship, and whether or not to show the contest in voter feeds if sponsorship is unavailable.

Implement server signature creation and validation by the app. The app will only display contests which are signed by the server, and will only display custom contests (see #41) whose custom code is signed by the server.

Implement logic to create, authorize (in the app, request confirmation from the user), sign, and broadcast transactions to the blockchain.

(proprietary format you can't open with anything else but our software, drag and drop and audit trail into the app, filtering UI/UX)

Ad space at top
Chart:

• Issuer
• # of active polls in this coin
• # of votes by period of time (1 hour, 1 day, 1 week)
• Are you eligible / do you have any of this coin checkbox

Will look like http://coinmarketcap.com/

Before any kind of live launch, we need to add analytics tracking to the app.

Add a screen listing the contests created by the current user

Since our UI technology (QML) allows dynamic evaluation of UI definition and logic, we can ship customized contest appearances over the chain, allowing us to update the contest display code over-the-air, or create a contest which has a custom appearance. Add support in the UI for ensuring that a valid FMV signature is available for the custom code, then rendering it in the UI.

It will be necessary to take the server down (or at least interrupt service) periodically for maintenance. Add support to the protocol/app for notifying active apps of upcoming interruptions so the user can be alerted and given a chance to get to a consistent state before the interruption.

Add support to the server for tallying the results of a contest and reporting them to apps. Results are reported via Backend->getContestResults() in shared/capnp/backend.capnp

Following #1 the C++ fully supports an 'infinite' contest feed; however, the UI does not. Update the UI to fetch contests as needed, and gracefully handle the possibility that the infinite feed runs dry.

Add a proper onboarding experience to the app, to guide new users through the process of connecting to a blockchain, claiming/getting some assets, casting votes, creating contests, etc.

Have the app notify the backend of user engagement with content. See shared/capnp/contestgenerator.capnp for the API and types of engagement we track. Ultimately, this data can be used to show users content most likely to be interesting to them.

Fully implement decision the decision lifecycle, including creation, persistence, submission, stale detection, and replacement.

Networked RPC is not encrypted at present. We want to encrypt it prior to launch, to support authentication and avoid MITM.

I prefer to avoid using TLS, as it's a truly nasty protocol, but it's better than nothing. I also haven't chosen a library to use for crypto. I like libsodium, but I don't think it's got anything for BitShares or Bitcoin style crypto. I could strip down fc to just get the crypto functionality. Or I could use libbitcoin. Once I choose a crypto library I'll probably choose whether to use TLS or a custom encryption protocol.

The UI should now be able to determine which balances the user has which can pay fees. This can be accomplished by getting the list of balances, finding the unique coins the user holds, and fetching those coins to determine which ones can pay fees.

When the user first submits a decision, he should be prompted to select his fee-paying asset with an option to remember his choice for future votes. Eventually this should be changeable from a settings page as well.

Add support to VotingSystem for using the user's preferred asset to pay the fee. TBD: Should castCurrentDecision take another argument for the fee-paying asset, or should it be a property on VotingSystem? Consider that the user may have set the coin when he had a balance in it, but no longer has any of that coin when he casts a vote, which makes it desirable to add it as an argument to castCurrentDecision so the UI can determine this before casting the decision; however, this requires the UI to handle the persistence of the setting.

hot wallet w/ pool on server, replenished by us on our private computers