Dev Updates - Mikhail, Matt, Anthony | Incubator WEEKLY

Episode Description

Dash Incubator developers demo the AutoShow content repurposing app with Dash payments and discuss two competing JavaScript SDK approaches for Dash Platform.

Episode Summary

This episode of Incubator Weekly features three developers presenting updates on Dash-related projects. Anthony Campolo demonstrates AutoShow, a content repurposing application that transforms audio and video into summaries, blog posts, and other assets using various AI models. He showcases the newly integrated login system and dual payment options—credit card via Stripe and Dash cryptocurrency via NowPayments—with plans to offer a discount for Dash users. The conversation then shifts to the JavaScript SDK landscape for Dash Platform, where two parallel approaches are under development. Mikhail presents his WASM-based SDK built from Rust code compiled to WebAssembly, along with a browser extension that securely manages identities and private keys without exposing them to web applications. Matt, taking a pure JavaScript approach that results in smaller bundle sizes and broader compatibility, pivots to explaining the proof verification system—a mechanism for confirming that data returned by a single node actually reflects the consensus of the network quorum. He walks through his proof-of-concept code demonstrating BLS signature verification and Merkle tree hash validation. The episode closes with a pragmatic discussion about prioritization, noting that while proofs are important for trustless verification, many Web2 developer use cases can proceed without them, and developer experience should remain a top priority.

Chapters

00:00:00 - Introduction and AutoShow Overview

Rion Gull opens the episode by introducing the three guests and outlining the topics for discussion, which include Anthony's AutoShow application and the JavaScript SDK work being done by Matt and Mikhail. Anthony begins by explaining that AutoShow is a content repurposing tool designed to help creators transform audio and video files into various outputs like summaries, chapter titles, blog posts, and even creative content like rap lyrics, with future plans for multimodal capabilities including image generation and text-to-speech.

Anthony demonstrates the app's login system and its two payment flows for purchasing internal credits: credit card processing through Stripe and Dash cryptocurrency payments through NowPayments. He explains the credit pricing model where one dollar buys 100 credits, with transcription costing around eight credits and LLM processing varying from one to 100 credits depending on the model selected. He notes that the app will offer a discount for users who pay with Dash, which serves both as a user incentive and as a way to gather analytics on cryptocurrency payment adoption.

00:05:05 - AutoShow Live Demo and AI Discussion

Rion examines the payment interface and raises questions about accessibility and the user experience of purchasing with Dash versus credit cards. Anthony acknowledges styling issues that still need work and explains that a redesigned interface is in progress. The discussion moves into a live demonstration where Anthony processes a recent Dash Core Group video through AutoShow, selecting GPT-4.1 as the model and generating key takeaways, quotes, and a blog outline from the video content.

While waiting for the AI to process, the conversation takes an informal turn as Rion asks Anthony about his views on AI's impact on jobs and society. Anthony argues that the job displacement narrative is overhyped, suggesting companies will pursue more output rather than layoffs, and that AI is a genuine productivity breakthrough that people should explore hands-on rather than dismiss. The generated results arrive, showing extracted takeaways about Dash development progress, direct quotes from the source video, and a structured blog outline with a first draft.

00:20:11 - Mikhail's WASM-Based SDK and Browser Extension

The episode transitions to SDK development as Mikhail presents his approach to building a JavaScript SDK for Dash Platform. He explains the two-part architecture consisting of the SDK itself, which handles transactions and API queries, and a browser extension that securely stores identities and private keys. The SDK is built using WebAssembly compiled from Rust code, resulting in a roughly three-megabyte bundle with full TypeScript support and autocomplete functionality. He notes recent migration to Dash Platform version 2.0, including token transition support and data contract methods.

Mikhail details the security model of the browser extension, which runs in a separate context from web pages so that private keys and seed phrases are never exposed to potentially malicious code. The extension provides a public interface allowing decentralized applications to request transaction approvals through dialog popups, while keeping all sensitive operations isolated. He also describes future plans for QR code-based integration with mobile wallets, allowing users to sign transactions from the Dash mobile app instead of entering seed phrases directly into the extension.

00:44:30 - Mikhail's Proposal and Development Roadmap

Mikhail walks through his upcoming proposal, outlining a week-by-week development plan. The immediate priority is releasing a first testable build of the Dash Platform extension that supports importing identities via private key. Subsequent milestones include adding seed phrase import functionality so users can see all their existing identities, implementing identity registration for new users, and building multi-wallet support with different storage options including seed phrases and keystores.

On the SDK side, he plans to integrate WASM-based proof verification, expose token transition methods, and conduct testing on both testnet and mainnet. The proposal also budgets for designer work on new UI screens and documentation. Rion expresses interest in having Mikhail demonstrate progress on the show regularly, noting that some of the weekly milestones seem ambitious but encouraging. Community members in the chat respond positively, with one commenting that the extension could attract regular users beyond just developers.

00:49:15 - Matt's JavaScript SDK and Proof Verification Deep Dive

Matt begins by praising Mikhail's work before presenting his own pure JavaScript approach to the SDK, which trades the WASM dependency for smaller bundle sizes and broader environment compatibility. Rion frames the two approaches using an engine analogy—internal combustion versus electric—acknowledging that it remains unclear whether these will become separate products or merge into one. Matt then shifts to explaining proof verification, the topic that consistently comes up whenever his SDK is discussed.

He walks through the conceptual foundation of proofs: when you query a single node for your identity balance, you receive a number, but a proof cryptographically demonstrates that the entire network quorum agrees on that value. Using BLS signature verification and Merkle tree hash reconstruction, his proof-of-concept code takes apart a real proof, validates the quorum's signature against their public key, traces the hash path through the tree structure, and confirms the root hash matches what was signed. He uses an airplane ticket analogy to explain why verifying the proof's validity alone is insufficient—you must also verify it corresponds to the specific query you made.

01:11:04 - Prioritization, Proofs Discussion, and Closing

The final segment focuses on practical prioritization of development resources. Rion emphasizes that while proofs are important for trustless Web3 applications, many Web2 developers can derive significant value from Dash Platform without them—simply creating schemas, writing documents, and verifying results through the platform explorer provides sufficient trust for numerous use cases. Matt estimates that completing robust proof verification with proper edge-case testing would take roughly a month of full-time work, though the scope can be narrowed incrementally by starting with simpler verifications like identity balances before tackling complex range queries.

Mikhail asks about Matt's timeline expectations, and Rion suggests a gradual approach where proof coverage expands over time rather than targeting full surface-area coverage by a fixed deadline. The conversation closes with Rion expressing confidence in both developers and stressing that developer experience should remain the top priority alongside proof work. Anthony's AutoShow launch target of end-of-month is noted as another important milestone for getting real Dash-integrated products in front of a broad developer audience, and viewers are invited to return for future progress updates.

Transcript

