js-drive VS dips

I would like to start by saying that I greatly value Andy's contributions both to DCG and the Incubator and thank him personally. I am not just saying this as a platitude, without him we would not be where we are today. I also would like to believe that there have been slight miscommunications that led to some factual inaccuracies that I would like to rectify. On top of that I believe in openness, so I'm not going to try to paint the rosiest of pictures, just what I think is actually accurate. First and foremost, DashPay is not our priority. It has however already been written by the mobile team last year when I led that team. This was after the failure of a Javascript React Native Dashpay team. Andy was the main backer of such a team, even though I made it clear to him at the time that the mobile team would do the work in React Native if we had such work defined. In the end I wrote the DIP for Dashpay with Eric/HashEngineering and we delivered as seen by the alpha program. Here is the DIP for any interested where you can clearly see my and Eric's name: https://github.com/dashpay/dips/blob/master/dip-0015.md My point here is not to bash Andy, but more to try to be open about the fact that decisions that turned out to be bad also happened under his watch when he was CTO. I don't entirely fault him though, it's impossible to know the future, and no one is infallible. I distinctly remember Ryan being very neutral on this topic and eventually siding with Andy, most likely because Andy was the CTO and you should trust people that have that role. Overall Andy's tenure as CTO was very beneficial as he was the main instigator for the concepts that will be brought to fruition in Dash Platform. I want to reiterate that DashPay is not our priority as Andy would seem to think it is, our priority is releasing Platform with a minimal set of features that are required for DashPay, and that's almost the definition of an MVP. We believe that this is what the community at large wants. There's a slight nuance that could have gotten lost somewhere. Basically for all intents and purposes, the DashPay Dapp is done. And as I said earlier, if Platform was ready we could release it with the work of a dev on Android and 1 dev on iOS within a week or two. I personally have only been spending maybe 5% of my time on DashPay, and this is more to validate work on Platform than anything else. The focus inside the entire organization is to do everything in our power to release Platform. If we add the features requested by Incubator - that I agree are very important - it will take time, I'm open to this approach but I want to make it clear that we are not choosing features for Dashpay Mobile wallet, as our recent (2021) and future work in Platform consists of consensus code, database storage, decentralized proofs and many other things that are both necessary for incubator development and Dashpay. The next thing that Andy said, and this time that is absolutely false, is that there are less people working in Platform than in Mobile, this is not true and easily verifiable. To that extent, we can just look at contributions on github to drive https://github.com/dashevo/js-drive/ and tenderdash https://github.com/dashevo/tenderdash/. These are the two main repositories for Platform team, with the second (Tenderdash) being largely what I personally have been working on. There are currently 5 active full time devs in Platform team, with 3 others part time, compared to 2 active full time devs in Mobile team, with 1 currently part time (and me who goes back to mobile when needed). Mobile team used to have 5, which Andy might have thought we still had. We are trying to hire more people for Mobile team too, with hires coming up very soon. The reason why Andy must have thought 3 for Platform, is that during a conversation I had with him I stressed hiring, and said that we are not going to build platform quickly with 3 devs, and I said that at a time when one was on vacation and I didn't include myself. I spoke quickly because of my own frustration at the time with speed, and I really should have included myself in the mix as well as other part time devs. So in the end this is really my fault and I apologize for the miscommunication. The main focus inside our org is delivery, the second focus is hiring. Andy could rightfully argue that the focus on hiring started later then it should have, and I won't debate that at all. There are complex reasons and failures that led to this being the case, but I just simply would not fault Ryan, as he is the one who stepped in to remedy the situation basically by giving me, Ivan and Pasta all powers to do anything in our power to get the people we wanted and still currently want. We hired 2 temp part time recruiters on top of the one we currently have, this has led to around a ~x3 in candidates. The structure and culture that Andy helped put in place is that Ryan has less power over the development side of things. Since the development teams 100% decide who is being hired, it seems weird to me to blame Ryan. What Ryan can do and did do is step in when things are not going well enough. He could possibly have done this a few months sooner, but he would have been stepping on toes and most likely wanted to give the development side of the org time to rectify the situation themselves. The more nuanced reasoning of where our hiring for Platform went wrong (for those interested, since Andy said he thinks this is an excuse) is that the Venn diagram between javascript devs that are very good, know cryptography, and work on the backend is very small. We have received 60+ candidates so far, with only 1 receiving an offer, which he ultimately turned down. I would like to add that if you are or know anyone who would fit such a role, please apply on Dash.org/jobs. Next, there seems to be an implication that Bizdev and Marketing are taking away valuable resources from the development teams. There are only 3 people between those teams (with potentially a few external contributors paid through different proposals than comp). With so many different voices in the network, some who want DCG to take on more marketing/bizdev and some who don't, I personally feel like having small teams like this is a net plus for the organization. I also personally do not think DCG should be the only/main marketing branch for Dash. And the same for our BizDev team too. However, these small teams do make strong sense in my opinion and should add to any effort made by other DFOs. We must remember that what's important is the value that such teams provide. Andy raises some very good points about the stability of platform releases. These are completely valid points. And this is why yesterday, before his post came out I had a chat with one of the main Incubator devs, who agreed to participate in testing the upcoming v20 release. Basically with my new role which will be announced shortly I want to make sure that Incubator devs no longer run into any issues. This is a priority for me personally. I thought Andy would like to be in control of QA, and he seemed very open to it when I talked with him a few months ago, but if that's not the case then we will take steps to do it inside DCG as soon as we have hired someone for that role or we have capacity to do it with our current team. The next part that is factually inaccurate is that the community has no way to actually verify work... That is just not true. The point of the DashPay alpha program was to show our community work that had been achieved. We are also fully open source so anyone can check repositories if they so choose. You can for yourself see how much each developer is writing in code. In fact (another call out) if anyone here wants to take their time and provide a tool to report some stats that would be appreciated.

