Welcome!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It was very frustrating watching the "Secure Platform Web SDK | Incubator WEEKLY" (https://www.youtube.com/watch?v=D48RLVeaJ5A). At one point AJ said, "if people want to downvote the proposal, because I've got a bone to pick, then vote down the proposal." And honestly, I think that is what should happen at this point.

I was also invited onto this call, and I originally intended to join, but due to relatively late notice and conflicting with a meeting, I didn't join.

Sam joined the call and started talking around [55:20](https://www.youtube.com/live/D48RLVeaJ5A?si=hLzPtAUxpcdhmda5&t=3320); and AJ literally didn't let him finish his first sentence related to the topic, this continued as Rion tried to tell him to let Sam speak.

Around 1:04:00 Sam asked AJ to describe what he what trying to achieve, and what he would deliver in his first release. Notably, AJ didn't talk about what he would do, but instead described the existing JS SDK as "too complicated and doesn't work" before going on to say "I do not have faith your team can produce clean, small code, because I see how you have not improved Dash Core, the C++ layer, and I see what you've done in Rust and you've done the exact same design patterns... I have zero confidence you will produce a codebase that web developers will enjoy using..."

Instead of engaging in a conversation and replying to the question asked- talking about his vision and how he'd achieve it- he ranted on about the products of DCG.

Finally, AJ said he'd mute himself and let Rion and Sam talk for a bit; and while slightly heated, maybe more-so than I would prefer, the conversation was generally respectful, and dare I say slightly productive.

At some point, as Sam was trying to explain why something wasn't do-able, AJ just couldn't take it anymore and said:
"Sam you don't know what you're saying because you don't have the relevant experience. You don't have experience in engineering and you don't have experience in JavaScript and your Rust experience is middling... it's not a personal attack it's a fact... this isn't a secret, this is BS"

At this point, Sam left, as it was evident nothing productive was going to come.

At the end of the call, a community member posted a comment asking for AJ not to be "Disrespectful to Sam" and AJ responded "Respect is earned; I have not seen things where he has earned my respect... I do not have respect for him, he has not earned my respect."

At one point AJ said "I will work with you (Sam) to create the best possible product." The problem is, no-one wants to work with someone who treats other people like this. Sam went on to their podcast, as invited, to try to have a discussion, and explain his perspective. AJ, it seems to me, joined with the mindset he always does, combative and arrogant.

I don't want to have to go back and source a bunch of discord messages, but suffice to say, this isn't the only time AJs manner of communication has made me feel this way.

Later on, Rion said, "My biggest fear is people will say that 'AJ got upset, and Rion even got upset'; but I hope people can see through that". But that's not the problem, it is not a problem to get upset, I'm frankly quite upset right now. And it's not even a problem to have strong opinions. Anyone who has ever been to a meetup or architectural call with me, Sam, and Ivan know that we all have very strong opinions, and will not hesitate to tell each other we think their idea is wrong. But we would NEVER say things in the same vein that AJ spouts with impunity.

AJ simply doesn't know how to communicate with people. It is important to have strong and informed opinions, and it is important to communicate things as you see them. But, ultimately, if you forget about the *person* you who are talking to, you shouldn't be in this community.

I think it is important for the DAO to make its voice clear, that strong opinions and disagreement are always acceptable, but disrespect will not be tolerated. I don't think this needs to be or should be the end for AJ in Dash. But I will be voting against each of his proposals this month, and I would ask you to do the same. He needs to learn that this is unacceptable; that to be a member and contributor to an open source community must involve being able to respect and have conversations with the other members of that community. His prior actions, and actions recently have shown he is currently unable to do that.

Pasta
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQQCuOfQAhZ8i0Ua8F/i89eRbnItOAUCZzwNdAAKCRDi89eRbnIt
OMaIAPkB3+iHm0g9maQYNTkOBFKyW50SJrXwdLA2Z/WJ/W1FjAEA90+PXp8Gxvjn
elBHkU1/9qmPPEN+1xmcWaTlpumWTw0=
=VN7y
-----END PGP SIGNATURE-----

Ugh, I really like AJ and I see his point (having anything to work with) but I see QE's point and I'm worried about pinching pennies right now. QE just said this on discord "Ivan was saying that he could strip out parts of the current JS sdk and that would be better than what’s being proposed." and nobody could attend today's incubator weekly. This is hard, but I think we should get Ivan to clean up the existing sdk, already built and just needs adjustment. Also, I also would want developers to switch to the secure version as soon as it's out, and I think they will if it has security as well as more services/capabilities.

Worried about pinching pennies, I mean feel the need to pinch pennies.

I try to not comment on proposals since becoming CTO of DCG. However I am heavily against this proposal and need to explain why.

Let me first give a basic explanation of how the security of platform works:

*Each block is validated by Evonodes, when over 67 Evonodes agree that a block is valid a BLS threshold signature is produced.
*This signature signs the state root hash, which is a the root of a merkle-ized tree that contains all data.
*All data in the system can be proved to be part of the state, by knowing the root hash, and a GroveDB proof.

Hence if you know the Masternode List and Quorums at a certain block with just 1 signature and a GroveDB proof you can prove all data in the state. On top of this GroveDB and Dash Drive are built in a novel way that allow for secondary indexes, so you can also prove that the data you got back is the right data that you requested and that it is complete.

This is extremely innovative in the blockchain space, and is a key differentiator for us.

On top of this we have DAPI which is a decentralized API that allows users to query Evonodes directly. So with that, together with provable data, we can bring out true web3 that is both secure and decentralized.

Now let me now say why I do not think this proposal can succeed.
AJ says in the text of this proposal: "Native JavaScript Library (No Rust, No WASM)".

In a nutshell he is making a system that is not secure, because the secure way without Rust or Wasm would be almost impossible to build without a massive team and millions of dollars, and he has admitted he is not going for security. I'll explain the issues of this approach at the bottom of this post if that interests anyone.

I am worried that this could eventually lead to a lot of issues. My nightmare would be that this becomes the main JS SDK, then gets exploited, and all of Evo gets blamed.

So why is AJ making this proposal? Well the current JS SDK is just not that great. It was written by many people over many years, and all inside DCG agreed that we would focus on the SDKs later down the line after the main release was stable. Neither me, nor Ivan, nor Lukazs have done any significant work on the JS SDK in years. So yeah it’s not good.

It’s frustrating coming out against this proposal, because I know that AJ means well. He is trying to solve a problem that he sees, and with the tools he knows. That is commendable. However we also need to do what’s in the best interest of the network. I believe that this work will eventually be a wasted effort if this proposal were to pass.

Our plan inside of DCG is to make a WASM binding on top of our RustSDK, by doing this, we will both be harnessing a battle tested SDK, and we will get all the security features that are needed. This solution will also support all the state transitions the system has and all the queries as well. We have to make this JS-SDK, because Dash needs to offer a secure SDK.

According to AI, this solution will however be about 1.25x to 1.5x bigger in size for the same amount of features. However with heavy optimization AI says that we can bring that down to parity with native JS. I however do not plan on heavy optimization yet, because it would be premature to do so before getting a significant amount of users.

Explanation why the proposed system is not secure:

I have asked him since then in discord how he will implement GroveDB proof verification in pure JS, and he wasn't planning to.
He is not planning to implement any form of hard proof verification. He did say that he would query many nodes to see if they agree, but this is a weak solution, because you would only be safe after querying more than 10 random nodes, which would put a lot of additional strain on the network, and take a lot of processing time and bandwidth on the client.
This is not how the system was designed, we designed for the system to be efficient and cryptographically secure. There's no point in years of innovation if we go with a clunky soft consensus mechanism.

The idea of alternative, non-proved JS SDK is to allow developers to begin scratching products, and introduce people into Platform, because right now we don’t have no easy way to access any of nice features of the Dash Platform like identity registration, name registration, submitting documents, etc. Nobody disagrees that provable SDK is a must have, and must be done, because it allow you to query the data in the decentralized way.

However, we don’t know how much time will it take for a full completion (in full provable way), and how easy will it be to use on the frontends, there are some concerns that could probably make it a bit complex to integrate it in the Web environment properly as we see it.

In my opinion, it makes sense to unblock frontend developers with the a less secure libraries, that would query a centralized trusted endpoint (perhaps Platform Explorer API), but allow them to start building products and show people all of the ground breaking capabilities of Dash Platform. Later, when appropriate SDKs will appear in the network, we can easily switch to it, or if AJ wants, he might want to build a proofs in his library as well, whether its a pure JS implementation or WASM bindings (only for proofs functions).

I'll provide a short reply now, but AJ will be joining me for Incubator Weekly tomorrow where we'll discuss this topic. We'll circle back with a more detailed reply (including text) after the show.

In short, this proposal simply provides a different JS SDK feature and security timeline than DCG's current plan. We are all aware of the high level security design of platform, and our plan is to add features and security iteratively.

By "we are all aware", I'm referring primarily to AJ and me, but also pshenmic, with whom we discussed this proposal before submitting (he can speak for himself regarding what he supports).

Hi AJ, Sam, Rion, and others.

Sam says he's "heavily against" this proposal... I'm thinking it's probably because this JS SDK might (temporarily?) be something that bypasses the fundamental proof system that makes Evolution a reliably secure decentralized platform. Is that right? And then if this exploitable version becomes what developers start using, then Dash's excellent, robust, secure, worthy Evo Platform which DCG has worked so hard to create might be put at risk of never being appreciated for what it's supposed to do. If Evolution gets blamed/shamed for being exploited because of the JS SDK, wouldn't that be tragic?

Sam said: "My nightmare would be that this becomes the main JS SDK, then gets exploited, and all of Evo gets blamed."
How big of a risk do you think there is of this JS SDK being exploited (and how confident are you)? Can you please describe what harm it might cause to Dash Evolution platform and to its reputation, if an insecure JS SDK gets exploited?

Would this JS SDK put "a lot of additional strain" on platform?

Will the heavily-optimized WASM binding on top of Rust SDK that DCG is going to make be all that is needed? or is this JS SDK preferable to that? Will it take too long? Is there a hurry to have something ready so that JS devs will take interest in Evolution?

I will watch Incubator Weekly tomorrow. I still might change my vote either way, because I do see a lot of value in attracting JS devs, but I'm also worried about risking any potentially negative outcome that might hurt Evolution's chances for success.

I get that this sounds good in theory, however how do you plan AJ plan on actually adding these features and security iteratively? Does he plan to rewrite the proof verification mechanism of GroveDB in pure JS? Does he plan on rewriting the DriveQuery to PathQuery converter? Is there an estimate of this time?

How do you think the timelines will differ?

Yes, AJ had decided to give up optimal security for the sake of quick dapp testing. He's made it known he's comfortable with querying nodes (that can lie) until DCG's solution is written up.

Shouldn't it be fine as long as your comments are considered by MNOs along with AJ's and other dapp devs' need to get this out sooner? Also, AJ and other dapp devs should pledge that any dapps created from this 'web SDK' would have big warnings saying to only commit minimal funds.

I don't think AJ's solution would be sooner though, unless the whole solution is just very hack-y and only made for a name registration and can not be used for anything else. Maybe we should have a complete list of features that is planned for the initial release and a time to get that done, and we can compare that to how long DCG would take to do that by just writing wasm bindings for that feature.

I said, Javascript is a bullshit. I received -4 in my comment.

quantumexplorer said, Javascript is a bullshit. He received +4 in his comment.

The moral of the story? The voters are stupid.

Recently we had a talk with the proposal owner regarding problems that we face while developing frontend Dash Platform applications in the Web. The main issue we get into right now is a lack of JS implementation of the Dash Platform Protocol, which forces us to use Dash SDK (Rust bindings) that is very heavyweight, slow, and unfortunately, not production ready yet

To build fast, native, and nice products with good UX, we need fast, lightweight libraries that anybody can run even on slow or mobile devices.

The idea of this proposal is a research of two important things - further research on how to create Dash Platform transactions in JS and a necessary Web infrastructure for it. GRPC protocol is pretty complex protocol, and also weights too much on the client, to be efficiently used in frontend bundles. I believe it would be much easier for developers to start scratching Dash DApps via querying simple HTTP JSON API interface.

I want to give all my support to this proposal and encourage people to vote for it :)

>how to create Dash Platform transactions in JS

Transactions in Javascript? This is NOT secure!!!!

We sorely need this, voting YES !

Whatever critical software you write, should be able to pass a formal verification.

https://en.wikipedia.org/wiki/Formal_verification

Otherwise you are just an amateur.

I think it is a bad practice to write such critical protocols in the insecure javascript language.

Remember, the Dash platform was initially writen in javascript, then all the code was thrown away and rewritten in rust.