[00:00:04.29] - Rion Gull Welcome everyone to today's episode of Incubator Weekly. We've got Anthony, Mikhail, and Matt with us today. How's it going, guys?

[00:00:13.25] - Matt Good, good, good.

[00:00:17.08] - Rion Gull So we're going to talk about AutoShow with Anthony. We're going to talk about the JavaScript SDK with Matt and Mikhail. There are a couple of different approaches that we're trying to converge on into a good solution, or figure out whether it makes more sense to have two separate products. Is this one product that we're coming together on? So we'll discuss that. We're going to start with you, Anthony, and you've got a screen share, so I'll put that up. But how's it going? Other than your demo, how's it going in general? How's life?

[00:01:01.12] - Anthony Campolo It's good. Yeah, I'm in the process of moving right now. Not a crazy big move, just to a different apartment area. We're moving just a couple miles away. So it got me a little bit behind schedule, but we're actually in really good shape right now. Last time I did a demo, I showed you how all the functionality was there, but there was still some stuff in terms of login and payments that needed to be put together. But that's pretty much all here now. We have login, and we have two ways that you can now buy credits. You can either do a credit card payment, which will go through a Stripe flow like so, or you could purchase with Dash cryptocurrency. So this is using NOWPayments under the hood. I decided to use an API provider just because the SDK seems like it's still kind of in flux and not necessarily production-ready. I think that's one of the things that we'll be talking about for probably the rest of this episode. But you can purchase credits through Dash or through credit card, and then the flow itself has pretty much stayed the same.

[00:02:27.25] - Anthony Campolo You could provide a URL to a YouTube video or a local file, and then you can select your different transcription services and prompts. So we'll do titles and rap song lyrics.

[00:02:47.07] - Rion Gull And before we get too much further into the details, could you actually step back for anybody who might not be familiar with this product and what your proposal is in general? Yeah. Can you talk a little bit more high level for three minutes?

[00:03:06.12] - Anthony Campolo Yeah, sure. The main proposal is to essentially build a Dash payment integration in an AI app that I'm currently building. The app is a content repurposing app, so what it does is it takes audio and video files and repurposes them into different assets. Originally, when I first built it, it was just for things like summaries and chapter titles and stuff that you kind of put in a YouTube description. It has expanded out wildly from that point. The functionality now includes multimodal stuff. You could generate images and text-to-speech, and there will eventually be video capabilities as well. So there will be a point where you'll be able to feed it a script and generate literally a show, like an AutoShow. That's pretty cool. But for now, it's designed to help content creators accelerate their content production through various different means. And I'm not sure how much you want me to go into the finer details of this, but it's been kind of hit or miss in terms of the funding. It was really supposed to be funded for six months, and then it was not funded the first month, it was funded the second, and was not funded the third.

[00:04:40.03] - Anthony Campolo And now we're coming into the fourth, so I'm hoping it will get funded this time. It's pretty much, with a couple tweaks to styling and just some UX things, ready to go to production. So I'm hoping to launch the app by the end of this month. Do you have any specific questions?

[00:05:05.26] - Rion Gull Yeah, so that makes sense. You scrolled through the proposal so people can pause that and read it if they're interested in the details of the proposal itself. Let's switch back to the app. So the idea here is that your product requires credits to use, and I'm gonna scold you right now because I see a little bit of an accessibility issue with your font color here.

[00:05:36.23] - Anthony Campolo I know. That's why I'm saying the styling still needs work.

[00:05:40.04] - Rion Gull But it says send the exact amount of Dash to the address below.

[00:05:44.18] - Anthony Campolo So that would be for this.

[00:05:46.04] - Rion Gull For this flow so you can buy credits. This is an internal credit system to your app itself. These are not Dash credits. These are AutoShow credits that you can purchase either using credit cards or Dash cryptocurrency. So cool that Dash has got the prominent spot there. You're using NOWPayments, so you could expand to other cryptocurrencies if and when you needed to. So I'm putting myself in the seat of some potential user here, and I'm thinking, okay, I like the product, I want to buy some credits. I don't know much about cryptocurrency. If I wanted to, I could just go through the credit card flow. That's always a pain in the butt for me. I always hate pulling my credit card out for stuff like that, and there's a little bit of a security issue with giving my credit card to random people. But if it's using Stripe, then that's not as big of a deal. Sell me on the idea of a general user that is familiar with cryptocurrency but might not have some. Is there any benefit to using Dash at this point other than, you know, is there a price discount or anything like that?

[00:06:58.07] - Anthony Campolo Yeah. So that would be the one other thing that I still need to add, is that you'll get a discount on credits if you purchase with Dash cryptocurrency. So I need to add the logic in for that and some kind of explanation in the UI so that people know that. I forget, I said something in the specific proposal in terms of the discounted rate. I don't think I said specifically how discounted it'll be, but yeah, it'll be like 10% off or something like that if you purchase with Dash.

[00:07:35.16] - Rion Gull Yeah. And one of the things I'd be curious about with this is, you know, this is an example of something that the whole Dash community kind of wants to see, that our Dash currency is used in the real world to buy things. So I would be interested to see stats like one out of every 10 people are using Dash or something like that. Is that something that you can offer?

[00:08:03.17] - Anthony Campolo Yeah, that's included in the proposal as well. There'll be specific analytics for that. I forget exactly where I wrote it in, but yeah, that's included. You'll get insight into how much payments are going through Dash versus the credit card flow, and how much the incentive matters for the users. And we could tweak the incentive, maybe add a better discount if we feel like not enough people are using the Dash option.

[00:08:38.14] - Rion Gull Okay. And then back to the app itself again. Why 1,084 credits? What's that?

[00:08:46.22] - Anthony Campolo That's my current balance. That's just the amount of credits I have in this account right now.

[00:08:51.23] - Rion Gull And so when you're sending 0.051 Dash, what does that get you?

[00:08:59.08] - Anthony Campolo So that's $1 and it gets you 100 credits. And then, if we see here, generating it was like eight credits for the transcription. Depending on what LLM service you use, it's somewhere between like 1 and like 100 credits for different models. So you could do a whole bunch of these if you're using a really cheap model, or you could do one for a dollar if you want the very, very best model. It's one of the reasons why there's a whole lot of different options in terms of transcriptions and LLMs. So if you want to generate a whole ton of show notes really, really cheap, you can do that. If you want to generate a few with a really high-quality model, you can do that as well. So there'll be more explanation in terms of what a credit is worth, with some different examples. Like if you have a five-minute video, it'll cost this much with these kinds of models. There's still more of a walkthrough or some sort of onboarding thing that I still need to build in.

[00:10:06.25] - Anthony Campolo But this is the core functionality right now.

[00:10:10.06] - Rion Gull Cool. All right, so what else did you want to show us on the app itself? And do you have a dark mode? I'm just curious there.

