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.