[ANN] Moonstone.io development and crowdfunder diary

[xeroc]

I'm sure you are aware of jcalfee's work on Bitshares-JS, do you intend to build on that work at all?

We used it as a good starting point. jcalfee also helped us with some explanations from time to time via skype.

Yeha .. I like that guy alot .. and his code is crystal clear to read ...
Most of the python code i wrote for my cold storage solution (https://github.com/xeroc/python-bitsharestools/blob/master/bitsharestools/transactions.py) was no brainer having jcalfee's code as a base

[fuzzy]

You can't please everyone.

This man is wise ^

[bitsapphire]

I'm sure you are aware of jcalfee's work on Bitshares-JS, do you intend to build on that work at all?

We used it as a good starting point. jcalfee also helped us with some explanations from time to time via skype.

Can we do something like this through Bitshares? https://www.jumpstartfund.com

Yes

We think with Flow Based Programming we could do some even better stuff in the future!

[luckybit]

4. Moonstone is not decentralized. It accesses a full client server which however cannot forge any signatures as the server holds no private keys.

Do you intend to eventually allow the client to poll multiple independent servers in future versions so that any one server cannot lie to the client without getting caught?

Yes. We intend to add this possibility down the line (V2 or 3).

8. If the crowdfunder is not successful, meaning we don't reach our goal of 130,000 USD worth of BTC within the 30 day window, we will proceed to release the frontend under the GPL3 license without releasing the backend. The delegate buyback commences nonetheless and we will buyback the tokens in the same manner. No BTC can be taken back.

That seems like such a shame. What if the amount raised in 30 days was 120,000 USD? I'm sure people donating would rather see a cut in the 15% interest and get the MIT license rather than get nothing at all. If the first few months of delegate pay is sold to cover the deficit with interest, the amount of BTS estimated to be collected over the remaining months in the 30 month window can be used to calculate the new (lower) buyback rate.

Yes that would be a shame. We are pretty confident though that we will reach our goal. The community has been responding very positively.
We are aiming to create a market solution for the creation of public goods. Combing a pure charity and for-profit model would in our opinion evolve the system into an unstable equilibrium. We have already plans how to potentially solve this dilemma for future Bitshares related projects but that would require our module based approach to be final and tested. Something which will take several more months.

One more thing. If we reach our fundraising goal we also pledge that V2 and V3 of the wallet will also be open source MIT licensed, the only potential exception being the ID verification module.

I'm curious regarding how the module system works. I expect to be able to compile (and audit) the client code myself for security reasons. So would these modules be plugins (some of which can be proprietary and pre-compiled) that the open source client can use? If so I would want to make sure that these plugins are in their own secure process sandbox because otherwise you would allow unknown proprietary code to have memory access to the client which they could use to steal private keys.

If you'd like to read up on it here is the official FBP page. We are using specifically noflo. V1 won't be FBP though but V2 and onward will be. We are currently switching the entire team to FBP as by our calculations it will increase our productivity several fold. You can read up on what new technology future we are actively preparing for here.
The ID verification module would not be client side, hence no memory access to your local machine.

You can't please everyone.

Agreed.

Can we do something like this through Bitshares? https://www.jumpstartfund.com

[svk]

I'm still curious about the relationship of the Moonstone wallet to Bitshares Music and Peertracks. Apparently it will also be used for that blockchain, so are you essentially asking BTS holders to fund the development of the Music wallet? How come Peertracks/cob aren't funding it?

Also, is this the same wallet you showed us last year, not sure when, in September maybe?

What is the current status of the development, do you have a working implementation or are we only seeing mockups?

Very good question.
Peertracks is committed to using Moonstone's codebase. Peertracks will contribute to this fundraiser as to offset some of the crowdfunder cost. The specific interface integration needed for Peertracks will be developed later for Peertracks and is not part of this fundraiser. Our plan for Moonstone is for it to connect to multiple blockchains from the same interface and be able to trade between all blockchains' tokens. This will include potentially all DPOS forks and Bitcoin, potentially Ethereum too (in the long run).

The wallet design we showed in September was the first design iteration we had finished. I think this would be a good time to mention what the development/iteration process has been like so far:

• Initial design concepts based on Google's newly released Material Design guidelines. Frontend work on the Angular app with Famo.us. Famo.us made it possible to have a buttery smooth UI for browsers as well as on the phone. The premise is "build it once, it works on all devices like a native app". It worked really nicely but Famo.us was at version 0.2 back then and once they upgraded up to 0.4 we had to abandon our plans as it broke too many things. In this iteration we still used the current wallet RPC interface.
• This is when we started our second iteration of the design with complete overhaul. We put on a second designer and things went a lot faster. We switched from Famo.us to native Angular Material Design frameworks which also helped us a lot. The drawback is of course that for the mobile wallet we'll need to redo it again. We still used the current wallet RPC interface, though now server side as we changed plans for Moonstone to become a light wallet. This is also when we started doing extensive user testing with the half baked interface. We discovered that there would be a 80% drop in likelihood for anybody to use our wallet for every 2 minutes of waiting/loading time (this would include blockchain syncing if this was a full client).
• After wrangling with for over a month with the BithShares RPC interface and trying to get it to be a scalable backend for the light wallet, we decided that the whole current wallet architecture (including the deserializer) was simply not intended for large scale deployment. It was rather build with the ideological backdrop of everybody downloading the whole blockchain. This was when we made the announcements on the forum ans started working on our own RPC interface and deserializer. Right after making the forum announcements we got the client-side universal transaction builder working, though there are still bugs that need to be worked out. We are currently working on the RPC interface/deserializer and the market interface. These two parts are also our two main milestones for the 0.9 release. Once fully tested we will release 1.0 for general use.

What you saw in the demo video all works and is real, however the universal transaction builder needs work and testing as well as the RPC interface/deserializer. The current demo still runs on the current wallet RPC.

It is important to note that we think Moonstone can spur the Startup/project econsystem around BitShares by providing a similar architecture to Bitpay's Bitcore Wallet Suite. That is our intention for our RPC interface. If it works out anything like Bitcore, you'll see many startups use it as the go-to BitShares/DPOS wrapper. Most Bitcoin startups we have worked with have used at least parts of Bitcore, which I think says a lot.

Excellent answers, thank you.

I too have my doubts as to the scalability of the client as a backend for multiple online clients, even for Bitsharesblocks I needed to build another layer on top of it in order to mitigate some performance issues.

I'm sure you are aware of jcalfee's work on Bitshares-JS, do you intend to build on that work at all?

[bitsapphire]

I'm still curious about the relationship of the Moonstone wallet to Bitshares Music and Peertracks. Apparently it will also be used for that blockchain, so are you essentially asking BTS holders to fund the development of the Music wallet? How come Peertracks/cob aren't funding it?

Also, is this the same wallet you showed us last year, not sure when, in September maybe?

What is the current status of the development, do you have a working implementation or are we only seeing mockups?

Very good question.
Peertracks is committed to using Moonstone's codebase. Peertracks will contribute to this fundraiser as to offset some of the crowdfunder cost. The specific interface integration needed for Peertracks will be developed later for Peertracks and is not part of this fundraiser. Our plan for Moonstone is for it to connect to multiple blockchains from the same interface and be able to trade between all blockchains' tokens. This will include potentially all DPOS forks and Bitcoin, potentially Ethereum too (in the long run).

The wallet design we showed in September was the first design iteration we had finished. I think this would be a good time to mention what the development/iteration process has been like so far:

• Initial design concepts based on Google's newly released Material Design guidelines. Frontend work on the Angular app with Famo.us. Famo.us made it possible to have a buttery smooth UI for browsers as well as on the phone. The premise is "build it once, it works on all devices like a native app". It worked really nicely but Famo.us was at version 0.2 back then and once they upgraded up to 0.4 we had to abandon our plans as it broke too many things. In this iteration we still used the current wallet RPC interface.
• This is when we started our second iteration of the design with complete overhaul. We put on a second designer and things went a lot faster. We switched from Famo.us to native Angular Material Design frameworks which also helped us a lot. The drawback is of course that for the mobile wallet we'll need to redo it again. We still used the current wallet RPC interface, though now server side as we changed plans for Moonstone to become a light wallet. This is also when we started doing extensive user testing with the half baked interface. We discovered that there would be a 80% drop in likelihood for anybody to use our wallet for every 2 minutes of waiting/loading time (this would include blockchain syncing if this was a full client).
• After wrangling with for over a month with the BithShares RPC interface and trying to get it to be a scalable backend for the light wallet, we decided that the whole current wallet architecture (including the deserializer) was simply not intended for large scale deployment. It was rather build with the ideological backdrop of everybody downloading the whole blockchain. This was when we made the announcements on the forum ans started working on our own RPC interface and deserializer. Right after making the forum announcements we got the client-side universal transaction builder working, though there are still bugs that need to be worked out. We are currently working on the RPC interface/deserializer and the market interface. These two parts are also our two main milestones for the 0.9 release. Once fully tested we will release 1.0 for general use.

What you saw in the demo video all works and is real, however the universal transaction builder needs work and testing as well as the RPC interface/deserializer. The current demo still runs on the current wallet RPC.

It is important to note that we think Moonstone can spur the Startup/project econsystem around BitShares by providing a similar architecture to Bitpay's Bitcore Wallet Suite. That is our intention for our RPC interface. If it works out anything like Bitcore, you'll see many startups use it as the go-to BitShares/DPOS wrapper. Most Bitcoin startups we have worked with have used at least parts of Bitcore, which I think says a lot.

[svk]

I'm still curious about the relationship of the Moonstone wallet to Bitshares Music and Peertracks. Apparently it will also be used for that blockchain, so are you essentially asking BTS holders to fund the development of the Music wallet? How come Peertracks/cob aren't funding it?

Also, is this the same wallet you showed us last year, not sure when, in September maybe?

What is the current status of the development, do you have a working implementation or are we only seeing mockups?

[carpet ride]

You can't please everyone.

Agreed.

I am already used to the bits-of-apps-for-hire's arrogance, and so I am not the tiniest bit surprised that he is not trying to please anybody but himself. So, this is not an attempt to change his mind, it is more of an explanation that he fully realizes what he is doing and does it this way only to serve his own interest.

So, if he believed that selling such amount of BTS would not kick the price of BTS way down, he would have taken BTS and sold them himself. But why do it? This would mean accepting BTS at current  price and suffering the loss when he himself kicks the price down by selling those BTS. It is much better for him to accept the BTC (and valuate them at equivalent BTS value) at a point when somebody  has sold those BTS (for BTC) and by doing so has moved the price of BTS down.... In other words he very well knows what this 'funding' will do to the BTS price and he is doing it in a way he does not suffer from the consequences of his actions....

If it gets funded and is later successful, the moonstone project ends up being good for all bts holders. Those who are worried about what it will do to the price in the short run seem not to be very bullish on some combination of moonstone/bts projects in the long run.  I personally don't think it's worth worrying about what the crowd funder will "do to the price" because I see moonstone as a harbinger of long run value for bts. Further, we'd be worse off if moonstone didn't reach their fundraising goal just because of the cost of doing it in bts.


Sent from my iPhone using Tapatalk

[zerosum]

You can't please everyone.

Agreed.

I am already used to the bits-of-app-for-hire's arrogance, and so I am not the tiniest bit surprised that he is not trying to please anybody but himself. So, this is not an attempt to change his mind, it is more of an explanation that he fully realizes what he is doing and does it this way only to serve his own interest.

So, if he believed that selling such amount of BTS would not kick the price of BTS way down, he would have taken BTS and sold them himself. But why do it? This would mean accepting BTS at current  price and suffering the loss when he himself kicks the price down by selling those BTS. It is much better for him to accept the BTC (and valuate them at equivalent BTS value) at a point when somebody  has sold those BTS (for BTC) and by doing so has moved the price of BTS down.... In other words he very well knows what this 'funding' will do to the BTS price and he is doing it in a way he does not suffer from the consequences of his actions....

[bitsapphire]

4. Moonstone is not decentralized. It accesses a full client server which however cannot forge any signatures as the server holds no private keys.

Do you intend to eventually allow the client to poll multiple independent servers in future versions so that any one server cannot lie to the client without getting caught?

Yes. We intend to add this possibility down the line (V2 or 3).

8. If the crowdfunder is not successful, meaning we don't reach our goal of 130,000 USD worth of BTC within the 30 day window, we will proceed to release the frontend under the GPL3 license without releasing the backend. The delegate buyback commences nonetheless and we will buyback the tokens in the same manner. No BTC can be taken back.

That seems like such a shame. What if the amount raised in 30 days was 120,000 USD? I'm sure people donating would rather see a cut in the 15% interest and get the MIT license rather than get nothing at all. If the first few months of delegate pay is sold to cover the deficit with interest, the amount of BTS estimated to be collected over the remaining months in the 30 month window can be used to calculate the new (lower) buyback rate.

Yes that would be a shame. We are pretty confident though that we will reach our goal. The community has been responding very positively.
We are aiming to create a market solution for the creation of public goods. Combing a pure charity and for-profit model would in our opinion evolve the system into an unstable equilibrium. We have already plans how to potentially solve this dilemma for future Bitshares related projects but that would require our module based approach to be final and tested. Something which will take several more months.

One more thing. If we reach our fundraising goal we also pledge that V2 and V3 of the wallet will also be open source MIT licensed, the only potential exception being the ID verification module.

I'm curious regarding how the module system works. I expect to be able to compile (and audit) the client code myself for security reasons. So would these modules be plugins (some of which can be proprietary and pre-compiled) that the open source client can use? If so I would want to make sure that these plugins are in their own secure process sandbox because otherwise you would allow unknown proprietary code to have memory access to the client which they could use to steal private keys.

If you'd like to read up on it here is the official FBP page. We are using specifically noflo. V1 won't be FBP though but V2 and onward will be. We are currently switching the entire team to FBP as by our calculations it will increase our productivity several fold. You can read up on what new technology future we are actively preparing for here.
The ID verification module would not be client side, hence no memory access to your local machine.

You can't please everyone.

Agreed.

[Chronos]

You can't please everyone.

[yellowecho]

But you will make the hard core BTS believers sell their BTS (like the current sell off by what seems like everybody else is somehow not big enough), so they can provide you with precious BTC...before diluting the shares (with your scores of delegates) for everyone to pay the investors back...

This is what I was thinking as well.  I would consider donating bitUSD or bitEUR but I'm not selling BTS for BTC to donate.

[zerosum]

Ohh  a real good one bits-app-hire!

Well done!

Not only you will not support the Bitshares ecosystem by using its products (bitAssets) - A giant red flag, as it speaks volumes about you not believing in the product yourself.

But you will make the hard core BTS believers sell their BTS (like the current sell off by what seems like everybody else is somehow not big enough), so they can provide you with precious BTC...before diluting the shares (with your scores of delegates) for everyone to pay the investors back...

I was thinking of starting to load up on BTS at 2K satoshi... now I can relax and load for even cheaper price in the not so distant future... 1.5K? maybe not a dream anymore.

[arhag]

4. Moonstone is not decentralized. It accesses a full client server which however cannot forge any signatures as the server holds no private keys.

Do you intend to eventually allow the client to poll multiple independent servers in future versions so that any one server cannot lie to the client without getting caught?

8. If the crowdfunder is not successful, meaning we don't reach our goal of 130,000 USD worth of BTC within the 30 day window, we will proceed to release the frontend under the GPL3 license without releasing the backend. The delegate buyback commences nonetheless and we will buyback the tokens in the same manner. No BTC can be taken back.

That seems like such a shame. What if the amount raised in 30 days was 120,000 USD? I'm sure people donating would rather see a cut in the 15% interest and get the MIT license rather than get nothing at all. If the first few months of delegate pay is sold to cover the deficit with interest, the amount of BTS estimated to be collected over the remaining months in the 30 month window can be used to calculate the new (lower) buyback rate.

One more thing. If we reach our fundraising goal we also pledge that V2 and V3 of the wallet will also be open source MIT licensed, the only potential exception being the ID verification module.

I'm curious regarding how the module system works. I expect to be able to compile (and audit) the client code myself for security reasons. So would these modules be plugins (some of which can be proprietary and pre-compiled) that the open source client can use? If so I would want to make sure that these plugins are in their own secure process sandbox because otherwise you would allow unknown proprietary code to have memory access to the client which they could use to steal private keys.

[bitsapphire]

Hi guys,

This is the fundraiser interface. Pretty simple and straight forward. You'll be able to generate a private/public key pair for your Moonstone tokens even if you currently have no BitShares wallet. You'll be able to import the keypair into your Moonstone wallet similar to how you can import your Bitcoin keypair to your current wallet.





If you have any questions let us know!