Setback and missed deadlineLet’s get the obvious and negative part of this update out of the way first.
We said we would have something to show by now, which didn’t materialize.
I was able to show you part of what we had done so far through the two walkthrough videos of the PeerTracks platform, which is done and functioning well.
But PeerTracks requires a stepping-stone (Troopeers) before it can launch, which is what we intended to finalize and release near the end of 1st quarter of 2016.
For those that don’t know, Troopeers
is PeerTracks, the non-music-specific aspect of it. It allows anyone that has or wants a fan base to create his token so that he may be discovered, funded, etc. Troopeers is simply an extension that of the original objective that tackles other markets such as sports, acting/movies, instagram stars, streamers, etc. The music branch of Troopeers is PeerTracks – that branch requires its own, more complex, feature set (music player, royalty splitter, etc).
As you may remember, we required internal developers rather than relying on external firms. This was our first delay. We had everything ready to go business wise, but no internal devs! We eventually did find someone highly qualified and so Troopeers was thus being built out in early 2016. Our new developer moved fast, first learning about our project, then Graphene, MUSE, etc. He picked up everything in no time and was the main dev in charge of the Troopeers web app (and finalizing PeerTracks’ MUSE integration). We were very happy with the progress. Unfortunately, a matter unrelated to PeerTracks required him to step away. This unfortunate event brought us back to square one regarding hiring of internal devs. Finding replacements and getting them up to speed would mean there was no chance in hell of achieving our objective of launching Troopeers in time.
Instead of telling you how the problem was solved, let me ride this wave of negative news with another kicker.
Graphene’s architectural shortcomingsGraphene was set up back in the day where it was thought that everyone would run their own node or download a client on their machine. The codebase still reflects that.
What we need is something that can provide an excellent UX while being scalable to millions.
Graphene’s wallet infrastructure makes it possible to host a mere few dozen wallets per virtual machine. This, of course… is not scalable to our needs.
A good solution to this is to have the wallets web based – browser side wallets.
The issue with THAT is that the JavaScript code for the browser side wallet was converted from C++ by an automatic converter making the code huge! (68 megabytes according to BitSapphire)
Loading such a large JS would be a nightmare for anyone trying to access Troopeers and PeerTracks from any phone/tablet/laptop no matter how fast your Internet connection is. Basically the code is far from optimized for this scenario, but it could be reengineered and be brought down to a more reasonable size (under 2 MG)
This is actually the exact problem BitSapphire is attempting to tackle with Moonstone. They are re-writing the JavaScript to solve this very issue.
Now that my excuses are out of the way...
We are launching a consumer-facing product in MAY!
Found amazing developers!Turns out the person that told me about BitShares, back in 2013, which I trust, is a hands-on coder. I thought he just knew everything about crypto as an early adopter. I didn’t know he was actually proficient in using the MEAN stack and Blockchains. He also has a ton of stake in BitShares and MUSE so is already highly incentivized to see this project succeed.
And so we’ve hired both him and his business partner (equally qualified!) to launch Troopeers, then PeerTracks. To top it all off, they are both located in Montréal (near me) and so I will be working with the team, hands-on, in the same physical space.
PeerTracks inc. finally has the piece that was missing in order to bring this idea to market.
Graphene workaroundLike life in general, problems usually lead to creative solutions since you are forced to look at situations from new angles. The solution we came up with is one that we have always ignored; it wasn’t even in the cards as far as we were concerned.
Phase 1 of PeerTracks (Troopeers) is hitting the market with a centralized database.
The goal is to ONRAMP people into the system with an excellent UX. The system is fast and responsive on any standard device – mobile from the get-go. It is scalable to millions and there is no crypto for the (non-techy) users to worry about. No need to educate anyone on public/private key cryptography while acquiring users. No need to have users remember a passphrase, backup keys/wallets and risk loosing everything. Nor do we need to hold any keys.
We are going full throttle with user acquisition. The community can finally have something to push and promote: An online, released product.
Every single user, from celebrities to token holding fans, and all token balances, will be snapshotted from our internal database, onto MUSE once the blockchain is ready for the heavy lifting required of it. In the meantime, everything will take place on our transparent – although temporarily centralized – database.
Stars/celebrities will be able to create their profiles and their limited edition tokens.
Fans will be able to show up and support their stars by using credit card to purchase tokens and take part in tipping and patronage.
Two-way interaction will be made possible with our weighted inbox.
Stars will be able to reward their troops with perks and giveaways.
Advertisers will be able to target specific fan bases using the token system.
Once complete, all token balances will be hardforked into MUSE. Tokens will essentially go from being an entry in our database to becoming a crypto-token on the MUSE blockchain.
Note that the current MUSE blockchain will still be operational during these stepping stone times, but it will serve only as a way to own and trade stake in the future, improved version. I should also mention that we now have a Graphene expert on board which monitors the MUSE chain and can update it whenever need be.
Advantages to the centralized stepping stone- Hit the market immediately – in May
- This is the speedboat approach for user acquisition
- Great UX
- Fast & responsive
- Scalable
- No crypto keys to manage
- No chargebacks (they can happen but we can revoke token ownership in case of chargeback) a major concern when dealing with credit cards
- Our internal database is transparent
- Token balances/ownership on our internal database is snapshotable
- MUSE’s market cap will still grow to reflect the success of the project
- Faster to develop
- Gives time to CNX, BitSapphire and crypto world in general to develop better blockchain tech – gives us more and better options when we upgrade MUSE
- Gives time to the music-industry to figure out the Minimal Viable Data set Benji Rogers is pushing for
- We can launch a proto-PeerTracks, with a music metadatabase, the royalty payment splitter and artist tokens – all of which will be snapshotted to MUSE
- Our PR firm, marketing experts and other resources can begin doing what they do best
The takeaway is that the objective is the exact same as always – a decentralized network for music metadata, royalty payments and tokens. We merely found a way to make users acquisition seamless. Release will be faster and by phases. We no longer need to have everything blockchain be perfect before we start getting people on board and test out the market’s reaction.
TL;DRWe have new devs
We are Launching Troopeers in MAY
Its database will be centralized (temporarily)
MUSE will be able to rise in value sooner rather than later
Our internal database will be snapshotted to MUSE 2.0
Topic: Early 2nd quarter 2016 update (Read 17056 times)
