• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

August 2016 Development Update

eduffield

Core Developer
Hello Everyone!

I wanted to take some time to update the community about the state of the project and our current work. As you likely know, I recently returned from the d10e conference, where I met a number of volunteers and enthusiasts from the community. We also established many new industry connections. Conferences are incredibly useful, and they remind us that the world has not been exposed to enough information about Dash for it to reach more than a small subset of people even within a community like d10e. Nine of ten people I personally spoke to were completely unaware of what we’re doing, but as they learned about it most became incredibly excited to hear something like this was being created. Dash-only features like self-governance, self-funding, decentralized api access, interest bearing accounts and masternodes were the features these investors were most excited about.

After returning from the conference, we’re quickly picking up where we left off on 12.1. This is a critical phase of development, far more than at any point we’ve been in the past. This is the phase where we need to anticipate as many use cases as possible for the evolution software, since providing new functionality at a later stage will be more complex. Therefore, this phase is arguably more important than it would be in a centralized company, as we have seen from other projects in the space, due to the complexity of altering decentralized systems after they are in the wild.

There are currently two separate teams developing the next version of Dash. These are the Evolution team, and dash-core. The Evolution team is tasked with creating a simple user interface to provide a secure, fun, and easy user experience. While this sounds simple, it’s nothing of the sort. The team is building three separate wallets for different audiences. These are going to be the personal-client, merchant-client, and operator-client. The personal-client provides the most simple experience, allowing end-users to engage in social commerce with friends and in transactions with merchants who list their apps and services within a decentralized marketplace in Evolution. The merchant-client will enable the merchants to manage their product and service listings, customer payments, and subscriptions in Evolution. The operator-client enables Masternode operators, moderators, and other incentivized roles to access their functions from a simple client.

The team is also building the decentralized REST API to be hosted on the Masternode network and a set of SDKs for major platforms. Together, these capabilities will enable merchants to quickly and easily integrate decentralized Dash transactions into any website or app, and without the need to host a Dash node of their own. Integrating Dash into a website or app will be as simple as integrating a few lines of code, similar to what payment gateway providers like Braintree and Stripe provide for online merchants. This will significantly reduce the barriers to digital currency adoption for online merchants, allowing them to integrate Dash within hours and without the need for third-party services, fees, or infrastructure.

On the dash-core side, the team has been working on general usability/stability of 12.1. We are also integrating a basic version of dashdrive into the system. Dashdrive is the storage mechanism that sentinel+dashd use to store information on the network. At this point it is in a basic state that allows for objects to be created and stored as they will in the future. However the current storage capacity is quite small presently. For now, we will only be storing governance system data, mirroring the system setup for budgets from 12.0.

After the release of 12.1, utilizing this new technology to build our budgets, we will begin adding additional required pieces of functionality to integrate the two sides of the project. This involves beginning to use dashdrive as it was intended, as a storage mechanism for user data. New functionalities such as creation of users, groups, accounts and the ability to pay-to-url will be next on the development roadmap.

12.1 is also going to be something of a “pre-alpha” for Evolution. This means it will be able to store some of the basic data structures required for a user to register their Evolution account and be able to use it in basic ways. Many of the more advanced functionalities will first be exposed via CLI, allowing more experienced users access into the system before we implement the features into the evo-client.

As for current testing process, after d10e we have been busy onboarding some new highly-skilled developers into the core-team, which will be helping us to thoroughly test and refine 12.1 and will continue into 12.2 development. This additional capacity and expertise will accelerate the pace and quality of testing, bug-fixing, and ongoing core development, and allow progress to continue unabated even when my time may be required for events or business-related needs.

Testing is currently progressing for 12.1, and we are presently working on getting superblocks to be created and accepted on the network. This introduces a lot of new code and needs some work before community-wide public testing would be beneficial. The current one is a process of debugging thousands of new lines of code, and making sure most of the work flows are tested and function on a basic level without critical errors. We should expect to shift to public testing of version 12.1 within the next two weeks.

Thanks!
 
Quick question: Are the new three wallet types being built for evolution going to be electrum based, qt based, or other?

Thank you,
Pablo.
 