[00:10:19.05] - Anthony Campolo Yes, the styling needs a lot of work. I was working with a designer and wasn't super happy with where it ended up. I built a whole new, fresh version of this that looks really nice, but I need to migrate it over to the new styling. So the app itself will look nothing like this when it actually launches.

[00:10:43.01] - Rion Gull Okay, cool. All right, so what other functionality did you want to demonstrate, if anything, or talk about?

[00:10:51.27] - Anthony Campolo We need to get to the final part where you actually get the show notes. So in the last step, I picked the prompts, which is what you actually generate. And then here is our output. So you get some potential titles, and then you get some lyrics here. It's a fun use case. You can put in any sort of videos and get some rap lyrics from it.

[00:11:23.23] - Rion Gull Can you do the latest Dash Core Group update for us on the fly? Or, oh no, Dash Incubator. Let's see, just do Dash. Yeah, I don't know if Dash Core Group is... Let's... Whoa, 2020. That's the right account.

[00:11:53.26] - Anthony Campolo Okay, so this would be the most recent one.

[00:11:58.05] - Rion Gull Yeah.

[00:11:59.14] - Anthony Campolo Cool. What do you want for the prompts? I'll show them.

[00:12:09.14] - Rion Gull Whatever you think is best.

[00:12:20.20] - Anthony Campolo And there's a bottleneck here that I need to fix as well, because the reason why it's processing is because it downloads the audio and then uploads it to an S3 bucket. That can happen in the background. What I really need to do is just have it immediately give you the prices and the prompts. That's one other thing that I still have to do.

[00:12:43.28] - Rion Gull Got it.

[00:12:45.25] - Anthony Campolo Yeah.

[00:12:46.13] - Rion Gull That wasn't too bad, though. Even that was okay.

[00:12:49.22] - Anthony Campolo Yeah. Okay, so let's do key takeaways and quotes.

[00:12:58.11] - Rion Gull How about a blog, too?

[00:13:00.07] - Anthony Campolo And a blog, sure.

[00:13:06.21] - Rion Gull Alexi says Dash. And Mike Buster says, "I'm just tuning in. Great to see you all." So we're just going through Anthony's AutoShow product here. He's doing the latest Dash Core Group video. And what model are you using for this?

[00:13:35.01] - Anthony Campolo Let's do GPT-4.1. That's a good kind of mid-ground between a newer model that's still not super expensive and pretty fast.

[00:13:52.05] - Rion Gull While it's chewing on that, what do you have to say about AI in general? Is it going to take all our jobs kind of thing? What's your take on this in terms of that?

[00:14:06.02] - Anthony Campolo I think the whole job debate is a little overhyped. Dax tweets about this a lot. Imagine a company gets a 2x boost in productivity. Are they going to fire half the people that work for them, or are they going to try and generate twice as much output? I think it's really not that realistic that just because firms get more productive they're immediately going to fire half their workforce. On an individual level, you're going to be more marketable in terms of your skill set if you at least know a little bit about AI and know how to use it. I think that on a societal level, it's going to have big impacts in the long term and not so much in the short term. People who say AGI is coming in 12 months or whatever, I think all that's crap. But it is definitely a genuine breakthrough in terms of productivity, in terms of coding, and even if you're not a coder.

[00:15:29.07] - Anthony Campolo My wife is a copywriter, and she was very reluctant to use AI at first, but I was kind of nudging her, and now she finds all sorts of ways to be productive with it. So yeah, I think AI is cool. I think that a lot of the naysayers about AI hone in on very specific issues that, if you understand them, you can actually get around, in terms of hallucinations and it not quite understanding things. Obviously it has limitations. It's not God. But yeah, I think people need to get their hands on it and try to find a way to use it for their own stuff, and then they'll find where its edge cases are, where it's actually useful. It should be treated like any other new technology, with pros and cons.

[00:16:20.20] - Rion Gull Yeah, so it looks like it finished there. I see some chomping away in your CLI behind the scenes, but is it...?

[00:16:27.19] - Anthony Campolo That's fine. Yeah. So the key takeaways were ongoing improvements and major updates across DCG products. Significant progress has been made on tools like Dash Evo Tool, Dash Core, and SDKs. The focus is on usability, bug fixes, and cross-platform support. They're attentive to community feedback, blah blah blah. SDK development is accelerating future integrations. Recent advancements in SDKs, especially the Rust SDK, CFFI bindings, and Swift wrappers, are enabling greater platform compatibility. And then automation and AI are enhancing productivity. Using AI-assisted tooling and automated backporting agents is rapidly increasing development speed and reliability, notably in complex areas like code backporting, verification, and multi-language SDKs.

[00:17:15.11] - Rion Gull That's interesting. Sounds kind of self-serving for the AI to talk about.

[00:17:22.21] - Anthony Campolo And then these are quotes from the actual thing. One is that if you made a token with a direct purchase and you were also the seller, it caused a mismatch of credits. Situations that cause something really bad like that, we try to halt the chain on purpose to make sure that it gets resolved.

[00:17:40.17] - Rion Gull That sounds important. Okay, so how'd the blog post turn out? Just real briefly, and then I think...

[00:17:46.19] - Anthony Campolo Yeah, so the blog, it's a blog outline, I think. Oh yeah. So it gives you an outline, then a first draft.

[00:17:54.21] - Rion Gull Okay.

[00:17:55.07] - Anthony Campolo So do you want to see the outline or the beginning of it?

[00:18:01.20] - Rion Gull The outline's pretty good. Yeah, I see.

[00:18:05.10] - Anthony Campolo Cool.

[00:18:06.26] - Rion Gull What else did it spit out? Just want to scroll down to the very bottom so we can see all of the output.

[00:18:14.26] - Anthony Campolo Let me go to the system where you see it. Again, all the styling is going to change. This is just the raw data you get. It's not rendering the markdown or anything, and that will obviously be fixed as well. But this is the full output. So the key takeaways, the important quotes, and then the blog outline. Those are the three prompts that we picked: blog outline and blog draft. And then all the way down here you get the actual transcript, so you could read through the whole transcript of the thing if you want. That goes on for a while because it's about an hour. And then the original prompt we used to generate it. So if you wanted to tweak the prompt and rerun it, you could do that.

[00:19:02.14] - Rion Gull Very cool. Splawik says, "Hey guys. Anthony, nice to see the progress on AutoShow app. It simply works. Nice."

[00:19:14.11] - Mikhail Cool.

[00:19:14.24] - Anthony Campolo Good to hear.

[00:19:16.26] - Rion Gull Yeah, this looks good. So you said you're hoping to launch this live by the end of the month. That's nice. Dash payments are working, and I think at a bare minimum that's somewhat good advertising. I know you have a pretty wide audience of key influential people in the Web2 space. So just them seeing the word Dash, there's value there even if they don't use it. But yeah, that would be cool to see what kind of discounts result in what kind of conversions. So anything else to say? And then we'll go over to the SDK stuff after. Final thoughts?

