+5% I vote for you!

Yes!

(This is an example of why this new system is great.  It results in Bitshares being built faster).

Quote from: sschechter on October 31, 2014, 04:56:05 PM
I've been waiting for this....will vote  +5%

I know Cass and team are working on the new market UI also.  Is there overlap?

cass is working on a UI for the client .. a full node so to say .. not really a web/javascript implementation .. but something that build ontop of the full-node client .. just like it is done currently .. all the network/blockchain stuff is done by the bitshares_client .. while the OP proposes to do the transactions stuff in the browser with javascript .. and having the signed tx sent over the the backend which is connected to the network ..

You have my vote as well.

I've been waiting for this....will vote  +5%

I know Cass and team are working on the new market UI also.  Is there overlap?

I would vote for this.  +5%

Thanks for the votes of confidence, guys - and to think I was considering moving onto something different! :)

Now to get the bitshares client actually built on centos so I can run a delegate - fun fun fun.

Quote from: biophil on October 31, 2014, 12:19:16 PM

Quote from: svk on October 31, 2014, 11:05:17 AM

Quote from: xeroc on October 31, 2014, 10:58:16 AM
I think you will run into problems when parsing TITAN transactions ... as the private key is in the browser .. and you need to scan ALL transactions if they are intended for you ..

Either you focus on the 'mail' protocol which will be used to announce transactions for the lightweight client soon .. or you will only be able to work with non-TITAN transactions .. either way .. the project can lead to a killer-app!! +5%

Mail will be used for this?? How did you learn that?

Can't speak for xeroc, but there was a conversation on the forum between bytemaster and drltc a while back when bytemaster mentioned this is what mail is about. Not necessarily the same thing as KeyMail, afaik.

Mail will be a key part of light weight transactions and basically make the payer to send a encrypted mail to the mailserver of the receiver (defined in the public data field) .. that mail will contain the transaction id .. such that the recevier does not need to scan the WHOLE blockchain .. but only for that transaction ..

Quote from: bytemaster on October 31, 2014, 12:16:08 PM
We are going to provide a way to do this without Titan.

+100% :)

Quote from: svk on October 31, 2014, 11:05:17 AM

Quote from: xeroc on October 31, 2014, 10:58:16 AM
I think you will run into problems when parsing TITAN transactions ... as the private key is in the browser .. and you need to scan ALL transactions if they are intended for you ..

Either you focus on the 'mail' protocol which will be used to announce transactions for the lightweight client soon .. or you will only be able to work with non-TITAN transactions .. either way .. the project can lead to a killer-app!! +5%

Mail will be used for this?? How did you learn that?

Can't speak for xeroc, but there was a conversation on the forum between bytemaster and drltc a while back when bytemaster mentioned this is what mail is about. Not necessarily the same thing as KeyMail, afaik.

We are going to provide a way to do this without Titan. 

Got my vote  +5%

You sir have my vote, good luck with your work.

Quote from: xeroc on October 31, 2014, 10:58:16 AM
I think you will run into problems when parsing TITAN transactions ... as the private key is in the browser .. and you need to scan ALL transactions if they are intended for you ..

Either you focus on the 'mail' protocol which will be used to announce transactions for the lightweight client soon .. or you will only be able to work with non-TITAN transactions .. either way .. the project can lead to a killer-app!! +5%

These are interesting points - I have to admit, I did wonder whether TITAN would present issues with this idea. I will take a look at the mail protocol, thanks for pointing me in the right direction :)

You have my support  +5%