Example spec: https://github.com/dashpay/dips/blob/master/dip-0006/bls_m-of-n_threshold_scheme_and_dkg.md

For a technical explanation of how Chainlocks works it's probably best for me to link you to the DIP rather than attempt explanation off the top of my head: https://github.com/dashpay/dips/blob/master/dip-0008.md

Dash Core v0.17 is fully active on mainnet following successful hard fork activation at block 1516032. This enables several new opcodes along with a new quorum type to support Dash Platform. Defined in DIP20 on GitHub.

I would like to start by saying that I greatly value Andy's contributions both to DCG and the Incubator and thank him personally. I am not just saying this as a platitude, without him we would not be where we are today. I also would like to believe that there have been slight miscommunications that led to some factual inaccuracies that I would like to rectify. On top of that I believe in openness, so I'm not going to try to paint the rosiest of pictures, just what I think is actually accurate. First and foremost, DashPay is not our priority. It has however already been written by the mobile team last year when I led that team. This was after the failure of a Javascript React Native Dashpay team. Andy was the main backer of such a team, even though I made it clear to him at the time that the mobile team would do the work in React Native if we had such work defined. In the end I wrote the DIP for Dashpay with Eric/HashEngineering and we delivered as seen by the alpha program. Here is the DIP for any interested where you can clearly see my and Eric's name: https://github.com/dashpay/dips/blob/master/dip-0015.md My point here is not to bash Andy, but more to try to be open about the fact that decisions that turned out to be bad also happened under his watch when he was CTO. I don't entirely fault him though, it's impossible to know the future, and no one is infallible. I distinctly remember Ryan being very neutral on this topic and eventually siding with Andy, most likely because Andy was the CTO and you should trust people that have that role. Overall Andy's tenure as CTO was very beneficial as he was the main instigator for the concepts that will be brought to fruition in Dash Platform. I want to reiterate that DashPay is not our priority as Andy would seem to think it is, our priority is releasing Platform with a minimal set of features that are required for DashPay, and that's almost the definition of an MVP. We believe that this is what the community at large wants. There's a slight nuance that could have gotten lost somewhere. Basically for all intents and purposes, the DashPay Dapp is done. And as I said earlier, if Platform was ready we could release it with the work of a dev on Android and 1 dev on iOS within a week or two. I personally have only been spending maybe 5% of my time on DashPay, and this is more to validate work on Platform than anything else. The focus inside the entire organization is to do everything in our power to release Platform. If we add the features requested by Incubator - that I agree are very important - it will take time, I'm open to this approach but I want to make it clear that we are not choosing features for Dashpay Mobile wallet, as our recent (2021) and future work in Platform consists of consensus code, database storage, decentralized proofs and many other things that are both necessary for incubator development and Dashpay. The next thing that Andy said, and this time that is absolutely false, is that there are less people working in Platform than in Mobile, this is not true and easily verifiable. To that extent, we can just look at contributions on github to drive https://github.com/dashevo/js-drive/ and tenderdash https://github.com/dashevo/tenderdash/. These are the two main repositories for Platform team, with the second (Tenderdash) being largely what I personally have been working on. There are currently 5 active full time devs in Platform team, with 3 others part time, compared to 2 active full time devs in Mobile team, with 1 currently part time (and me who goes back to mobile when needed). Mobile team used to have 5, which Andy might have thought we still had. We are trying to hire more people for Mobile team too, with hires coming up very soon. The reason why Andy must have thought 3 for Platform, is that during a conversation I had with him I stressed hiring, and said that we are not going to build platform quickly with 3 devs, and I said that at a time when one was on vacation and I didn't include myself. I spoke quickly because of my own frustration at the time with speed, and I really should have included myself in the mix as well as other part time devs. So in the end this is really my fault and I apologize for the miscommunication. The main focus inside our org is delivery, the second focus is hiring. Andy could rightfully argue that the focus on hiring started later then it should have, and I won't debate that at all. There are complex reasons and failures that led to this being the case, but I just simply would not fault Ryan, as he is the one who stepped in to remedy the situation basically by giving me, Ivan and Pasta all powers to do anything in our power to get the people we wanted and still currently want. We hired 2 temp part time recruiters on top of the one we currently have, this has led to around a ~x3 in candidates. The structure and culture that Andy helped put in place is that Ryan has less power over the development side of things. Since the development teams 100% decide who is being hired, it seems weird to me to blame Ryan. What Ryan can do and did do is step in when things are not going well enough. He could possibly have done this a few months sooner, but he would have been stepping on toes and most likely wanted to give the development side of the org time to rectify the situation themselves. The more nuanced reasoning of where our hiring for Platform went wrong (for those interested, since Andy said he thinks this is an excuse) is that the Venn diagram between javascript devs that are very good, know cryptography, and work on the backend is very small. We have received 60+ candidates so far, with only 1 receiving an offer, which he ultimately turned down. I would like to add that if you are or know anyone who would fit such a role, please apply on Dash.org/jobs. Next, there seems to be an implication that Bizdev and Marketing are taking away valuable resources from the development teams. There are only 3 people between those teams (with potentially a few external contributors paid through different proposals than comp). With so many different voices in the network, some who want DCG to take on more marketing/bizdev and some who don't, I personally feel like having small teams like this is a net plus for the organization. I also personally do not think DCG should be the only/main marketing branch for Dash. And the same for our BizDev team too. However, these small teams do make strong sense in my opinion and should add to any effort made by other DFOs. We must remember that what's important is the value that such teams provide. Andy raises some very good points about the stability of platform releases. These are completely valid points. And this is why yesterday, before his post came out I had a chat with one of the main Incubator devs, who agreed to participate in testing the upcoming v20 release. Basically with my new role which will be announced shortly I want to make sure that Incubator devs no longer run into any issues. This is a priority for me personally. I thought Andy would like to be in control of QA, and he seemed very open to it when I talked with him a few months ago, but if that's not the case then we will take steps to do it inside DCG as soon as we have hired someone for that role or we have capacity to do it with our current team. The next part that is factually inaccurate is that the community has no way to actually verify work... That is just not true. The point of the DashPay alpha program was to show our community work that had been achieved. We are also fully open source so anyone can check repositories if they so choose. You can for yourself see how much each developer is writing in code. In fact (another call out) if anyone here wants to take their time and provide a tool to report some stats that would be appreciated.

But more importantly, beyond economic incentives, a single Masternode is incapable of making any promises: It's always quorums consistent of up to 400 nodes, so even if one acted maliciously, the majority would override and sanction the offender(s) via PoSe-bans (->no more rewards).

DIP-0003 provides an in-depth look at the new Evo-based masternodes model.

More details about how Identities will work are particularly exciting (as are usernames using DPNS). Usernames will resolve to an Identity (analogous to a website domain name resolving to an IP address). And it may be possible to have subdomains!?