@eduffield Can you explain the 12.1 budget system? Will this have turing complete programming? If so, this is a really big deal, and it should be the main focus of this release.

The community would like the opportunity to understand how the code works BEFORE it is released. There could be some changes that severely effect Dash (like multiple month contracts that can never be voted out). How does the minimal Masternode hosting requirements change. Is the REST api going to require more bandwidth? Dashdrive more server space? This release needs a discussion and maybe a vote before it is released.

Thanks for the update.
 
Quick question: Are the new three wallet types being built for evolution going to be electrum based, qt based, or other?

The Electrum based Evolution demo was just a prototype/showcase. The actual Evolution wallets are developed from scratch. @AndyDark may chime in if i wrote something wrong :)
 
@flare thank you as always :).

@AndyDark Hey :),
Could you please tell me if the wallets will use the electrum codebase at all or be completely new?

Thank you very much for your help.

Pablo.
 
@eduffield Can you explain the 12.1 budget system? Will this have turing complete programming? If so, this is a really big deal, and it should be the main focus of this release.

The community would like the opportunity to understand how the code works BEFORE it is released. There could be some changes that severely effect Dash (like multiple month contracts that can never be voted out). How does the minimal Masternode hosting requirements change. Is the REST api going to require more bandwidth? Dashdrive more server space? This release needs a discussion and maybe a vote before it is released.

Thanks for the update.

Just wanted to reiterate what solar said above. For Dash users and stakeholders who are not privy to your private development Slack or other private conversations, it really would be nice to have some more information about 12.1 specs. AFAIK, you haven't even officially announced here what sentinel *is* and what these other new features will mean for us in the short term, so you might understand why updating us that you're working on the stability/usability of it (sounds like finishing touches) might make me nervous when it hasn't even been openly discussed.
 
@eduffield Can you explain the 12.1 budget system? Will this have turing complete programming? If so, this is a really big deal, and it should be the main focus of this release.

The community would like the opportunity to understand how the code works BEFORE it is released. There could be some changes that severely effect Dash (like multiple month contracts that can never be voted out). How does the minimal Masternode hosting requirements change. Is the REST api going to require more bandwidth? Dashdrive more server space? This release needs a discussion and maybe a vote before it is released.

Thanks for the update.

+1 I would also like to get more information about how the 12.1 features are implemented. What does Dashdrive mean for the Masternodes? How reliable is their data storage? How did the new budget system end up being implemented? Releasing information early allows for a wider peer review and minimizes the risk that the community will be surprised when the new release comes out and opposes to it.
 
minimizes the risk that the community will be surprised when the new release comes out and opposes to it.
It's not something to vote over. Evan & team build whatever they want. Info would be nice however. But i guess it's better to let the ETH/C storm die down a bit to give our news room to impress.
 
It's not something to vote over. Evan & team build whatever they want. Info would be nice however. But i guess it's better to let the ETH/C storm die down a bit to give our news room to impress.

Yes, info would be nice. Not giving stakeholders a clear picture or even having a discussion with stakeholders prior to dumping a release on us is the kind of thing that exacerbates disunity between core and community. Ultimately, it gets voted on by miners and MNOs when they decide to update or not update. But just leaving it to that sounds like a poor plan if anyone on the dev team cares at all about input from stakeholders or keeping them well informed.
 
Sorry, don't agree at all. Evan doesn't work for you, he owes you nothing. He builds open source software for everybody to use or not.

"Demanding" stuff and then starting discussions with big words "disunity between core and community" when your demands are not met is at best illogical. But it also looks like just a tactic to spread FUD. This is something trolls do, not level headed "community" members.
 
Sorry, don't agree at all. Evan doesn't work for you, he owes you nothing. He builds open source software for everybody to use or not.

"Demanding" stuff and then starting discussions with big words "disunity between core and community" when your demands are not met is at best illogical. But it also looks like just a tactic to spread FUD. This is something trolls do, not level headed "community" members.

Actually he does work for us because we pay him. No one is "demanding" anything. I am simply stating that stakeholders might want to be treated a little differently than this, for good reason. I don't appreciate being labeled by you as a troll, already! Seriously? This is the attitude that alienates people and makes people want to completely withdraw from this place. Anyway, I would appreciate if someone *from core development* ( not you) would be kind enough to weigh in
 
