augurproject / augur-ui Goto Github PK

This page is quickly becoming unwieldy. A default sort based on something useful (volume?) and allowing for some others (price, trading fee, etc.) as well as adding basic pagination.

Jack pushed a fix to augur.js so this will work now

The account ---> holdings module is a nice touch, it should also say the market text for each holding.

See:

use web3 lib to implement a namereg client class for use in augur-client

http://ethereum.gitbooks.io/frontier-guide/content/contract_namereg.html

Title self explanatory, leave exp date blank then click submit and it tries to submit

price == 0 no matter what

From #23:

If someone tries to collude during the first half, and you can provide their salt and report and address to the network, you get their rep (because they are a cheater)!
Send a transaction to def slashRep(branch, votePeriod, salt, report:arr, reporter) to do this.

Submitting a report doesn't currently change the UI. It should replace the ballot with a message that tells the user when they need to run Augur again for their ballot to be submitted.

Is it possible to make it so you can refresh the market pages? Right now it gives an error when you try to do this. (I noticed that the markets are identified by some kind of hash, but it doesn't appear to be the market ID -- my suggestion is to just make the identifier in the URL just be the market ID.)

• create market doesn't work
• buy shares to error is back
• share cost : $1 for 1 share --- every share costs $1 no matter what
• new forecast: 0/100 no matter what

(All of these things used to work on the night of the Mayweather vs. Manny fight as I tested them)

Uncaught TypeError: this.state.simulation.cost.toFixed is not a function

occurs upon an attempt to buy / sell shares

So getSimulatedBuy and getSimulatedSell were revamped: they return [cost, price] --- price being the new price for that outcome if you bought, and cost being how much money you will get paid if you sell, or how much money you will have to pay if you buy.

When I create a market, wait for the "market successfully added" to appear in the console, then immediately click on the market when the pending label is removed, it takes me to a blank page. (The sidebar and navbar are still there, but nothing in the main panel.) Refreshing the page fixes this and I can visit the market normally.

Show how much profit a position has made if you were to sell at the current price in the holdings modal

There should exist a page that displays all the users account details and assets. These would include but not limited to:

• all accounts attached to the ethereum client, highlighting the primary and one used for augur
• balances (cash, reputation)
• outstanding shares/outcomes in markets
• markets authored
• recent transactions with link to transactions browser filtered for account

From https://github.com/AugurProject/augur-client/wiki/Specification:

Ballots show, at a glance, all the events a reporter needs to vote on. It shows the most useful information for reporters (particularly the highest priced outcome), and should link to the market detail page for the given event. Reporters indicate their vote for each event, then click a "cast ballot" button. The client generates a salted hash of the ballot, stores the ballot and salt locally, and broadcasts the hash to the network. The user is informed that they still need to run the client again to finish casting their ballot between the appropriate deadlines.

If a quorum has been reached and the reporting period is over, the client automatically broadcasts the users ballot and salt. When there's a use case for making that process manual, we'll add a way to disable automatic ballot broadcasting.

Voting deadlines are always clearly displayed. Reporters have half a period to submit their ballot hash. The ballot and salt must be submitted between half a period and two periods after the given voting period has ended.

From https://github.com/AugurProject/augur-client/wiki/Specification:

The holdings page displays a list of event outcomes with the number of outcome tokens held, their current price, and the current total value of the user's holdings of a given outcome. It also displays the total value of all held event outcomes. Each outcome links to its corresponding event detail page, where the user can buy and sell shares.

Users can send reputation to other accounts from the holdings page.

web3.js has switched the order of the function name and call/sendTransaction. branchContract.call().getMarkets(branchId) becomes branchContract.getMarkets.call(branchId).

https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-methods

We need a welcoming and useful home page instead of the default markets view. This might have such things are some intro text, invitation to a tour, featured/trending markets, etc.

The creation of markets is core to this app and the current modal is barely a placeholder. This modal should implement the following data collection and flow:

• prompt for text/query with hints and guidance for well-formedness
• market fee and explanation of what that is
• setting initial liquidity
• number of outcomes with types (true/false, arbitrary labels, decimal/integer range, etc.)

This modal should be a gem of the application and can even be multi-paged. It also can be slightly more heavy and rich because it doesn't suffer from any on-boarding syndrome.

Authors are motivated. Let's help them and make the experience fun and exiting!

Need to do a test run of consensus

We made too many separate stores in the first pass. We should catalog the sets of stores that components listen to, and combine the stores that are always listened to together. Beyond that criteria, there's probably some simplicity to be gained in combining more of them.

E.g. I can use both faucets, send rep, cash, etc. However creating a market never submits a transaction nor does buying/selling shares. I have 350 ether so that's not the issue.

The async getMarkets should scale better, and will provide a good example of async the React/Flux way.

Currently, we use the branch's current vote period value from the contract to determine which period's ballot to display, but you can never vote on any period except for branch (currentPeriod - 1). votePeriod is really only useful for determining whether to call dispatch.

It's clear that augur will need an alternative, CENTRALIZED data store for some of the data on market and possibly comments, etc. This would be an interim solution until decentralized solution mature. This would also be a way to reduce gas costs while augur grows up.

I'm recommending MongoDB, because it fits the bill, is very mature, fast and i'm familiar with it.

The store should accept a doc type and hash id as query and return any meta data seemed fit to supplement on-chain data.

account
(much of this will also be stored in the ethereum client's db and check there first)

• list of contacts and associated address
• profile data (blob of avatar, handle, name, etc.)

market

• longer description of the market detailsing specific rules etc.
• image blob

event

• price history of each outcome (time stamp, price, ?)

Basically, I can buy shares in a market, the transaction is definitely completing (checking log) and going through because my cash balance decreases, but the UI doesn't continue to say that I hold shares after a refresh.

I buy, tx happens, UI says I own shares, I refresh, UI doesn't say I own any shares nor does the account modal.

I'm guessing the sequential RPC calls are holding us up. Potential solutions:

• Find a way to batch RPC calls.
• Return some sort of stream so each market can be added to the UI as its calls finish.

Error above

We currently rely on Augur.js callbacks to determine the state of transactions we send. That works, but I think it'll be easier to reason about our program if we make transactions part of our application state instead of using callbacks directly to modify other application state. It'll also make it easier to show users what they're spending on transaction costs.

Each time we send a transaction, we'll pass on onSent callback that adds the transaction hash to the store along with the transaction type (e.g. the augur.js method name) and arbitrary metadata to store for display purposes, like the name of the market that's being created. We'll add a call to NetworkActions.onNewBlock to update the TransactionStore with the current status (pending, success, failure) of each transaction. Transactions that failed or succeeded will be updated with their transaction costs.

Components that depend on a particular transaction succeeding can watch the TransactionStore and use the state of the transaction there to determine what to display. A new market, for instance, would have two pending transactions. Each time we load markets, we'd check the TransactionStore for pending addMarket and addEvent transactions, and use the metadata to display a pending market in the UI. Once the transactions get updated with a non-pending status, the code will ignore those transactions and just display whatever markets have successfully been stored on-chain.

The submit hash transaction won't succeed in the second half of the voting period, so we should make it impossible so user expectations are accurate and transaction fees aren't wasted.

i mean it's the 90's already...

Sell buttons only show up if you own shares of that outcome. For elements that require Augur's web service (#6), we should just put in placeholders for now.

Buy/Sell take you to a trade screen with that keeps the same image/description header.

Purchase Shares

Yes

57%

_____ shares (X cash)

[ Buy ]

If the outcome of this question is Yes, your shares could
approach their maximum worth of Y cash.

Clicking "buy" pops up a confirmation modal.

Will Hillary Clinton win the 2016 U.S. Presidential Election?

Click confirm to purchase X shares of the **Yes** outcome for Y cash.

[ Cancel ] [ Confirm ]

Thoughts on this sketch?

Uncaught Error: Invariant Violation: Component (with keys: getDOMNode,_handleChange,props,context,state,refs,_reactInternalInstance) contains render method but is not mounted in the DOMinvariant @ augur.js:96509findDOMNode @ augur.js:95504ReactBrowserComponentMixin.getDOMNode @ augur.js:82198ReactClass.createClass.componentDidUpdate @ augur.js:86229assign.notifyAll @ augur.js:78723ON_DOM_READY_QUEUEING.close @ augur.js:91892Mixin.closeAll @ augur.js:94775Mixin.perform @ augur.js:94716Mixin.perform @ augur.js:94702assign.perform @ augur.js:92914flushBatchedUpdates @ augur.js:92994wrapper @ augur.js:91321Mixin.closeAll @ augur.js:94775Mixin.perform @ augur.js:94716ReactDefaultBatchingStrategy.batchedUpdates @ augur.js:87074batchedUpdates @ augur.js:92929ReactEventListener.dispatchEvent @ augur.js:88836

So as a market creator (or anyone involved) I want to be able to close markets:

make this call tradingPeriod = MARKETS.getTradingPeriod(market)

Then check in js if(BRANCHES.getVotePeriod(branch) > tradingPeriod)

Using both those calls if you get 1/true then a market is able to be closed.

To close the market call def closeMarket(branch, market)

The back-end (and augur.js) support buying/selling fractional shares (e.g., 2.512 shares), so adding this as a feature request for the client.

Developing Augur shouldn't require a stable geth and sane data on the chain. We also need a good foundation for UI unit tests.

When a user navigates to their ballot after the hash has been submitted, we should add a link or button to the messaging in #42 that lets the user edit their ballot and submit again.

The ballot page should have some more info about the period. My suggestion:

• Say something like Current period: {currentPeriod}
  and then below it have Reporting on: {currentPeriod - 1}

If the period on the ballots component says 1293, we're actually voting on 1292.

For instance if it's period 101 right now as defined by block.num/periodLength then we should be voting on things in period 100, which is prob. what the ballots screen should show IMO.

Submitting a report when consensus won't succeed is a waste of effort and transaction fees. We should make it impossible in the UI.

It would be ideal to leverage the shh (whisper) protocol for persistent market commenting. The channel and tagging looks promising for associating them to market ids, but It's unclear to me if the messages remain on the blockchain and are persistent.

Let's explore this and see what we can come up with.

So for reporting... to get a list of events happening in the current report period call
def makeBallot(branch, votePeriod) in expiring events --- votePeriod is (block.number/periodLength) - 1 This is a list of all events you need to report on in order.

Now make a report --- basically an array of values.
So for no no yes no yes indeterminate your array should look like:
[2**64, 2**64, 2*2**64, 2**64, 2*2**64, (3*2**64)/2]

Get (block.number/periodLength) - 1 via a call, go to makeReports and call
def checkReportValidity(branch, report:arr, votePeriod) with that vote period. Make sure to save the report securely client side.

Now call
def hashReport(report: arr, salt) using a random salt generated with some nice entropy.

You now have a report hash.

Submit this to the network with
def submitReportHash(branch, reportHash, votePeriod) using a live sendTransaction

Note: for the first half of the voting period (so the first 4 weeks you can submit this hash (and update it if you like).

Now during the second half of the vote period (the last 4 weeks) you can submit your real report

Send a transaction to def report(branch, report:arr, votePeriod, salt) and you'll have submitted a report.

As soon as a period changes (e.g. block.number/periodLength increases by 1, it's time to vote on (block.number/periodLength) - 1 again). Remember first half is hash, second is the plaintext report.

Now for something fun:
If someone tries to collude during the first half, and you can provide their salt and report and address to the network, you get their rep (because they are a cheater)!
Send a transaction to def slashRep(branch, votePeriod, salt, report:arr, reporter) to do this.

Dispatch is caught up and it just keeps spamming dispatch tx spending all my ether regardless of it already being caught up.

I think an additional piece of data would be useful in the holdings modal. When you buy/sell shares, basically take the amount your cash decreased/increased by and divide by number of shares you bought/sold and that gives you the average price per share you bought/sold at. Would be useful to have this stored in the holdings modal.

Seems you're not dividing by 2^64 I'd guess

After a market has matured and the event's outcome has been decided, remove the market from the markets/branch page.

Then, on the account holding page, show the user how much profit/loss they made on that market after it's closed. Once it has been closed (meaning the user has been paid out if they won) allow the user to click an x or something to remove that market from their holdings page.

So people will need to be able to call consensus (it has to be called multiple times to do a full round - it has many calls). So basically call def checkQuorum(branch) from the checkQuorum contract, if that returns 1/true then consensus is ready to be called.

Anyone can call consensus.

Call def dispatch(branchNumber) multiple times until eventually it returns 9 which means that that round of consensus is complete.

Title self explanatory, open console then make a market and you'll see what I mean. Lags things up quite a bit

this may take several forms (modal, form validation, etc.) but for the alpha, we should have some basic user messaging for actions that require ether (add market, sending assets, buy/sell shares, etc.)

a modal could also have help text for mining or requesting it.

Since adding a market takes ~24 seconds or so in all, I think it would be great if there was a progress bar (or some other visual indicator). Maybe you could have a checklist appear somewhere (sidebar or something?) and visually check off:

• event submitted
• event accepted
• market submitted
• market accepted

But, maybe this would emphasize the difference between events/markets too much? I dunno, just a progress bar that jumped to 25%, 50%, 75%, 100% on the 4 steps listed above would be pretty cool.

Also, suggest making the markets display auto-refresh once the market is accepted -- maybe put that in the onSuccess callback in EthereumClient.addMarket?