GLBSE - request for next features

[Nefario]

On a related note, I'm going to be separating charts and the API (for chart information, but not for trades) into a separate application, moving it to a another server, I'm thinking of OpenSourcing this as well.

Opinions on the opensourcing part?

[1713546131]

1713546131

[1713546131]

1713546131

[1713546131]

1713546131

[stochastic]

On a related note, I'm going to be separating charts and the API (for chart information, but not for trades) into a separate application, moving it to a another server, I'm thinking of OpenSourcing this as well.

Opinions on the opensourcing part?

I think you should add dividend payments to its own twitter feed like the current trade history reporting.  Right now the only way to get the latest trade is to call the api for that security and it pulls all the dividend that security  has paid.

[EskimoBob]

Please add "Last trade price" to https://glbse.com/portfolio > Assets table.
And please add:
Total market value too.
Next div date, last div paid (what received)

This will eliminate multiple unnecessary clicks and page loads. As mentioned before, one needs to click way too many pages to get any idea whats really going on.

BTW, after you limited API requests to 10 per minute, I can not update my googledocs table. I do not refresh my table more than few times a day but I have more than 10 different securities in my portfolio. 

[Nefario]

Please add "Last trade price" to https://glbse.com/portfolio > Assets table.
And please add:
Total market value too.
Next div date, last div paid (what received)

This will eliminate multiple unnecessary clicks and page loads. As mentioned before, one needs to click way too many pages to get any idea whats really going on.

BTW, after you limited API requests to 10 per minute, I can not update my googledocs table. I do not refresh my table more than few times a day but I have more than 10 different securities in my portfolio. 

When the new server arrives then I'll increase the limit by 2x or something along those lines, in the meantime other changes on the way.

Sto. a twitter feed for dividends will be added also.

[piotr_n]

I don't know if you've seen it, but the asset view page is suffering from this new Error 503 feature.
Sometimes the Buy/Sell form just doesn't appear - reload is needed and a bit of luck..
That is definitely not nice.

Though, the new speed is nice - like in the good old times, when there were no bots yet.

[Nefario]

When the new server arrives then I'll increase the limit by 2x or something along those lines, in the meantime other changes on the way.

Sto. a twitter feed for dividends will be added also.

Why not generate a static page for the API every time a change occurs? I've done this on sites that needed fresh results without bogging down the database. That way you're turning potentially hundreds of DB queries into one DB query & hundreds of static html requests.

Yeah someone mentioned this in IRC (you?) for the most part this is certainly the route that we'll be taking.

[cytokine]

First off, thank you Nefario for your wonderful creation! The amount of productivity that the GLBSE has enabled is astounding and growing every day.

Here are my particular pain points:

(1) Dividend data API needs to have a way to specify a date range. I have local copies of this data, so each day I only need the "most recent" dividend payments from the last date I ran the update. Otherwise, it takes a long time to update all of my dividend data.

(2) Twitter for trades is OK for now, but won't scale in the future. My main worry is that eventually we will have too many trades in a single 24-hour period, and then when I go to update my trade database I will miss some of the trades (because Twitter only lets you go back so many tweets...)

That's really all of the essential stuff. This next one would be nice to have, but it's not critical by any means:

(3) The last-trade price listed next to each security in the portfolio, along with last-trade price * # shares to see the value of each holding. And then a total value for the entire portfolio.

[EskimoBob]

When the new server arrives then I'll increase the limit by 2x or something along those lines, in the meantime other changes on the way.

Sto. a twitter feed for dividends will be added also.

Why not generate a static page for the API every time a change occurs? I've done this on sites that needed fresh results without bogging down the database. That way you're turning potentially hundreds of DB queries into one DB query & hundreds of static html requests.

Yeah someone mentioned this in IRC (you?) for the most part this is certainly the route that we'll be taking.

I did. About twice This will be huge win and your db load will drop dramatically.   

[ChrisKoss]

That's really all of the essential stuff. This next one would be nice to have, but it's not critical by any means:

(3) The last-trade price listed next to each security in the portfolio, along with last-trade price * # shares to see the value of each holding. And then a total value for the entire portfolio.

+1

[OgNasty]

That's really all of the essential stuff. This next one would be nice to have, but it's not critical by any means:

(3) The last-trade price listed next to each security in the portfolio, along with last-trade price * # shares to see the value of each holding. And then a total value for the entire portfolio.

+1

This is definitely overdue.

Nefario, would it be possible to include the total dividends paid by an asset in the API?

[dust]

Placing an order through the API should return the order id.

[Lucidize]

The "Bids & Asks" graphs are a waste of space and bandwidth because some idiot puts 100000 @ 0.00000001 on every asset.
I would like to be able to view them normally as I'm sure others would too, but if it's not possible can it just be removed?

[btharper]

