Interested.

Quote from: bytemaster on February 13, 2014, 02:20:08 AM

The money we get from the bounties will be used to set-up servers in a private bunker in the Swiss alps.

That's so 007. 8)

Quote from: domsch on February 13, 2014, 01:52:32 PM
servers in a private bunker in the Swiss alps.

Too cool.  8)

Quote from: alt on February 13, 2014, 04:47:48 AM
the Identification authentication should based on keyhotee?

Something we should definitely work on. But as Dan had mentioned, we are trying to build up an MVP that is fully functional and operational for the Bitshares launch. But in our continuous development cycle, we will definitely include this.

Quote from: bytemaster on February 13, 2014, 02:20:08 AM
Requirements:

1) All private keys are managed on the browser side, the server never has unencrypted access to the keys.
2) Should support the full range of actions possible from the command line client: buy, sell, short, cover, transfer
3) Should display the latest market data from the blockchain

Notes have been taken care of.

We intend to create a one-stop solution and work on this bounty and the block explorer. So in the end, we will be the Blockchain.info for Bitshares.

The money we get from the bounties will be used to set-up servers in a private bunker in the Swiss alps. Will keep the community up to date with our progress!

Quote from: bytemaster on February 13, 2014, 04:54:07 AM

Quote from: alt on February 13, 2014, 04:47:48 AM
the Identification authentication should based on keyhotee?

Ideally yes, but not required given the timelines.

I wish you can add this to the requirement.
Identification authentication with keyhotee should be pushed on. 
this can be used in many projects, even this forum.
It will be very exciting to see this happen  :D

Quote from: alt on February 13, 2014, 04:47:48 AM
the Identification authentication should based on keyhotee?

Ideally yes, but not required given the timelines.

the Identification authentication should based on keyhotee?

Requirements:

1) All private keys are managed on the browser side, the server never has unencrypted access to the keys.
2) Should support the full range of actions possible from the command line client: buy, sell, short, cover, transfer
3) Should display the latest market data from the blockchain

Quote from: domsch on February 13, 2014, 02:14:25 AM
As had been discussed with Daniel, we are going to work on the Web-Wallet bounty and the Block Explorer.

Waiting for Dan to respond so we can agree on the terms of our agreement.

As no one has started any work on this, I am going to give domsch the opportunity to have exclusive rights to this bounty.  I will work to establish the details here and welcome feedback from the community.

As had been discussed with Daniel, we are going to work on the Web-Wallet bounty and the Block Explorer.

Waiting for Dan to respond so we can agree on the terms of our agreement.

I am thinking a browser based wallet would interact with the block explorer bounty for querying the blockchain and/or submitting transactions to the blockchain.   It would effectively implement what my command-line bts wallet does only instead of posting transactions via my binary protocol it would use websockets and JSON.  It also would not verify transactions or store the blockchain, instead it would simply trust the blockchain explorer provider to provide accurate representation of the transaction history.

The goal of this bounty is to make it easy for EVERYONE to get a wallet without having to install anything.

I think it should either be completely independent of the local bitsharesd instance because it makes no sense to visit/login to a site if you can just fire up your local software. Another way is to have bitsharesd act like a webserver which can be reached

I think there are a few options here and I'm willing to work on any of these

• Option 1: Incorporate bitsharesd rpc api and let the site just handle the communication and calls between you and your local instance. Trade updates can be either rpc'ed from the client or at a centralized point and pushed to the clients
• option 2: Same concept but instead of a centralized platform let the user download a ready-to-deploy instance of the platform which he can hosts himself somewhere. Maybe it can be added to option 1, it's platform in depended since it can all be done in javascript and some static html pages

[edit] I'm sleeping over the slick option 3, be back tomorrow with a detailed implementation suggestions [/edit]
[/list]

I am interested in this.

After the wallet website is made, who would have to control it for the bounty to be paid? Would it be run by Invictus?

Also, if I were to get it running in a month, would that still be before the Bitshares genesis block?

i will fork this and try it here https://github.com/sowbug/happynine