[00:20:11.05] - Anthony Campolo Just that if people have any questions or comments, hit me up. And yeah, hoping to move forward with this.

[00:20:21.11] - Rion Gull Okay, cool. All right, so moving on to SDK discussions. So for a while now we've been... Anthony, just as a segue, you know, we had 10 or 15 people from your circle of developer friends test. Yeah, we're gonna do that again at some point. Yes. I did one more additional one recently with one of my developer friends, and things are still basically the same. But we obviously do need an improved JavaScript SDK to work with, and so that's what we've been working on with both Matt and Mikhail. Mikhail, do you want to start us off with the approach that you're taking to do your SDK stuff? You have a proposal as well. You had one a couple months ago, as far as I remember, and you have a current one for this coming month. So do you want to talk about what you're working on?

[00:21:36.02] - Mikhail Right, right. Yeah, I wanted to show the whole progress, what we did and what the proposal is about. Where is it? SDK. Yeah, so the SDKs that we do consist of two parts. The first part is the actual SDK that can create transitions. It can make queries to the DAPI and stuff like that. It's a pretty simple part.

[00:22:14.10] - Rion Gull Sorry, can you bump up the font about four notches?

[00:22:18.03] - Mikhail Yeah. Right. So there are two parts. The first part is the actual SDK, which has all of the methods for web developers. The second part is the wallet, which will keep your identity private key secure and can hold your identities. What we want to do on the web basically is give developers a way to connect the wallet, connect the mobile wallet, or connect through an extension. An extension is also a wallet. Developers want to simply, through JavaScript, connect their wallet and then create some transactions and ask the wallet to sign it. Because we really don't want to ask users for private keys or seed phrases on the dApp application itself. Otherwise, you would have to ask the user for secure information that can be very easily leaked. So what we did in the previous months, the last two months, was work on the JS SDK and the Dash Platform extension. The first one is pretty much done for the regular operations like creating transactions, signing them, basically the basic document stuff on Dash Platform.

[00:24:01.29] - Mikhail Yeah, so we did that with the help of the Wasm DPP. There is a DCG Wasm DPP which doesn't work really well. It has certain limitations, it has certain complexity, and we were trying to improve it in the beginning of the year, but the effort was too much to refactor all the things and stuff like that. So we did a completely different Wasm DPP project, which basically uses the Rust code, the Rust DPP, and bundles it into WASM bundles. These WASM bundles get loaded into the JS SDK. So the SDK is using that Wasm. It adds some complexity when you work with JS, but at least we have something to work with. It let us build an SDK which weighs not really much, like 3 megabytes. It's optimized. It has all of the typing system. Recently we added all of the types. So when you use it, you can use TypeScript or JavaScript. If you use TypeScript, you have all of the types, so the autocompletion works and you always see what methods, fields, and classes are available. Right now we just recently migrated it to Dash Platform v2.0.

[00:25:53.07] - Mikhail I'm talking about the DPP layer because it's the most significant part. We upgraded it to Dash Platform v2.0. It's working. We have added all of the token transitions there. We have added the data contract methods to work with the data contract, to create a new data contract, one which has tokens, like to create tokens and mint tokens. I haven't yet exposed it in the Dash Platform SDK itself, but it will be pretty quick. I just need to create functions and execute the methods of the DPP itself.

[00:26:36.05] - Rion Gull Okay, do you mind if I give a little bit of a high-level explanation for those people who might be wondering what all these acronyms are talking about? It's a little tricky because people who are developers probably know what's happening, and people who aren't developers probably won't know what's happening even after I try to explain it. But I'm going to give it a shot. So Dash Platform has some functions that you can call to the service side or the network side or the blockchain side. It exposes certain methods, certain functions that you can call. It does that over, not JSON-RPC, but gRPC. In order to get the structure of the data correct to do those function calls, you need to know what the structure of the data is. What fields do I need? What kinds of data does it accept? What are the types of those fields? And that's what DPP is all about, correct? That's what DPP stands for, Dash Platform Protocol, and it tells you the data structures and the function calls that are supported by Dash Platform.

[00:28:07.17] - Rion Gull And that's language-independent. Any language can implement those data structures. Currently, the easiest way to do that is using WebAssembly. That's what Wasm is referring to, WebAssembly, because JavaScript engines support WebAssembly to execute those functions. So instead of executing them in pure JavaScript, like literally writing JavaScript code and then throwing that through the JavaScript engine and having that send that up through gRPC to Dash Platform, you can do it through WebAssembly as well. Rust is specifically a good language that spits out support for WebAssembly pretty easily. So that's the approach that you're taking. You're not writing a JavaScript SDK from scratch. You're creating an SDK that is WASM-based, and that by nature is supported by JavaScript engines. What did I get wrong? What did I miss?

[00:29:24.28] - Mikhail Well, I wouldn't say that. I would say it's still a JavaScript SDK, but it internally uses Wasm, WebAssembly, to create transactions, sign transactions, decode and encode stuff like that. It's still a JavaScript SDK.

[00:29:44.12] - Rion Gull And the end result of that is that you get a big WASM bundle that you said was 3 megabytes, which is a significant improvement over the existing SDK, but still quite a bit bigger than what most JavaScript developers would be used to. 3.66 megabytes. I think what matters probably more to people is how quickly it performs than how big it is, but those are just some aspects of the trade-off.

[00:30:19.27] - Mikhail Yeah, yeah. It will be slightly increased when we implement proofs in the Dash SDK because proofs are also WASM-based. So I think it will double in size, but it's the least that we can get right now.

[00:30:37.02] - Rion Gull So the last time I looked at the, I looked at your proof package and I thought I saw that was 13 megabytes.

[00:30:46.19] - Mikhail And you're saying, yeah, stuff like that. Yeah, it will be optimized.

[00:30:50.13] - Rion Gull It can be optimized.

[00:30:51.19] - Mikhail Yeah, yeah. I think it will be something like 5 megabytes or 6 megabytes. The problem is not the size itself, because when you use WebAssembly you can't just use regular imports from packages. You have to download the whole WASM binary, the whole WASM buffer, and then compile it at runtime and use it in JavaScript. So you have to pass down the compiled instance instead of just importing your function. That's one thing. The second thing is that it has to be downloaded, so the page will be loading. You can't use functions until the page is loaded, but the WASM is still not there and you'll always wait until it downloads. But with that size, it's pretty much acceptable.

[00:31:50.09] - Rion Gull Yeah, and I was just going to ask you, you did some of this, but I'll probably ask the question anyway. Can you describe the user experience that you're targeting here for both application developers and the users of those applications that the application developers build? Is your target something like the developer creates an application that talks with an extension that all of the users of that application are expected to have installed? Or give us an idea of the high-level user experience for both that developer building an app and the users of those apps.

