Proposal “Dev_Web_SDK-Platform_Id_with_Explorer“ (Active)Back
Title: | Develop Web SDK - Platform Identities & Explorer Web App |
Owner: | digitalcashdev |
Monthly amount: | 200 DASH (11048 USD) |
Completed payments: | no payments occurred yet (2 month remaining) |
Payment start/end: | 2024-10-28 / 2024-12-27 (added on 2024-11-07) |
Final voting deadline: | in passed |
Votes: | 338 Yes / 202 No / 29 Abstain |
Will be funded: | No. This proposal needs additional 191 Yes votes to become funded. |
External information: | digitalcash.dev/proposals/dcd-4-dev-web-sdk-platform-id-with-explorer/ |
Manually vote on this proposal (DashCore - Tools - Debugconsole): gobject vote-many 3465ec31a2be0f04a38b010942ea122c3a61d87439f9f97be29d99f7df2ca733 funding yes Please login or create a new DashCentral account for comfortable one button voting! |
Proposal description
Proposal Abstract
This is a "first full loop" for working with Platform natively in a Web Browser focused on Platform Transitions (the build blocks of Platform), specifically those related to Platform Identities.
The deliverables are a Native JavaScript Library (No Rust, No WASM) and a Web App with code examples for Registering Identities on Platform.
Once completed, another proposal will be submitted for work to support another batch of Platform Transitions.
Video
Full Text
https://digitalcash.dev/proposals/dcd-4-dev-web-sdk-platform-id-with-explorer/
This is a "first full loop" for working with Platform natively in a Web Browser focused on Platform Transitions (the build blocks of Platform), specifically those related to Platform Identities.
The deliverables are a Native JavaScript Library (No Rust, No WASM) and a Web App with code examples for Registering Identities on Platform.
Once completed, another proposal will be submitted for work to support another batch of Platform Transitions.
Video
Full Text
https://digitalcash.dev/proposals/dcd-4-dev-web-sdk-platform-id-with-explorer/
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
No comments so far?
Be the first to start the discussion! |
https://www.dashcentral.org/p/Retain_DCD-AJ
https://mnowatch.org/votethenumbers/votethenumbers3/calc3.php?proposals%5B%5D=Dev_Web_SDK-Platform_Id_with_Explorer
But it failed!!!
Wake up, stupid proposal onwers!
Challenge the election system!
https://www.dash.org/forum/index.php?threads/pre-proposal-put-the-unvoted-10-net-votes-threshold-of-the-dash-budget-system-into-vote.54042/
Hey AJ, looks like it's probably too late to affect this voting cycle now, but let me know if you'd be interested in talking with me (and others) in the afterparty sometime. I would like to hear and try to understand your reasons for lashing out at Sam. What I've heard so far sounds like:
"I don't like Sam because:
I think he is a bad coder.
I disagree with how he has spent DCG funds.
He is opposed to DAO funding of a JS SDK."
I suspect there must be some deeper reasons for your animosity toward Sam... but even so, your brazen insults were entirely unprovoked and mean. You instigated negativity needlessly, and doing that did not add persuasiveness to your point.
Maybe you don't respect Sam, but you do owe him an apology. If you won't apologize to Sam, that bothers me, but I'd like an explanation please.
I'd be interested to hear you to try to persuade me about Sam: politely, using ideas and reasoning or presenting evidence. The tactic of being mean when you disagree with someone is just outright garbage; it's immature, and you need to reflect on your own behavior.
But I still like you and respect you, AJ. I see great value in your work and your ideas. I didn't turn against you, I simply reacted to the objectively bad behavior that I witnessed, which you can choose to improve. Please be nice to people here.
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-----
Why, in your long and signed message, you do not mention the most important point?
@AJ and @Rion exploded because @QuantumeExplorer refused to implement WASM.
https://youtu.be/D48RLVeaJ5A?t=4176
Here is @QuantumeExplorer's NO to WASM:
https://youtu.be/D48RLVeaJ5A?t=5359
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.
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).
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.
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.
How do you think the timelines will differ?
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.
quantumexplorer said, Javascript is a bullshit. He received +4 in his comment.
The moral of the story? The voters are stupid.
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 :)
Transactions in Javascript? This is NOT secure!!!!
https://en.wikipedia.org/wiki/Formal_verification
Otherwise you are just an amateur.
Remember, the Dash platform was initially writen in javascript, then all the code was thrown away and rewritten in rust.