Not true, the blockchain does.

And who decides whether the blockchain pays? Stakeholders. Of which I am a member.

I understand, also I didn't do that. I argued from the 'illogical' option.

Saying that my post looks like a tactic to spread FUD which is what trolls do, is a strong enough implication for me.

From this point forward I will try to keep this *on topic*. A few of us have requested additional information or a response from the op. It's not anything personal. I am happy to hear other people weigh in, both of *us* have already made our opinions known so it's a waste of time for us two to go back and forth anymore.
 
Thanks @orangecycle.

This budget readme is the one that we want to see before release. It currently says rewrite..
https://github.com/dashpay/dash/blob/v0.12.1.x/doc/masternode-budget.md

Why advanced notice on this release? Most releases up to this point just added features. It isn't a big deal to add a feature and shouldn't require any community discussion. This release fundamentally changes the budget system. Users need to know these changes before they are released.

I see that multiwallet support is listed as a change. This is really cool. (Changes like this don't need a vote, but you do get more ataboys if you can list the cool stuff that is added in the release notes)
window.setCurrentWallet("~Default");

If you need someone to write the release notes, ask. I am sure we can help out with this with a little help and direction.
 
A good place to keep up with all the changes is the official repo https://github.com/dashpay/dash/. You can "watch" a repo and have all updates emailed to you. A lot of updates are packed with valuable and interesting commit comments. Makes for good morning reading with a cup of coffee.

Just wanted to add this one has a ton of juicy stuff that is nowhere to be found on the official repo...
https://github.com/evan82/sentinel

If Evan is not responsive here it's probably because he's committing the hell out of that repository. Documentation on functionality is thin but that might be because there's literally only one person coding all of this. How comfortable is everyone else in our dev team in terms of knowing what this is? I think it is imperative that even though Evan is clearly the lead (if not only) developer for Sentinel, we need to work to get as many people up to speed on what it is and how it is intended to work, as soon as possible. This will speed up testing and also increase the quality of peer review.
 
There is a proposal for technical writing https://www.dashwhale.org/p/crdev-docwiki-201608

It may help us better view from developer perspective.

Why don't we vote for it? Evan and his team quite busy to code and that proposal will satisfy us as stakeholders and reduce work load for core developers.
We are not asking for a 12 page technical paper with drawings and flowcharts! This is a simple 10 item list with some of the important features and how they effect masternode budgets, voting, and operation. Specifically, how the budget contracts are getting implemented and how they can be stopped. Pretty simple. If this takes more than 10 minutes, I would be surprised.

I suggested that before we ask some technical writing wizard to take money, that we instead ask a few community members to write it. There are many people that want to get involved in Dash and this is a perfect activity to get people to make flow charts, images, or just summarize some text. We already have a gigs list on www.dashnation.com/gigs where slack member participate in bounties and finish projects. That would be a much better solution to get this type of project done.
 
We are not asking for a 12 page technical paper with drawings and flowcharts! This is a simple 10 item list with some of the important features and how they effect masternode budgets, voting, and operation. Specifically, how the budget contracts are getting implemented and how they can be stopped. Pretty simple. If this takes more than 10 minutes, I would be surprised.

I suggested that before we ask some technical writing wizard to take money, that we instead ask a few community members to write it. There are many people that want to get involved in Dash and this is a perfect activity to get people to make flow charts, images, or just summarize some text. We already have a gigs list on www.dashnation.com/gigs where slack member participate in bounties and finish projects. That would be a much better solution to get this type of project done.
I love what you guys are doing with your grass roots styled approach @Solarminer, however I do think that the technical writing needs to be done by someone that is experienced at doing that. If there is someone in the community that is experienced then that is great, let them hit up babygiraffe and let him know that they want to apply for the job. However if there is no one that is qualified or experienced at this then the best thing to do is out source and not wait around.
The grass roots styled approach is great for getting the community involved (hats off to you), however there are two approaches to work getting done and the core seems to be more directive in there approach rather than waiting for someone to do it. It doesn't mean that they wouldn't be open to taking job applications though if someone did step up to the plate.
 
Back
Top