[00:32:40.06] - Mikhail So yeah, the Dash Platform extension will be targeting two types of people. The first is obviously regular users who own a seed phrase, have identities, want to create documents on dApps, want to buy tokens, and stuff like that. So it's basically a separate wallet. It's a wallet which allows you to keep your identity safe while allowing JavaScript to request some information. For example, developers would like to retrieve a current identity ID from your account. You have chosen one identity, right, and you want to use it on the dApp application. So we have to have some kind of interface which allows you to retrieve that data, and this is where Dash Platform Extension comes in. There is a public interface done through some sort of messaging layer which allows you, for example, to request a transaction approval.

[00:33:53.24] - Mikhail So you just ask, "Here is my state transition, I want the user to sign it," and then the dialog on the user will pop up and the user can either reject or sign it. I was building this extension keeping in mind that we would possibly like to use a mobile app instead of putting the seed phrase in the extension itself. It will be possible in the future, but in order for us to have it, we will need some kind of interface from the mobile wallet to exchange that information, to request signing the transaction. It could work through QR codes, so the dApp would just ask to sign a state transition, but instead of rejecting or signing it there will be a QR code which you just scan with your mobile and approve from the Dash wallet, from the mobile Dash wallet. And the second type, the second group of people, is actually the developers who want to build dApp applications. It works by injecting some small amount of code into the web page.

[00:35:31.05] - Mikhail And once you visit some dApp application on the domain, it will be possible to connect your wallet, and a similar dialog will pop out. The SDK itself works pretty much like this. From the developer's perspective, you first install the SDK, or if you're using the Dash Platform extension it's already there in the window. So wherever you visit any page it gets injected, but later we will change it so only approved dApps will have the Dash Platform SDK code injected. You have some data. For example, we want to create some document. We have our identity identifier, data contract, and which document type we want to post this data in. Then you request the identity contract also, which is needed to create the document. Then you ask Dash Platform to sign it. It's currently integrated straight into Dash Platform SDK, but it can be moved out separately. So basically the transaction that you ask Dash Platform to sign could be made by any application.

[00:37:08.26] - Mikhail Not only by Dash Platform SDK. It could be made by a mobile application or any other SDK, and we can simply pass it to the same interface. So internally, I would like to tell you how it works internally. Oh, wait a second. Yeah, it's a different branch which has all the code right now. So internally, all of your keys, for example, you import your private key or your seed phrase into Dash Platform Extension. We just made the feature so it will all be kept encrypted. Once you get into the Dash Platform section, it will ask you for a password to set. You set the password, and then all of the secure information like private keys and seed phrases will be encrypted with it. Dash Platform Extension itself runs in a separate context. So we have two contexts right now. We have the web page, and it has the Dash Platform extension.

[00:38:36.24] - Mikhail Any information we put there, for example the private keys, doesn't have access to the regular web page, and the regular web page doesn't have access to the Dash Platform Extension context. So I built two sets of APIs. The first one is used inside the extension itself to get information about your identities, for example a list of your identities, stuff like that, like your transactions. Transaction data is actually required by Platform Explorer right now. But anyway, it's a completely different set of RPCs. If the regular user gets hacked and some malicious code is there in the browser, this code will not have any access to the Dash Platform internal things. It has only a public interface which allows you, for example, to connect the application or request state transition approval. Internally there are all the other RPCs needed in the Dash Platform extension, like create identities, import identities, create wallets, switch wallets, and stuff like that.

[00:40:22.21] - Mikhail So yeah, I made it pretty much secure to use. Private keys and seed phrases are encrypted. Of course, you can look into the application and see the storage, but all of the important information will be secured. Users can inspect the stored data manually, but it doesn't get shared with regular web pages.

[00:40:47.10] - Rion Gull Do you have a sample app at this point that does connect with the extension?

[00:40:52.24] - Mikhail No, not yet. This functionality will be done next. So it doesn't have the functionality to connect your app yet. What connect app does is write the dApp application that you authorized access to into the internal database. When people visit the dApp application and try to use, for example, request state transition approval, it will only work if the user approved that specific dApp application inside the extension. On any other page these methods will not work. So it's another layer of security.

[00:41:58.26] - Rion Gull How far do you think you are from being able to create a very simple web page that connects with the extension and does one simple thing, say creating an identity?

[00:42:13.17] - Mikhail Right. Yeah, it's already working. What we did last time was this flow where you can create a document and ask the extension to sign it. We reworked the UI interface. So right now it's mostly the same, but it has a reworked interface and

[00:42:39.19] - Anthony Campolo We...

[00:42:39.25] - Mikhail ...are very close to finishing it. So what I did was a really huge refactoring of the code, and right now we are trying to adapt the front end to the new code changes. I can't show you the work right now. We're still finishing stuff. We need to make it in the final bundle, test everything. But we expect to have a solution with a single identity, and you can import the private key instead of the seed phrase. We will have it this week. So we will release a first testing bundle, an open testing release, which people could use to see how it's working on testnet.

[00:43:33.11] - Matt Okay.

[00:43:34.17] - Rion Gull Halawi says, "This is the WEN SDK edition." And Alexi, who I believe is your developer...

[00:43:42.10] - Matt Correct?

[00:43:44.15] - Mikhail Yeah.

[00:43:44.26] - Rion Gull Alexi, he's one of your developers. I think that we'll be able to attract regular users to use the platform, not just developers. Indeed. So, all right, that's a good overview of what you're working on. I am eager to see the Hello World application working with the extension to do something on platform like creating an identity, a contract, or a document. And speaking of which, Matt, did you first of all have anything else to add, Mikhail, before we move on?

[00:44:30.00] - Mikhail Yeah, I want to talk about the plans, about the proposal. So basically what's included inside this proposal?

[00:44:39.16] - Rion Gull And by the way, just real quick, we are going to have a discussion about proofs with both you and Matt at the end here because I know that's an important part to discuss. But yeah, I want to do that at the end after Matt's done some of his presentation. And after you're done with... Can you bump up the font on this so that people can read what you're...

[00:45:02.20] - Mikhail Yeah.

[00:45:04.08] - Rion Gull So go ahead. Go ahead, Mikhail.

[00:45:06.08] - Mikhail Yeah, so this week we will release a first Dash Platform Extension release build, and it will allow you to import an identity via private key. It will not allow you to create an identity or import a seed phrase, but it will showcase the minimal functionality. What we plan to do is add seed phrases so you could import your existing seed phrase and see all of your identities. We want to implement registration of identities so people who don't have identities yet will be able to register their first identity through the extension. This Dash Platform Extension will have multi-wallet support, meaning people could change their seed phrases and have different wallets. For example, one could have a seed phrase wallet. You could have a keystore wallet if you don't want to mess with seed phrases. You could have your identities stored on your Dash Evo Tool, but have some specific private keys imported into Dash Platform Extension. The SDK we are kind of finishing, I believe, because we have a proof of concept for WASM proofs working that we are going to integrate.