The "Bids & Asks" graphs are a waste of space and bandwidth because some idiot puts 100000 @ 0.00000001 on every asset.
I would like to be able to view them normally as I'm sure others would too, but if it's not possible can it just be removed?

+1 for this. Maybe cut things off at +- 10% of the bid/ask gaps? Highest bid is 0.9, cut the graph off at 0.81. Even a larger percentage (50%) would cut off the garbage bids that skew the scale of the graph

[Sukrim]

No need to cut it off, just disply an aggregated amount, like the depth charts on bitcoincharts.com.

[btharper]

No need to cut it off, just disply an aggregated amount, like the depth charts on bitcoincharts.com.

Unfortunately you probably would need to cut them off to avoid disrupting the scale. You'll have one order for one satoshi per share for 100000 shares (even on bonds that only produce a tenth as many shares). So the X scale is blown out by having bids at {0.00000001, 0.9, 0.901, 0.98, 1.1, etc} Then you break the Y scale by having a bid for 100,000 shares {100,000, 5, 10, 1, 100}.

Having an aggregated amount is just a different view of the same data, and you'd just end up with a huge spike on the far end of the graph and then a very small line that goes from two pixels wide down to one.

Hell, I'd go one step further and suggest that these bids have so little business being on the site that they not be allowed at all. Anything less than 0.1% of the current highest bid on a security with at least 5 bids is rejected (A security with fewer than five bids may not reflect accurate prices, this exception may not be required however). This would still allow a bid of 0.001 BTC on a security trading for 1 BTC normally, which is still ridiculously low.

[Sukrim]

100000 shares at 1 Satoshi are equal to 1 share at 0.01 BTC - that would not impact the graph very much... please look again at the charts at bitcoincharts.com - the volume is measured in BTC, not shares (which would be a quite weird measure after all). I am seriously against disallowing any kind of bid, especially now that the UI is denominated in BTC (as opposed to the command line client on GLBSE 1.0 in Satoshis). There maybe might be a warning/confirmation popup, if you bid/ask much too low or too high but disallowing such stuff is just not the right thing to do imho.

[btharper]

100000 shares at 1 Satoshi are equal to 1 share at 0.01 BTC - that would not impact the graph very much... please look again at the charts at bitcoincharts.com - the volume is measured in BTC, not shares (which would be a quite weird measure after all). I am seriously against disallowing any kind of bid, especially now that the UI is denominated in BTC (as opposed to the command line client on GLBSE 1.0 in Satoshis). There maybe might be a warning/confirmation popup, if you bid/ask much too low or too high but disallowing such stuff is just not the right thing to do imho.

Ahh, my apologies, I was thinking of the current charts just with a different display type. Those charts are also clipped themselves; looking at the mtGoxUSD chart, the range only goes from $8-$15, excluding small orders (and even ones that were active a few months ago) and asks at the higher end (I'd personally love to sell my coins for $25 a piece, but that chart won't even show it).

A chart showing the shares (cumulative or otherwise) is still of interest to me, but a chart by value would make it much easier to see what my current holdings are worth if I had to sell off immediately (I think either chart would show this information, it's just easier). The only real difference is plotting price (on the X axis) against either shares or price times shares.

The other thing to consider about the bitcoincharts graph is that you're trading "shares" of BTC on that graph, so it's only natural to show cumulative results in BTC.

Disallowing orders may not be the best way to handle it you're right, but I do see it as disruptive to say the least right now.

The current API is also in satoshis, my understanding is that it's much more machine readable where the UI BTC prices are easier for humans to read (or at least for me personally).

[Francesco]

Hell, I'd go one step further and suggest that these bids have so little business being on the site that they not be allowed at all. Anything less than 0.1% of the current highest bid on a security with at least 5 bids is rejected (A security with fewer than five bids may not reflect accurate prices, this exception may not be required however). This would still allow a bid of 0.001 BTC on a security trading for 1 BTC normally, which is still ridiculously low.

I'd also limit the number of digits allowed in a bid. Hell, if no one is prepared to bet really more than me, why should anyone, arrived later, be allowed to be before me for the exact same price -just one shatoshi more? So that if I want to be first, I have to cancel my previous, and make a new order again (which process is, I remark, nowhere as fast as it ought to be).
It's basically... a penny auction; not in BTC (since price goes nowhere really) but in time.
If I have a bid at 0.12, either you offer at least 0.121 or you're after me, since you came later and do not really offer more. Seems fair to me.

Also, unrelated: can I manage the transfer feature via API? And, can I see who sent me something? [Of course I should have looked to the CSV history] It seems both no, but this features would be quite useful; if they aren't there yet, my vote to implement them.

[odolvlobo]

I don't know if this has already been requested, but please please please add a confirmation dialog to trades. There are too many ways to make mistakes when entering quantity and price, especially when both the enter and tab keys generally don't do what you want.

[odolvlobo]

BUG!!!! If there is an entry at a particular price and I make a trade at the same price, it puts my order in before the order that was already there.