[00:46:47.28] - Mikhail We need to integrate the token transitions. That wouldn't take too much time, I think maybe a week or less. You would just need to expose methods in the SDK itself. We will test everything on testnet and mainnet, both the SDK and the extension. Right now the extension works only on testnet, because that's what we've been working with. Finally, the SDK documentation. And there are also a lot of screens that we need to make with our designer for the new screens that our front-end dev Alexi will be implementing, like the seed phrase flows and a reworked home screen, which will include more information like send credits and withdraw credits. So we need screens for this front end, and that's another thing this proposal will be budgeting. Yeah, I think this is it. Yeah. Okay. Did I tell about the proofs? Yeah, we will integrate proofs as well. Yeah.

[00:48:14.07] - Rion Gull Thank you for breaking that down into weekly things. From my perspective, I would love to have you on Incubator Weekly, maybe not every week, but every other week to demonstrate your progress on this. The second week showing proofs integration in SDK seems ambitious to me, but if you can pull that off, great. Anything else that you wanted to add before we move over to Matt?

[00:48:45.08] - Mikhail No, I think I'm good. I think I discussed everything I wanted.

[00:48:52.23] - Rion Gull Okay. All right, Matt, let's bring up your screen here. Anything that you wanted to add or talk about with Mikhail before you move on, or just general statements, or do you just want to jump right into your demo?

[00:49:15.25] - Matt Yeah, I think the work that Mikhail's doing is wonderful. Being able to get an SDK into the hands of developers now is really important. Getting an extension out there that people can actually trust and use, and don't have to trust every silly little application with their private keys, I think is super important. That's all work that I wanted to do before I even heard Mikhail was doing it, and I'm glad that he's doing it because I don't want to do it myself. But yes, I think everything that's happening there is awesome. So good job.

[00:49:47.12] - Mikhail Thanks.

[00:49:51.10] - Matt So did you want to prompt this or should I just get going on proofs?

[00:49:58.01] - Rion Gull Yeah, I'll say just a few words about the compare and contrast. So Mikhail, like we talked about, is focusing on doing a WASM-based SDK, and you are focused more on doing JavaScript-native code without WASM, which has trade-offs. One of the big benefits is that it's much smaller and potentially supported in more environments, for example, and a little bit easier to use, potentially quicker to load, things like that. But I think this month is going to be critical in figuring out between the two of you where the lines are and where the overlap is with what you're working on. Because I think there are certain things that you're both building that are kind of the same. The analogy that I drew yesterday was that you're both kind of building a motor, an engine, where one of them is an internal combustion engine and one of them is an electric engine, electric motor. They both kind of do the same thing, but they do it in different ways and they have different trade-offs.

[00:51:28.25] - Rion Gull And it's not clear yet to me where the overlap is, whether these will end up being two different products or whether they can merge into one product. I think there are pros and cons to both of those approaches as well. To some degree it's good to have competition between products that are competing for the same thing, but that takes a little bit more resources. On the other hand, it could be better to just have one product and focus all the resources on that. So there are trade-offs there. But I think we've made enough progress on both sides that it does make sense to me to have both of you pursuing this and to see where those lines end up, and which products fit better into which environments and use cases. So yeah, just go ahead and demo. We can talk more about that later if we want, and if anybody has any questions about that, please feel free to ask.

[00:52:45.20] - Rion Gull But go ahead. I wanted you to at least show a little bit of a review, like a three-minute recap of what we did in the last show that I had on with you, where you created an identity and then a data contract and then a document using your libraries in Node.js and/or the browser.

[00:53:11.08] - Matt Yeah, so this is just everything that I showed last week. I don't know why it is refusing to allow me to move this window. What is going on? Okay. I don't know what is happening. I'm sorry. I am trying out a new browser. I don't know if you've ever heard of Arc. It's nice, but it's really misbehaving right now, so I don't know what is wrong.

[00:53:50.14] - Mikhail We can see some video. You're sharing the different display thing.

[00:53:54.09] - Matt I know. I'm showing a different window. I'm trying to move this one and it won't let me do it. And now it's split and I can't even unsplit it. So not impressed.

[00:54:09.20] - Rion Gull Owl says hi.

[00:54:13.20] - Matt We have something now. I got it moved. This is just something I showed last week. It's just the identity creation stuff that we had. I think I was doing like 42 last time. I think I was doing 41. It's asking me to create the identity. This is stuff that's been demoed a couple of times. I can fund this and then it will create an identity. I have not yet fixed the issue with asset locks. At this point, I'm not going to actually try to create one. But you can see that at index 40 on the wallet, I already have an identity, and we can use that index to create a data contract. And of course something is broken, so maybe we're not going to be able to demo this today. I've been messing around with my code base too much. But long story short, I have the code working in a browser most of the time.

[00:55:13.02] - Rion Gull People can review the previous video.

[00:55:15.13] - Matt Look. Go look at my last video.

[00:55:22.13] - Rion Gull Yeah. So what else did you want to discuss?

[00:55:28.27] - Matt Sure.

[00:55:29.09] - Rion Gull Yeah, because I at least want to discuss the proof system, because that's one of the major things still in the roadmap. With you having done the create identity, create data contract, and create document against that contract, that's showing that there's a very clear light at the end of the tunnel as far as getting Dash Platform support in your JavaScript SDK. It's just a matter of creating more convenient abstractions on top of that for a better developer experience at this point. But what else did you have to talk about, if anything, before we move on to the discussion of the proof systems?

[00:56:21.08] - Matt Well, I guess we were going to talk more about extension, or we were going to talk more about SDK integration stuff a little bit later, right? Or do you want to do that now and do proofs after that?

[00:56:32.23] - Rion Gull Either way, whatever you think is best.

[00:56:36.04] - Matt Well, I'll show you what's on the screen now. Proofs keep coming up every time we talk about the JavaScript SDK that I'm building. Every time I mention it, somebody says, "What about proofs? What about proofs? What about proofs?" Why do we even care? For example, what if I called the Dash API and this was the implementation of the get balance function? I say, "Hey, what's my identity's balance?" and it says five. Cool. How do we know that that's right? How do we know that's correct? How do we know that's up to date? That's what proofs are all about. Proofs are all about what the Dash network quorum actually believes your identity balance is right now at the latest block.

[00:57:26.26] - Rion Gull Why don't you describe how you get that data in the first place?

[00:57:30.14] - Matt Yeah, so I think it's this one right here where I'm getting a slightly different thing. I'm asking for the nonce. We find an existing identity, and once we get that identity, then we send this RPC call directly to one of the platform masternodes and we say, "What's my current identity nonce or balance or whatever?" So we're sending a message over the internet, and it sends it back and says, "Here's what your balance is. Here's what your nonce is," whatever you're asking for. In this case we asked for it, and then it says, "Here it is."

[00:58:13.28] - Rion Gull That one node said, "Here's what it is."

[00:58:16.07] - Matt That one node said that's what it is. You gotta think about maybe we don't want to have those nodes publicly accessible at some point, because that means they're easily targetable by denial-of-service attacks and things like that. So maybe at some point in the future it's not actually a masternode. Maybe it's like a follower that just has all the data, has access to everything, but it's not one of the masternodes and nobody cares if it goes down because it's not important for the network to function. So there could be a front-end caching node that we're asking instead. The point is that shouldn't matter. We should always be able to get a proof that the network actually believes that is the correct value, and that's what a proof is.

[00:59:11.17] - Rion Gull Let's rephrase that again, or emphasize it again. What a proof is, is proof that not only a single node thinks some data is some value, but also the whole network accepts that that specific data is a specific value.

[00:59:29.16] - Anthony Campolo Right?

[00:59:29.28] - Matt Correct. And if you use that information to create a transaction, you'd be guaranteed that that transaction is going to work unless something else has changed in between you asking and getting that. But assuming you're the only one that has access to that key and you send a transaction, you should be guaranteed that it's going to work because you just asked the network what your balance was, and you know that's actually what your balance is. So in this case there are two different options you can get. You can ask it to just give you your balance or your nonce, and in that case it just gives you a number.

[01:00:45.06] - Matt But you can also ask for a proof. When you get a proof, it's this giant pile of cryptography stuff that you have to look through and check that the proof actually does say what you expect it to say based on what you asked. Every time we talk about the JavaScript SDK, they always ask, "Well, what about proofs? What about proofs? That has to be done." I've heard this so many times, and people seem to think it's super hard. I still kind of think it's not that hard. It's definitely work, but it's not impossible to do. So I decided to just try it and see how far we can get. I want to preface all of this: this is very rough. This is not complete. It's not checking everything it's supposed to. It's more of a proof of can it be done rather than is it good yet, if that makes any sense. So this is some code that's walking through an example. This is actually the same, I don't know if any of you saw, but Mikhail posted the proof of concept with their Wasm proof bindings that they're going to be using in their SDK in a few weeks. This is actually using the exact same identity and the exact same proof that they were verifying, just to show that this is a real example of something. All of that proof information is in this file that we're reading. Then what we do is there are a couple of layers to this proof. The main layer, the layer that goes to everything we were talking about, is: does the quorum actually believe this? Is this what the quorum actually knows to be true?

[01:02:06.11] - Matt And the way that you get that is the quorum has a public key that they all kind of work together to make signatures that follow this public key.

[01:02:15.20] - Rion Gull It's a quorum public key in the sense that the whole quorum has to prove this thing.

[01:02:24.12] - Matt The nodes all have to work together in order to produce these signatures that match this public key. There's some threshold. I don't remember how many nodes have to work together. Some percentage of them have to work together in order to do this. So these are BLS signatures. You don't need to know what that is. It's a cryptography thing. But long story short, we're passing the signature from the proof and this other hash in, and making sure that the public key matches the signatures. We'll go backwards.

[01:03:01.09] - Rion Gull It says it prints out verified at the end, I saw.

[01:03:03.25] - Matt Right. It prints out "verified: true." Just to talk about what things would go into this, and I'm not an expert in all of this, so I'm just explaining what I understand here. We have this structure called a canonical vote. I think the thing that we need to care about right now is the state ID hashes here. We also know which block it came from. We have the hash of the block. We have the height of the block, so we know where that's coming from. We also know which chain ID that comes from. But then there's a state ID hash, and the state ID has some other metadata in there, like what time it was made, and again the height. But we also have this root hash. This root hash is the root of the GroveDB Merkle tree that has all of the data that the platform has stored in it. That's what this hash is referring to. You have to have all of the data, or at least a portion of the hashes, to be able to create this hash. So then what we do after that is we take it apart.

[01:04:19.14] - Matt The proof comes in layers. Let me show you here what we're doing. When we ask for the identity balance, what we're doing is asking for a subset of this database, this Merkle tree, where we just want a piece of it. We don't want the entire database. We just want the piece of it that proves that we're getting the part that we wanted. So what the platform code does here is it creates a path. Sorry, this one. We have this root tree, and there are a couple of different kinds of trees in here. We specifically want the balances. So we're going to go into the balance tree, which is 96, which is 60 in hex. Ninety-six is in decimal. So we're going to go down this path, the balances path, and then we're going to ask for this particular identity in the database, which you would have known because you asked for it. This is the hard-coded identity that was given to me. It only just now occurs to me that this doesn't match, and I think that's because it's being encoded in a different way.

[01:05:40.17] - Matt This is base58, whereas this is hexadecimal. But anyway, we're asking for that identity in this path. What we get back is a proof that takes apart the Merkle tree for just the parts of this that we asked for. So at layer one we're going down 60, which is the balances tree. Then at the second layer we're going through and looking for that particular identity ID. Inside that identity ID we have this value. This value is encoded, and we take that apart and get this as our current balance. The important thing is that we have all the hashes for everything on all the different sides of the tree, and the balance down in the middle. As we recombine the hashes all the way up the tree, we zip it back up and get to the same root hash that was encoded in that proof. You can see here that this hash is the same root hash that was encoded in that state ID. I know that was super confusing and all over the place. This is very bad code. I did this last night, really late at night, getting all this working together.

[01:07:00.24] - Matt So please don't think this is the final state of everything. All I'm doing is showing that we can take apart the proof, find the information inside, and verify that it's all there. Very much not done.

[01:07:16.20] - Rion Gull Yeah, well, you've actually taken it further than I thought you would. I had no idea that you would be working on proofs even yet. So the fact that you've got the proof of concept for proofs relatively worked out as a proof of concept, that's significant in my opinion. And I know that you've mentioned several times before that proving something involves more than just comparing Merkle hashes and seeing that they're the same.

[01:07:49.15] - Matt Right.

[01:07:49.24] - Rion Gull Do you want to talk about that? I also know that you've got a stop coming up soon here, so I—

[01:07:55.21] - Matt can do that real quick.

[01:07:56.16] - Rion Gull Give us that explanation real quick, and then I have some things to say. You can feel free to drop out when you need to, though.

[01:08:05.00] - Matt So the analogy that I want to give here is, if you go to the airport and you try to get on an airplane and they ask you for your airplane ticket, what they're asking for is proof that you're allowed to go on that airplane, proof that you paid to go on that airplane. If you hand them your driver's license, that is a valid proof that you are allowed to drive a car in that country, at least as of whatever date is on that driver's license. It is not an airplane ticket. And if they ask you for an airplane ticket and you hand them your completely valid driver's license, they're going to look at you funny and they're going to kick you out. It's the same kind of thing here. We're getting a proof. We can verify that the proof came from that quorum. We can verify that the hashes they gave you are correct. But if you don't check that the hashes they gave you are for the identity you asked for, you're getting the wrong proof. And it doesn't matter how valid that proof is. If you don't verify that it is the right proof for the thing you asked for, then it's not actually helping you.

[01:09:20.02] - Matt So that's the three parts. I say that we need three parts to this. We need to verify that it came from the quorum's public key. We need to verify that the hashes all validate to the same root hash. And then we have to verify that the query matches the proof. The query matching the proof is a little bit tricky because these queries can include things like range queries. These proofs can be combined. If you, for example, ask for your identity and a document at the same time, the proof is going to have both pieces of information in it, and you need to be able to check that all the parts you asked for are there. There's some tricky stuff there. If there's an index in a data contract and you ask for all the names that start with B, for example, the proof is supposed to show you not only all of the names that start with B in that proof, it's also supposed to show you the names that start with C, one of the first names that starts with C, and it's supposed to show you the last name that starts with A. That way you know it didn't skip some of the Bs and only show you some of them.

[01:10:30.03] - Matt So there's a lot of nuance there to making sure that you actually got the query, or that you actually got the proof you're supposed to. In my code I'm printing out all of the information. You can see it all in the terminal. I'm not actually checking any of it. That stuff is definitely not done yet, and it will need to be done before we can say that this is ready. But what I'm showing here is that we can do it in JavaScript. I understand what's going on. I can write the code for it if I can get funding to do that.

[01:11:04.07] - Rion Gull Yeah, and right now we're going to be working on proofs even if my proposal does pass to get you to continue to work on this throughout this month. But the plan would be that next month you submit your own proposal to continue the work. So this month will be kind of like extending the proof of concept to something that's more usable to developers. I know that this proof stuff is very nuanced because for a lot of people the proofs aren't even really necessary in order to get some of the value out of what Dash Platform is giving you.

[01:11:50.15] - Matt If you don't care about trust, you don't need proofs.

[01:11:53.04] - Rion Gull Exactly. And a lot of my target market with Web2 developers, they aren't going to care a lot about any of this. So even if we didn't get the proofs done, the fact that you can create a schema, which we call a data contract, on Dash Platform in a permissionless way, and all you have to do is pay a few cents to do that, it's a very simple-to-use SDK. You can verify by going to platformexplorer.com, which Mikhail made, and see that, hey, that thing that I just wrote in code, it actually showed up in somebody else's interface. That's proof enough for me that things are working. Then I can have the users of my app create documents against that schema. All of that is extremely valuable if you can wrap it in a good developer experience, even without these formal proofs. I just wanted to mention at the very end as well that this proof system is like icing on the cake. But don't forget that the cake is valuable and nice to have even without the proofs.

[01:13:01.08] - Matt Proofs will never add functionality.

[01:13:04.14] - Rion Gull Exactly.

[01:13:05.05] - Mikhail So.

[01:13:05.17] - Rion Gull So the proof system in general as a whole is more about the Web3 crowd that really has some absolutely necessary critical data application where you need the proofs for very specific reasons. I do think there are valid use cases for that, but I think there are a lot more use cases that are going to be achievable without proofs. But you still want a good developer experience. Developer experience is, in my opinion, even more important than some of the proof stuff. If we can get it all, great, but with limited resources you have to prioritize certain things in certain orders. I think that's about all the time that we have today, but I wanted to open it up to anybody else to say anything else they wanted to. We also have Top Shelf Anarchy saying, "Hey Dash folks, y'all should pursue getting Dash on Cake Wallet." Which, you know, sure. It's a permissionless system also, so feel free to integrate it if you are part of Cake Wallet. But anything else that anybody else wanted to say? Any questions from...?

[01:14:24.05] - Mikhail Yeah, I have a question to Matt about this verification that has to be implemented. What do you expect? How much of the work is necessary? One month? Two months? Do you have any expectation for how easy it will be?

[01:14:45.23] - Matt That is a very good question. I think if I was able to work on this full time, I could do it in less than a month, maybe a month. I don't know. It's hard because if I was going to come on the record and say that I actually trust this code, I would want to be really darn sure that everything was there. I would want to have tests for all the edge cases. It's not nearly as easy as what I've just shown here, which was mostly just taking apart everything and hashing it again. So I would say a month is probably decent if I was only doing proofs the whole time. I could do that.

[01:15:37.09] - Rion Gull And I would probably add to that

[01:15:38.26] - Mikhail that,

[01:15:41.04] - Rion Gull you know, having proofs for the whole surface area of platform is one thing. With all of the edge cases ironed out, that's one thing. Having ironclad proofs for three things, that's another thing. I don't think it's going to be this thing where there's a specific deadline and you get all of the whole surface area done. It would be more of a gradual thing where after one week you've got a very good proof system for creating an identity and verifying its balance.

[01:16:11.15] - Matt Absolutely. We don't need to do the complicated range queries for things like just checking an identity balance. So that verification is much easier.

[01:16:26.06] - Mikhail Great, great. That's really, really nice to hear all of this.

[01:16:35.00] - Rion Gull Okay everyone, thanks for joining our show today. There are, or at least should be, more questions about this SDK stuff because there's a lot going on. But I'm very confident in both of you guys. Mikhail, you and your team are doing a great job with your approach. Matt, I have full confidence that you can accomplish anything I throw at you. That's been my experience so far, and actually more than that. So yeah, just thank you guys both for your work. As far as I'm concerned, I just want a good product that I'm not embarrassed to share with people that have high standards, and I think that's the kind of standard that I have. So yeah, we'll see how things go in the next few days as far as funding goes, and we'll keep plugging away. Thanks everybody for joining us, and join us next time for some updates from both of these guys. Anthony, hope your proposal goes through well as well, because getting real products in front of a good, wide developer audience is very important too. So catch everybody next time. Thanks.

[01:17:52.26] - Mikhail Thanks.

Related Links

• AutoShow + Dash | March Update - Mid-development status update covering payment mechanics, the credit system, and platform experiments, providing direct context on the challenges leading up to the June demo
• AutoShow Dash Integration - The original proposal pitch where Anthony presents the AutoShow and Dash integration concept to the Incubator, establishing the foundational business model demonstrated in this episode
• Dev Updates | Mikhail, Anthony Vijay, Rion, Matt - The directly preceding update episode featuring the same developers discussing SDK progress, treasury voting, and AutoShow development momentum
• AutoShow Types with Dev Agrawal - Technical deep-dive on AutoShow's TypeScript architecture and CLI pipeline that provides context for the codebase structure the team is building on top of
• Goose with Rizel Scarlett and Ebony Louis - Rizel Scarlett and Ebony Louis from Block demo Goose, an AI agent built on MCP—adjacent AI automation tooling that parallels the developer workflow themes discussed in this episode