Dev Updates | Mikhail, Anthony Vijay, Rion, Matt
Dash Incubator developers demo AutoShow's AI content app, Bitcoin backport progress, a new lightweight platform SDK, and discuss treasury voting scenarios
Episode Description
Dash Incubator developers demo AutoShow's AI content app, Bitcoin backport progress, a new lightweight platform SDK, and discuss treasury voting scenarios.
Episode Summary
This episode of Incubator Weekly brings together four developers—Rion, Anthony, Vijay, and Mikhail—to showcase their current work and proposals on the Dash network. Anthony demonstrates AutoShow, a content repurposing application that transcribes video and audio files and processes them through various LLMs to generate summaries, chapters, and creative content, with Dash payment integration running on testnet and nearly ready for production. Vijay walks through nine merged pull requests focused on backporting Bitcoin improvements to Dash, covering bug fixes, thread safety, integer overflow protection, and code maintainability, while appealing to the community for continued support of this essential maintenance work. Mikhail presents the most technically ambitious update: a rewritten, lightweight Dash Platform SDK that reduces the WASM layer from roughly 10 megabytes to under 3, works across browser, Node.js, and React Native environments, and pairs with a browser extension prototype that functions like MetaMask for signing platform transactions. Rion then outlines Matt Peterson's parallel work toward a pure JavaScript SDK generated from Rust source code, aiming for even smaller bundle sizes and full type safety. The episode closes with Rion walking through treasury voting scenarios, arguing that SDK development should take priority over a proposed third-party marketing initiative until better developer tooling is in place.
Chapters
00:00:00 - Introduction and Proposal Overview
Rion opens the show by welcoming Anthony, Vijay, and Mikhail, noting this is one of the most developer-packed episodes in recent memory. He briefly mentions an upcoming Twitter Space hosted by Joel that combines several digital cash communities, with this week's topic being stablecoins. Rion sets expectations for a 50-minute to one-hour runtime and outlines the agenda.
Each of the guests has an active proposal on the Dash network, and the plan is to have each developer present their work in sequence before Rion shares closing thoughts on treasury voting dynamics. He notes the tight monetary situation in the Dash community and frames the episode as both a technical showcase and an opportunity for masternode owners to understand what each proposal delivers.
00:03:14 - Anthony's AutoShow Demo and Dash Integration
Anthony presents AutoShow, a content repurposing application that takes video or audio input, transcribes it using services like Deepgram, Assembly, or Whisper via Groq, and then feeds the transcript through various LLMs to generate summaries, chapter titles, key takeaways, and even creative outputs like songs. He walks through the full workflow live, showing the credit system, model selection with pricing tiers, and the JSON output that gets written to the database.
The Dash payment integration is running on testnet and is described as roughly 99% complete, needing only a switch to production. Anthony explains that the app is designed to be accessible to non-technical users through a simple drag-and-drop interface, removing the need to understand prompt engineering or model selection. Rion commends the progress and notes Anthony's deep familiarity with the Dash JavaScript SDK, which made the integration relatively straightforward for him compared to a developer starting from scratch.
00:11:19 - Vijay's Bitcoin Backport Pull Requests
Vijay presents his work on backporting Bitcoin improvements to the Dash codebase, a process he has been contributing to since 2021. He walks through nine merged pull requests covering wallet test corrections, redundant logic removal, integer overflow fixes, thread safety improvements, deadlock prevention, and dependency modernization. He highlights the signed integer overflow fix as particularly important for security and correctness.
Rion provides context that Vijay received only one month of funding from his six-month proposal and has been working for several months without pay. He acknowledges that backporting is essential maintenance work for any Bitcoin fork and commits to compensating Vijay for at least one month from his own proposal funds if Vijay's proposal doesn't pass. The discussion touches on the tension between network priorities and the undeniable importance of keeping Dash's codebase in sync with upstream Bitcoin improvements.
00:22:08 - Mikhail's Lightweight Dash Platform SDK
Mikhail introduces a rewritten WASM layer for the Dash Platform Protocol that reduces bundle size from roughly 10-12 megabytes down to 2-3 megabytes while adding modular tree-shaking so developers can strip unused features. He explains that the existing DCG WASM DPP package breaks in production browser bundles when code is minified, because the bindings rely on specific class names that get mangled during minification. This distinction clarifies why Anthony's server-side Node.js usage worked fine while browser-based single-page applications failed.
Built on top of this new WASM layer, Mikhail has created a lightweight Dash Platform SDK that works across browser, Node.js, and React Native environments without requiring polyfills or special configuration. It supports querying data contracts, documents, and identity information directly from DAPI endpoints, and he demonstrates it loading directly into a web page's window object—something the existing JS SDK cannot do. The SDK deliberately omits wallet functionality, requiring only identity private keys rather than seed phrases.
00:37:26 - Browser Extension and Transaction Signing
Mikhail demos a proof-of-concept browser extension modeled after MetaMask that stores identity private keys and provides a transaction approval dialog for decentralized applications. He shows the flow of importing a private key exported from the Dash Evo Tool, viewing the identity balance, and then signing and broadcasting a platform transaction from a sample web application—all on testnet. The extension injects the SDK into the browser's window object so any dApp can access it.
Discussion turns to identity registration, which currently requires an asset lock transaction from the core chain. Mikhail presents mockups for a centralized gateway that would handle asset lock creation without exposing identity private keys, allowing users to pay via QR code. Rion and Anthony weigh in on the tradeoffs between storing keys in extensions versus mobile wallets, with Mikhail noting his long-term vision involves delegating key storage to mobile applications communicating with the extension, similar to WalletConnect's model.
00:54:51 - Matt's Pure JavaScript SDK Vision
Rion shares Matt Peterson's progress on an alternative SDK approach that aims to auto-generate a fully type-safe JavaScript library directly from the Rust Dash Platform Protocol source code, eliminating WASM entirely. He shows Matt's branch comparing against the base Dash Hive platform repository, noting that Matt is working toward demoing the three core operations—identity creation, data contract creation, and document submission—but hasn't reached that milestone yet due to illness and competing priorities.
Rion articulates his vision for an SDK measured in kilobytes rather than megabytes and milliseconds rather than seconds, with complete IDE autocomplete support and no black-box WASM debugging issues. Mikhail agrees this is the right long-term direction and confirms his SDK architecture is designed to swap out the WASM serialization layer for a pure JS alternative once it's ready, allowing both efforts to converge rather than compete.
01:05:44 - Treasury Voting Scenarios and Closing Thoughts
Rion pulls up a spreadsheet showing the current treasury is oversubscribed by approximately 1,500 Dash, meaning not all proposals can pass. He walks through three funding scenarios, each assuming DCG's proposals will be approved, and explores different combinations of development versus marketing proposals that could fit within the budget. His preferred scenario funds all SDK-related work while postponing a third-party marketing initiative called Market Across until developer tooling is more mature.
He argues that grassroots marketing through community Twitter Spaces and real application demos is more effective at this stage than paying an outside PR firm, especially given past experiences where contracted marketing efforts failed to move Dash's price. Anthony, Vijay, and Mikhail share brief closing remarks, with Rion reiterating his commitment to compensating Vijay from incubator funds if needed. The episode wraps with Rion heading to the scheduled Twitter Space on stablecoins.
Transcript
[00:00:00.05] - Rion Gull All right, welcome everybody to today's episode of Incubator Weekly. This is probably the most packed show that we've had in a little while. I've got today with me Anthony, CryptoTura, AKA Vijay, and Mikhail. How's it going, guys?
[00:00:21.25] - Anthony Campolo The dev extravaganza, right?
[00:00:25.08] - Rion Gull Yeah. All developers here. So today we have a lot to talk about. We'll jump right in. I will give my normal little preamble here. I'm going to try to keep this between 50 minutes and an hour. I don't think we're going to get any less than 50 minutes. But we do have an important Twitter Space that I'm planning to join either as just a listener or hopefully a speaker. But I kind of haven't had an invite to be a speaker, though I would be.
[00:00:57.26] - Anthony Campolo Why is it so important? What's happening?
[00:01:00.04] - Rion Gull Well, it's important to me. It's not going to be important to everybody, but it's just a weekly thing that Joel has started that combines a lot of different communities, the Litecoin community and several other communities, like digital-cash-focused coins, and we talk about important topics. Last week was a really good show. We had a heavy lineup of speakers. Joel put together a really interesting discussion. We had, I think, 20,000 people that came to view the Space, and this week the topic is stablecoins. So that does kind of affect development as well. It's not just marketing and discussion. So I want to join that conversation. I might be a little bit too late to that, but either way we'll all say what we want to say on this show. Each of us has proposals on the network right now, and each of us has been doing work in the past, either from past proposals or from hopeful upcoming proposals to pass. So I'm going to pass it over to Anthony.
[00:02:18.29] - Rion Gull You're going to talk about what you've been up to and what your proposal is about. Then we'll go with you, Vijay, and then we'll go with you, Mikhail, and talk about your proposals, particularly the SDK work, which is what I would like to discuss with you. Then I'll have some closing thoughts about different voting scenarios and whatnot that I foresee. Okay, so Anthony, you want to... Oops, that's my screen share. That's what I'm going to be talking about. So let's see where yours is, Anthony. Here we go.
[00:03:00.13] - Anthony Campolo Let me know when it's up.
[00:03:03.17] - Rion Gull Okay, I guess I gotta remove mine. That's interesting. There we go. Is this you? Yeah, this is you.
[00:03:13.19] - Vijay Okay.
[00:03:13.28] - Anthony Campolo Yeah, cool. Sweet. So this is my proposal. I'm building an app called AutoShow. It came very close to passing last month. Votes are a bit down since then, but I'm still kind of on the precipice, so it would be really nice if it were to pass. But I understand that we're kind of in a tight monetary situation right now in the Dash community. But yeah, I'm going to show off just a little bit of what I got going. I'm going to kick this off while I explain, because this first step takes a while. AutoShow is a content repurposing app that lets you take video and audio files and transcribe them, and then use cutting-edge LLM AI technology to do things like create chapter titles, summaries, blog posts, and you can even write songs. The plan was to kind of use Dash as the payments and authentication layer, and the integration is like 99% done. Right now it's running on Testnet. So what you're seeing here is kind of using, like, Play Dash money, but everything that needs to be there to actually ship this to prod is basically there.
[00:04:37.09] - Anthony Campolo So because this is on Testnet, this first step takes a long time. But basically right now what it's doing is letting you know how many credits you have in your wallet, which is just a unit of measurement for the app. Because there are two steps with the app that require credits. There's picking your transcription service, and then there's picking your LLM service. Because if you're someone who is into the whole AI thing right now, maybe you're using ChatGPT, maybe you're using Claude, maybe you're using Gemini. This is a multi-model app, so it lets you do a little bit of everything. So you see here right now, it kind of tells you what your balance is in duffs, which is always confusing to me because there are all sorts of calculations that go into figuring out what a duff or a satoshi or a dash is, and then...
[00:05:34.02] - Rion Gull Or credit.
[00:05:35.09] - Anthony Campolo Yeah, or credit. So the term credit in this app is not related to a credit in Dash App, which is another thing that's a little confusing, but we can blaze all past that. So right now, this is kind of how many credits we've got. AutoShow credits. Yeah, AutoShow credits. And then you can give a file on your computer or a YouTube URL. Once you do that, it gives you your different transcription options. The main ones are Deepgram, Assembly, and Whisper through Groq. Right now, because it's still on Testnet, there's just an extra step where you give your API key, but this step will not exist once you're actually using the full-on Dash part. So then you get your transcript right here and you select your prompts. This is what you can generate with your LLMs. So you can create titles if it's just a raw video you created and you don't even have a title for it yet. You can have different-length summaries, different-length chapters, things like key takeaways. You could even do questions if you want to create educational material based on it.
[00:06:54.29] - Anthony Campolo So we'll just do a summary and a country song.
[00:06:58.22] - Rion Gull And just in case people missed it, you uploaded a video. So it processed that video, or it is processing that video, and then spitting out through the AI these different things that you're asking it to spit out.
[00:07:14.21] - Anthony Campolo Yeah, exactly. It showed the transcript, and then I went to the next step, so you don't see the transcript anymore. But the transcript was based on the video I gave it, which is just like a couple-minute podcast that I had recorded from FSJam. Then it gives you all of your different AI options. I'm going to use DeepSeek just because it's the cheapest, so it's good for demos. Because I selected a summary and a country song, what it does is take the transcript and the custom-written prompts that I've written that go along with the prompts we selected earlier, and feed both of those to the LLM. Then it gives you back the result. If you see here, it tells you the exact amount of credits you need for each of them. So if you're using a more expensive model like ChatGPT 4.5, it's 300 credits, but if you're using o1-mini, it's only 10 credits. Then this is kind of the JSON output of what's being written to your database. But really what we want to see is this. So we got our summary: discussion between hosts about JavaScript and FSJam frameworks, reflections on 2020.
[00:08:36.15] - Anthony Campolo And then there is your song. So yeah, pretty simple app. The idea when I built this is I really wanted it to be friendly to non-technical people. This was originally a CLI that I had created, but I wanted just a very simple drag-and-drop, click kind of thing so anyone can use this regardless of technical ability. They kind of get all of the benefits of modern LLMs, even if they don't know what the best models are or how to write a prompt. They just have to drop their video in, click what they want, and then they get it back. The only thing that really needs to be changed here for actual production is to have it on prod instead of Testnet, and then when you do the final step, it will subtract those credits from your account and send them to the AutoShow Dash account. So like I said, it's 99% complete in terms of the integration. Just a couple more lines of code would need to be changed to make it actually ready to send to prod. So yeah, that's the whole demo.
[00:09:46.12] - Anthony Campolo Pretty, pretty simple.
[00:09:48.26] - Rion Gull That's awesome. You've come a long way, obviously, on this since the last time that we discussed it. You've got a UI now, and I didn't really expect the Dash integration to be as far along as it already is. So that just kind of shows how committed you are to making that work and putting in the time and work even before you're funded.
[00:10:16.23] - Anthony Campolo Yeah. And I know how the Dash SDK works. I did a whole bunch of tutorials with it already. So it was actually a pretty simple integration for me. Someone who was coming in totally cold would have to go through the docs, learn all the terminology, and figure out how the SDK works. But I was pretty much ready to hit the ground running when I wrote the proposal, so I wanted to get it as close to the finish line as possible.
[00:10:40.27] - Rion Gull Yeah. The key thing there being that you've had a lot of experience with the SDK and so you kind of know how it works.
[00:10:50.12] - Anthony Campolo I've always said it's a little slow, but aside from that, I actually think it's a pretty, pretty good SDK.
[00:10:58.03] - Rion Gull All right, so Vijay, unless anybody has any questions, it looks like we got a couple comments here from Al. How's it going? I haven't read this yet, so hopefully...
[00:11:09.15] - Anthony Campolo So this was using the SDK and it is running on the web. So what you saw is the SDK on the web, so the JavaScript SDK. So yeah.
[00:11:18.18] - Vijay Yep.
[00:11:19.21] - Rion Gull Okay. And there will be plenty more talk about the SDK stuff later, after Vijay. So do you have a screen share for us, Vijay, that you wanted to present?
[00:11:33.02] - Vijay Yeah, yeah, yeah.
[00:11:35.17] - Rion Gull Okay, I don't see it. Does anybody else? Okay.
[00:11:51.24] - Rion Gull Yeah, yeah, we can see it now. And just as a quick preamble, you've been working hard on Bitcoin backports. You had a six-month proposal, and you've been working for several months without any funding for that. So that's the context behind this in case you were planning on saying that. I've seen the PRs coming through and getting merged and things like that. So yeah, go ahead and give us your presentation.
[00:12:35.27] - Vijay And so my name is Vijay, and I'm also known as CryptoTura in the Dash community. I've been contributing to backporting pull requests since 2021, focusing primarily on backporting improvements from Bitcoin Core into Dash. Most recently, from the last funding, the only funding I got was in January. After that, I have done these nine pull requests. These changes make the code faster, fix bugs, remove technical debt, and fix tests. I can talk about each PR. For example, 6308: this wallet test has been corrected and fixed, with a couple of refactors and CI wallet tool fixes. It brings test accuracy and long-term code maintainability. If you can see in the details of 6308, I merged 2372 into 2346. This fixes the test and runs only if a specified wallet type is available. Another part improves headers for the Bitcoin wallet tool. So this brings test accuracy and long-term code maintainability. Similarly, for 6534, I've removed redundant logic in the wallet with spend tracking for better performance and cleaned up unused and outdated network functions.
[00:14:27.20] - Vijay So this improves efficiency and reduces tech debt in wallet and networking code. Similarly, the third PR changes test clarity by making miniwallet mode explicit, and improves build portability and configuration via standardized variables. This benefits cleaner tests and more robust cross-platform builds. Similarly, 6519, this pull request, has this signed integer overflow issue in prioritized transaction RPC, so I have backported this one. This is a potentially dangerous signed integer overflow, so this is one important fix. Then there was time logic with a safer alternative, cleaning out legacy and MSVC warnings. So this increases correctness, security, and code maintainability. Similarly, 6550 clarifies wallet behavior through better documentation. For test reliability, I fixed the CI/CD pipeline. And 6552 is for wallet performance and modularity. This optimizes wallet I/O by avoiding redundant DB reads, makes dust testing more realistic, and enforces better encapsulation in the address book. Then 6619: deadlock prevention via recursive lock prevention, fuzzing by updating data providers, and fixing wallet backup discovery. This is for stability, test effectiveness, and backup safety.
[00:16:28.18] - Vijay This is a concurrency-related data race, so this is a thread-safety issue addressed via this pull request. It also cleans up outdated mempools, so this is for thread safety. Similarly, the last one, 6624, standardizes fuzzer structure for safety and clarity, removes Boost dependency in testing, and modernizes old macros and path-handling logic, which leads to cleaner, more portable, and easier-to-maintain code. So all of these pull requests bring very important changes that are already tested in Bitcoin code, from thread safety to integer overflow protection to readability, documentation, and wallet updates. These changes make the code faster and safer. Overall, this is very significant work, which I'm trying to do and have been doing for a very long time. I had a wonderful 2024 year working with Mikhail. Since I have been working on this so long, I'm also trying to understand network behavior, I mean when and how they accept proposals.
[00:18:07.02] - Vijay These are very important changes, and supporting this proposal is a very small investment in the long-term stability and performance improvement of our Dash network. So I request the community to look into this. This is a very small ask. I think currently it is around $1,000 USD or something. My request for the network is to consider this. This is important work that helps Dash stay up to date, secure, and easier to build on. This is very important work, and I hope the community supports me this time. I have been consistently doing this work, and I hope I get the support.
[00:18:57.13] - Rion Gull Yeah. Thank you for going through each of those. I would also say, you know, I don't think anybody doubts the importance of backporting Bitcoin.
[00:19:11.20] - Vijay We...
[00:19:12.01] - Rion Gull We are a fork of Bitcoin, and we maintain upstream compatibility with that other than the features that are unique to Dash. So this is a constant process. So long as we are going to maintain being a fork of Bitcoin, we have to stay in sync with Bitcoin. Dash Core Group does a lot of this work. You were working through the incubator to do some of the ones that either they weren't doing, or I'm not exactly sure what the process was or how you determine which backports you decide to do versus which backports DCG decides to do. But I would say, just in case I forget to say it later, because you've been working so long and because you had a history of working in the incubator, and we were paying you through the incubator at that point, but you've been doing it for several months without pay, if your proposal doesn't pass and my proposal does pass, I do plan on reimbursing you or compensating you for at least one month.
[00:20:39.05] - Rion Gull So I will say that because I personally find it valuable, even though I want proposal owners to be independent. That's one of my main goals in the incubator, to get people with their own independent proposals so that we get network feedback. So I understand there's a balance to be made. Whereas if the network rejects your proposal and says, for whatever reason, we don't think the juice is worth the squeeze, whether it's too high of an ask or the quality of the work isn't up to what the network wanted, or it's just a matter of priorities, which is I think the most likely case, that it's just been a matter of priorities, I think that's a tricky place for me to say I'm going to override the network's vote and pay you anyway from what ultimately is the network's money. But I think that most people would agree that if it's just a matter of priorities, I would be happy to kick in some of that funding if my proposal passes and yours doesn't, by whatever chance. So it depends on how the MNOs, the masternode owners, decide to do their Tetris work this month, of what room is available.
[00:21:59.08] - Rion Gull So thank you for your work regardless of the outcome, Vijay.
[00:22:03.27] - Vijay And...
[00:22:06.02] - Rion Gull Let's, I guess, move on to Mikhail.
[00:22:08.26] - Anthony Campolo Good stuff. And also props for using Notepad.
[00:22:14.04] - Rion Gull Yeah, that's OG right there.
[00:22:17.07] - Mikhail Hey, guys. I want to show you what we've been doing last month, and yeah, the progress in SDKs. So last month we were focused on the dApp examples and the SDK around them. There was quite huge work in testing different schemes, different approaches, how we can do that. And we basically bootstrapped a new toolset, so basically a lightweight SDK which is a little bit different from our original JS SDK, which contains a wallet and other stuff like Core Chain, for example. What we've done is just a lightweight Dash Platform SDK which runs straight away. You don't need to sync anything, and it works straight away. Let me share my screen. I will show you some stuff.
[00:23:31.06] - Rion Gull Okay, I'll put it on as soon as I see it.
[00:23:45.29] - Mikhail So yeah, the first thing that we've done, we basically rewrote the DPP. It works by acquiring the DAPI endpoints and then deserializing the responses, basically kind of similar to what the current SDK is doing. Our problem was with the original WASM DPP package, which is the DCG one. There were multiple things that were blocking our work. First, it was missing some features that we were desperately trying to implement, and the code base is pretty heavy. So yeah, I've been spending a lot of time trying to add some features. Then it was going to review, and on the review it was kind of hard for us to implement all of the missing features that we need. There were also a lot of internal bugs and architecture flaws which prevented it from being used in the production environment, in the JS production environment. As an example, there is an issue where it basically doesn't work in production bundles, because when you minify the bindings, it minifies the class names and then it just cannot work because it has a different name, but in the code for some reason it tries to read it.
[00:26:02.12] - Mikhail Let me show you. Yeah, basically it's somewhere here. Yeah, this one. It basically expects some certain class name and stuff like that. It was pretty hard to understand what was going on there. Basically, what we've done is just take all of the things from Rust DPP and implement a new, very flexible Rust WASM DPP, which is pretty lightweight. Last time I checked, the WASM DPP size was like 10 megabytes or maybe 12 megabytes. We managed to reduce it to 2 or 3 megabytes, which is kind of acceptable for the web.
[00:27:10.16] - Rion Gull I have a question about the examples that you were giving and what's kind of necessitating this need in your mind. Because as we've seen, Anthony's got an app right here that was using the existing JavaScript SDK, and it works for what he was needing. Now, nobody's used the JavaScript SDK more than you, Mikhail. So you know how it's working, what the corner cases are, and what the edge cases are that may not be working. You said in production bundles, Webpack production bundles, it wasn't working. Was that for React Native or...?
[00:27:53.11] - Mikhail No, no, it's for the regular browser.
[00:27:56.05] - Rion Gull Regular browser. And what specifically wasn't working for you?
[00:28:00.27] - Mikhail No DPP methods were working. I actually think not even queries were working, or maybe only particular queries. So this error which I was showing...
[00:28:17.21] - Vijay Where?
[00:28:18.15] - Mikhail Where it was, yeah. So it fails to set metadata, and metadata appears in every DAPI query. So I suppose it breaks on everything. It breaks when you try to use platform features. It does work for core, I believe, but I'm not sure. So yeah, when you minify it, it stops working.
[00:28:47.05] - Rion Gull Okay.
[00:28:48.25] - Mikhail Okay, well.
[00:28:49.28] - Rion Gull And I don't doubt you at all, because we've run into many, many problems. Sometimes it works and sometimes it doesn't. So whatever's working for you, Anthony, I'm not sure how many platform features you're using at this point in your...
[00:29:06.14] - Anthony Campolo Yeah, I mean, for the, for the AutoShow app, it's. Right now it's just grabbing the balance. But I mean, we did the tutorial where we use every single method, so I'm not really sure what Mikhail is talking about in terms of the metadata.
[00:29:18.20] - Mikhail Did you use it in the Node environment or the browser environment?
[00:29:23.02] - Anthony Campolo Node environment, yeah.
[00:29:25.04] - Mikhail In Node, it works perfectly. Everything works.
[00:29:27.13] - Anthony Campolo Yes, that's the thing. I just, I just do it all on the server side. So that's that's why I've never really had issues, I guess.
[00:29:32.16] - Rion Gull Yep. Yeah. And that's why I wanted to clarify that, because the whole purpose behind the JavaScript SDK, at least in my mind, is to be able to work on the client side in the web browser. We want people to be able to build applications that store and use data from platform even if they're building a single-page application without a server side. So that is a big deal. I've seen it working at some points throughout the history, even in the browser, purely single-page-application style. But through different versions, sometimes you'll get one feature added and then another feature breaks. I just wanted to make sure that that was the issue.
[00:30:27.27] - Mikhail What we used to do is just make all bundles in development mode. Yeah, exactly. It's not a single bug or issue as such. It's currently a lot of things happening on the way.
[00:30:47.26] - Anthony Campolo So...
[00:30:50.13] - Mikhail We basically did a new WASM layer which not only has reduced size and improved web compatibility, it also has a feature where you can reduce the bundle even more by stripping out all of the functionality you don't need. So everything is broken down into different modules, and you can build those separately and reduce your bundle if you don't use some kinds of features.
[00:31:27.22] - Anthony Campolo Yeah.
[00:31:28.11] - Mikhail So it works pretty great. I tested it in many environments: the Node.js environment, the web environment, even React Native. But in React Native it's kind of more complicated, a more complicated environment. But I ensure that it is working. It's just a bit hacky right now.
[00:31:56.08] - Anthony Campolo Okay.
[00:31:57.24] - Mikhail Yeah. So what I did next, I got this WASM DPP integrated into Dash Platform SDK. This is a lightweight SDK which basically even allows you to load it straight up into the web page, which isn't possible with the current JS SDK. With the current JS SDK, it basically isn't working. In the past we've been trying to accomplish that for like an hour and couldn't manage to do it. The reason is the current JS SDK misses some polyfills. It doesn't really get bundled for cross-compatibility. For example, buffer is being used everywhere, which does not exist on the web. I have bundled it for every environment. You can use it in your regular frontend, like in React applications. You can use it in Node.js with the CommonJS syntax. And you can even load it straight into a web page, and it basically gets available on the window object. It's pretty much very easy. You just supply some parameters, and then you can execute the queries. So how it works: it just has some predefined list of seed nodes. This is one that I'm spinning up, and a few DCGs.
[00:33:30.05] - Mikhail But yeah, when you're creating an SDK, it automatically fetches the list of masternodes from AJ's Digital Cash RPC. So basically, if it's possible, it fetches the recent addresses of the DAPI. If not, it just uses the static ones. Currently I have implemented the most simple things, like data contract, get data contract. It is possible to create a data contract, I just haven't got to that yet. I will add it pretty soon. You can create and get documents from the DAPI. You can retrieve information about identities like get balance, get identifier, get by identifier, get by public key hash, get all the nonces for your transactions, get identity public keys. I didn't put the identity registration in yet. This is the thing that I'm thinking of because this Dash Platform SDK is designed to work with only platform. It doesn't have core functionality. So what we possibly could do is create a separate function for creating an identity when you pass a complete asset lock proof from the core chain. Because I don't want to put core functions into this platform SDK.
[00:35:21.28] - Mikhail But we will talk about this later how it could be used.
[00:35:25.22] - Vijay Okay.
[00:35:26.02] - Mikhail Yeah, yeah. So name search and some utility functions, like you can get the status of the masternode, which retrieves your versions, broadcast, wait-for-transition result, stuff like that, and some utilities. This can already be used for making applications. It's working, it's cross-compatible, it weighs like 2 or 3 megabytes, I believe. Let's see actually. Yeah, it's 3 megabytes right now. But yeah, we will try not to raise it even more. There are things to optimize. For example, yesterday Matt Peterson showed me another gRPC library which should reduce it even less. Anyway, it is already working, and you can use it for querying and submitting documents. But how does it work? With the regular JS SDK you're just putting in your seed phrase or private keys. Actually, seed phrase. I think you can only use seed phrase. But with the current Platform SDK, you basically can sign your transactions with the private keys that are bound to your identities. For example, each identity has some set of public keys which you can use to create and sign transactions in the network.
[00:37:26.10] - Mikhail Our SDK does not implement any wallet, so you don't have to provide a seed phrase to it. All you have to do is provide a simple private key from your identity that can be shown, for example, in DET. So yeah, it is currently the responsibility of the developers who are using this SDK to handle those private keys. So anyway, the user has to insert the private key inside the dev application, and that's not really the best use case because we want to make it as transparent for a user, and as secure, as possible. Like in Ethereum, we have MetaMask, which allows you to sign transactions so you can see what you are signing, and you don't necessarily put private keys into web applications. So what I did next, basically, I bootstrapped and sketched a Dash Platform extension. It works. It's kind of ugly right now, I know, but we will work on that. I was just working hard on the functionality and how to connect all things together. So basically how it's working, it's like storage for your identity private keys.
[00:39:22.06] - Mikhail So you just put your private key inside the extension one time, and then you can use it on every page. Every page you're visiting, like any Dash dApp application, the SDK gets available straight away on the window object, and developers can use it the same way MetaMask works. So yeah, this is an example of how to use it. Basically, with the SDK, you get the SDK from the window. For example, you want to send a message. You get the SDK from the window object, then you get all the parameters, and then you do some stuff, create this transition, and then you can invoke a signer, which basically opens the approve-transaction dialog. So it's a small extension. When you open that, you can see two buttons: Import and Register. Register right now is grayed out, but I will implement it later. When you click Import, you can import the private key in hex or WIF format. So what I wanted to show you is that it requires you to import your private key. It's supposed that you have registered your identity somewhere elsewhere, for example in Dash Evo Tool, and then you can just import the private key.
[00:41:21.17] - Mikhail Let's try and create a new identity. There is an option...
[00:41:28.20] - Rion Gull While you're doing that, what are your thoughts about...
[00:41:35.14] - Vijay Yeah.
[00:41:35.20] - Rion Gull What are your thoughts about creating the identity in the extension itself?
[00:41:43.09] - Mikhail Yeah, in the extension itself. Let me show you actually how...
[00:41:49.17] - Rion Gull Nobody's going to want to download Dash Evo Tool, like just normal users, right? Normal users aren't going to want to do that, right?
[00:41:56.25] - Mikhail Yeah. Here are the mocks, the mocks of my application that I sketched. So basically how it could work: right now the most complicated part is asset lock transactions, because you don't want to put your seed phrase in, or any private keys. What you would like to do is just pay with your QR code through your Dash application, or redirect to any other applications like Dash Core or Dash Electrum. But it's currently not possible. Right now we have the ability to pay by QR code, by pay-with-link, but it's only for regular payments. You can't do specialized transactions right now. You can't do asset lock transactions. So for implementing registration in the extension in a decentralized way, without relying on any other services or stuff like that, we have to have some kind of way to create specialized transactions from our wallets. So to make this work, the way I was thinking we could do it is with a centralized gateway which will help you register your identity. Basically it takes care of creating an asset lock transaction, which provides the collateral for registering your identity on the platform.
[00:43:48.29] - Mikhail But it doesn't share your identity private keys with this service. What it basically does is share a one-time private key with this service, which basically allows you to send a regular Dash payment to some address, and then it creates an asset lock transaction. Then you can use it as collateral in the platform register-identity transaction. So it's kind of not decentralized, but it's a kind of way that we could make this work, registering inside the extension. Yeah. Is it clear for you, Rion, how it's working?
[00:44:40.21] - Rion Gull Yeah, I think a lot of users are used to the idea of either generating or importing even a seed phrase. So that's the whole idea behind extensions: you trust one extension, and then after you've trusted one extension wallet, you don't have to trust any of the applications because all of the wallet features are done in the extension, and the applications are just asking to sign things or give the application permission to do various things without asking after that point. So that is the experience that most people have with decentralized applications. So I'm personally not opposed to the idea of generating or importing seed phrases into extensions. There are other ways to do this, things that I've talked with AJ about, for example, because even extensions are quite insecure when you get down to the details of things. But this is all about user experience.
[00:45:58.04] - Mikhail Of course. Personally, I don't like the idea of holding any private keys or seed phrase either in the extension. I believe that should be delegated to the mobile app.
[00:46:10.11] - Anthony Campolo Right.
[00:46:10.23] - Rion Gull So that's another option.
[00:46:13.17] - Mikhail That's the option.
[00:46:14.14] - Rion Gull At the end of the day, you're going to have to trust some application, whether it's an extension, an application, a web application, or a mobile application. At some point the user has to trust some developer that built some application to hold the private keys. I don't think anybody would dispute that. The only thing is how do we minimize the trust, and how do we make sure that it's a good user experience so that users feel comfortable with the small amounts that they are using on web applications and through extensions.
[00:46:50.20] - Mikhail Let me show you how it's working.
[00:46:55.07] - Rion Gull You jumped in here. Did you have something to say?
[00:46:58.21] - Anthony Campolo No, just I agree that the Dash ecosystem in general is always technically sharp, but the UX sometimes leaves a bit to be desired.
[00:47:12.23] - Rion Gull Right. And mostly because we don't have millions and millions of dollars of VC funding. But that's a separate...
[00:47:21.25] - Mikhail okay.
[00:47:23.11] - Rion Gull But go ahead and finish what you're demoing.
[00:47:27.06] - Mikhail Let's use the existing identity just to save some time. I have already registered an identity today on Testnet. It's all on Testnet. We can see the keys, and what we want to do here is export the private key, which is in wallet import format, called WIF. Let's try to import that through our extension. We click Check, and then it almost instantly gives you your identity information. Here is the identifier, which matches what we have in the DET, and we have the actual balance. Here it is. We imported our identity, we can see the balance, we can see some grayed-out buttons again, and we can see some transactions that are related to this identity. For example, this is maybe identity creation. Anyway, what happens when you visit the dApp application? This is the sample application that I just made as a proof of concept. What it does is it gets a Dash Platform SDK from the window, it queries some documents from the data contract, and if there are any, it will show you. Basically it creates a transaction. Let's try to do that. So once you click on the transaction...
[00:49:21.14] - Mikhail Wait a second. Yeah. Once you click on the Create New Transaction button, an approval dialog appears from the extension. Then you click Sign, and it instantly gets broadcasted to the network. You can copy your transaction hash, close, and check. We can already see the transaction is in the network. Awesome.
[00:49:52.25] - Rion Gull Yeah, that's a good demo. I don't care how it looks at this point. Getting the nuts and bolts working together where the extension is communicating with an application, the application communicates with the SDK, and the SDK is a revised version that you've written of the SDK that Anthony is using in his application from DCG, for example, it seems like you've got the basics of all of those components working together, which is great. We've been able to do that with the old SDK. You've done it now with a newer SDK that has advantages over the older SDK. Unless you had something else to demo, I wanted to transition the conversation to what I'm working on with Matt, and then a little bit of discussion about the proposals and how...
[00:50:53.16] - Mikhail Yeah, I wanted to have a really small chat about mobile applications. What I did was test the Dash Platform SDK in React Native, which is a cross-platform mobile framework used by a lot of developers right now. We were talking about how private keys and identities should be held in some secure storage, like mobile wallets. So that's what I was planning to also implement. In a future version of the extension, you could delegate the storage of your identities to mobile applications. So what I did was...
[00:51:49.03] - Rion Gull And by the mobile applications, it's always been my preference, and even Andy, way back when he was running the incubator, he was very opinionated that everything should be contacting not just any old application or even an extension, but the actual Dash Pay from DCG application. So is that what you mean by mobile app? Do you mean that the keys should be stored in Dash Pay from DCG?
[00:52:21.28] - Mikhail It would be really great to integrate it with the Dash Pay wallet, but I'm not sure what the current resources and capabilities are there in the mobile team, or how fast it could be done. What I was thinking is to make another proof-of-concept mobile wallet which can hold that identity storage that you can use with your extension, just to prove that this kind of communication works. Because I believe that would totally require something else.
[00:53:02.05] - Rion Gull So just to be clear about what you're suggesting here, you're saying that a decentralized web application, instead of communicating with an extension wallet to sign transactions on the user's behalf, would communicate through the platform, and then a separate mobile application would be holding your keys to approve web application communications.
[00:53:34.15] - Mikhail And it will, it will communicate, it will talk with the extension, but extension will take care of connection with your mobile wallet.
[00:53:45.25] - Rion Gull Okay, so in your proof of concept here, you're still having an extension. I thought that you were suggesting doing away with the need for an extension and replacing that with a mobile application, which is something.
[00:53:58.14] - Mikhail No, no, no, it's additional. So you could use just the extension, you could import your private keys into the extension, or you could use your mobile app. So just pop up your mobile app and scan a QR code or stuff like that, something like WalletConnect.
[00:54:16.21] - Rion Gull Okay. And so do you have that to demo so that we can discuss?
[00:54:23.05] - Mikhail What I managed to do was test the Dash Platform SDK in the React Native environment. But there are some issues, and I wasn't able to go further with that. It just requires some more time to do things. So yeah, I think that's pretty much it.
[00:54:48.08] - Vijay Okay.
[00:54:51.07] - Rion Gull Okay, I'm gonna put my screen share on. I'll briefly talk about this. There's not a lot of time. We're already kind of later than I wanted to be. But that space is going to be fine. It takes a while to get started and they go for hours and hours, so I'm not going to let that get in the way here. I just wanted to talk briefly about what Matt has been doing. Matt unfortunately has been quite sick for what seems like a week or more, so he wasn't able to join the call today. But he has been busy working. However, between some priorities that he's had, some non-Dash priorities, being sick, and some other things, unfortunately he hasn't been able to get to as much as I was hoping for in terms of how his side of the SDK work is going. But I wanted to show what he's done recently. He's doing his work in... let's see, this is Dash Hive Dash Platform. This is comparing his branch with the base Dash Hive platform.js branch, just to kind of show what he's been working on.
[00:56:15.23] - Rion Gull Last year he was working a lot in March, and then he did some things in April as well. He's trying to get to the point where he can demo the creation of an identity, then use that identity to create a data contract, and then from that data contract create a document. So here's the data contract. You also saw some generated stuff. I'll talk about that in a minute. And then, like I said, creating a document on top of that data contract. You can also see there's a build folder that has a lot of, I assume, generated files as well. So this is all... He's not at the point where he can demo all three of those steps. That's the main three-step demo that we've been working toward: creating an identity, a data contract, and documents. We'll get there soon. However, the difference between this and what you are working on, Mikhail, is that I feel very strongly that we should have the most performant, lightweight, and user-friendly SDK that we can have. Because as opposed to somebody like Anthony, who has worked a lot with our existing SDK and has developed Stockholm syndrome and has loved his abuser, something like that, most developers are not going to have that kind of patience or incentive to work through all the warts of the existing SDK.
[00:58:23.07] - Rion Gull Everybody acknowledges that there's a lot of work to be done on the SDK. So I'm envisioning a future where I'm aiming big. I'm aiming toward a future where we can have an SDK that integrates with some of these frontend frameworks. If the frameworks, after spending years and years getting themselves down to tens of kilobytes, are then being asked to add on megabytes of data just to get our stuff working, I think that's too much to ask of the non-interested developers. So I'm trying to have an SDK that basically gives nobody an excuse other than, "I just hate cryptocurrency, so I don't want to use that." But in terms of size and user experience and performance, I want it to be as good as possible. The way that I see us doing that is writing it in pure JavaScript, but as a library that's auto-generated directly from the single source of truth, which is the Rust Dash Platform Protocol and the Rust code base in general. And so what you're doing, Mikhail... I'll just switch to the discussion screen again.
[00:59:54.18] - Rion Gull What you're doing is kind of fine-tuning the existing Dash Platform Protocol and still using WASM bindings. And I see a future where that might be the first step. You've said that you've gotten some gains where you've taken it from 10 megabytes down to 2 megabytes. It's faster. But I'm shooting for a future where we're dealing with hundreds of milliseconds rather than seconds, and kilobytes rather than megabytes. And where the whole SDK is completely type-safe, where developers can just say dash dot and then have all of the auto-completed methods and everything like that. That's extremely important so that people don't have to deal with documentation so much. Everything that Matt has done to this point is toward that future where we have a fully type-safe SDK that shows everything and is very debuggable, because you're never going to run into a black box where it says, "Oh, this is WASM code." So that's the future where I'm headed. Mikhail, any thoughts on that so far?
[01:01:28.22] - Mikhail I agree with you. I agree with you that we should have so-called JS DPP that will be lightweight and work fast and be cross-compatible between environments, like React Native, for example, which I had problems with.
[01:01:47.21] - Rion Gull Any time you introduce WASM, you're going to run into an edge case. Some kind of cloud function, for example. I remember the first time that I, as a developer with my developer hat on, tried to use the Dash SDK in a Lambda function on AWS, and it just did not like it. Because part of that is WASM, and part of it is just how WASM is built and everything. It's not working on certain architectures that AWS is running. So there's going to be edge cases any time you introduce WASM. Even if it's not a performance issue, even if it's not a size issue, it's going to be a debugging and developer-experience issue at some point with certain architectures. If it's pure JavaScript, everything supports JavaScript these days, but not everything supports Rust and WASM. So that's my opinion. I think that we can get there. I think that we're actually very close to being there. We just unfortunately didn't get there between Matt's conflicts and being sick. We didn't get to that demo this month.
[01:03:03.05] - Rion Gull But I do think that with you working on higher-level APIs, and Matt working on the lower-level stuff, anything that you throw at him, because he knows Rust, he knows tooling, he knows TypeScript, that is a definite possibility. Matt can do almost anything that I throw at him as long as he has enough time, has the priority to do it, and the incentives, financial being one of those. So between you guys working together and continuing to work together, I think that's a definite possibility. Did you have anything else to say to that? Because I'm going to jump now to the...
[01:03:52.26] - Mikhail Yeah, I wanted to say that I agree with you. I would really love to see JSDPP, and as soon as we have some examples or some working stuff, I would like to try it in our SDK. Eventually I think we will switch over to JSDPP. It's possible to flip it. It was designed in a way that we can switch the library of serialization.
[01:04:24.08] - Rion Gull Yeah, because that's what I was worried about a little bit when I first saw your proposal. I was a little worried because I don't want to build on the WASM foundation any longer than we have to. But I understand also that you want to move fast, and you want to have an SDK with a good API as fast as possible. I just want it to be built on the foundation of JSDPP rather than WASM DPP, or modifications and optimizations to that. Again, I understand you want to move fast. This is the hard part of the conversation. There's no scenario where everybody's going to get what they want this month in terms of funding and being able to continue developing toward this future. But I did want to sketch out some scenarios that the MNOs can use in their decision-making, with the last three days of voting here, just so that they have an informed decision. So Mikhail, before we jump into that, did you have anything else to say about technical things before I get into the politics of treasury?
[01:05:44.07] - Rion Gull Thunderdome.
[01:05:47.29] - Mikhail I think, I think I'm good. I think I'm good.
[01:05:50.26] - Rion Gull Okay, feel free to just share. Yeah, Thunderdome. Okay, let's see. So here's how the treasury looks. I'll bump up the font a little bit. Here's how the treasury looks right now. You can see there are three days left of voting. I don't know if CrowdNode has voted or not by now. Let's refresh and see if there's a new update. Yeah, 2.96 days available. When you click on Advanced, you can see the recent votes coming in. It looks like CrowdNode has not voted yet. You can tell when CrowdNode votes because it looks like a lot of votes come in at once. So that hasn't come through yet. But as you can also see down here, the remaining balance, if all proposals would pass, which is not possible, would be minus 1,500 Dash. So in other words, the treasury system is 1,500 Dash oversubscribed. There are people asking for 1,500 Dash more than the budget limit will allow. So not everybody's proposal is going to pass, including potentially my own. But there are, like I said, some scenarios where, depending on people's priorities, do you want to prioritize development?
[01:07:18.29] - Rion Gull Do you want to prioritize marketing? What do you want to prioritize? I think all the MNOs would like to be able to fund things, right? But it's all about budget constraints and priorities. So I just wanted to sketch this out. There's a little spreadsheet. It shows the active proposals and three different scenarios in these A, B, and C columns, where if you check a box it will update this sum. This is the amount of Dash that's left in the scenario. In other words, a positive number here would mean there would be 1.2 Dash remaining in this scenario based on the existing budget. So I kind of assume that everything DCG proposes is going to pass. I've rearranged these, by the way. This isn't in the order of the votes right now. It's just collected amongst groups. So here you have the DCG block. Kitty Whiskers Van Gogh is part of DCG, so he has his own separate proposal that's requesting 200, for example. I just assume that everything DCG proposes is going to pass.
[01:08:36.22] - Rion Gull So that's just my assumption. It doesn't have to be that way, but that's how it's been in the past, so I assume that's a constraint. These are some proposals that are relatively high on the list, and again I've reordered these to be DFO-specific. So here's all of your proposals, Mikhail. Here's my proposal. Vijay, here's your proposal. Anthony, here's your proposal. I just put those together for simplicity. Here's the Desert Lynx. No, Joel, I didn't put you down at the bottom because I don't like what you're doing. In fact, I love what you're doing, especially with the Dash Growth stuff. It's just collecting these together. However, I will say that we don't have an option where everybody can have what they want again. And as somebody who's focused on development and actual utility, whether or not the market likes that, that is my focus. We want actual utility, so I'm naturally going to be more developer-focused. So I'll start with this scenario right here, this A scenario, where DCG is getting all their proposals passed. Mikhail, two of your proposals are passing in this scenario.
[01:09:56.21] - Rion Gull My proposal is going to be passing in each of these scenarios that I'm interested in, obviously, because I'm self-interested. But there are obviously scenarios where my proposal doesn't pass, and then that leaves room for other proposals, for example. So this is a scenario that basically assumes that everything Joel has proposed is also going to pass, other than this iOS supplemental proposal, which hasn't passed ever. So I'm assuming that's not going to pass as well. These are both kind of like dead proposals that aren't going to pass. But these are all active proposals that the proposal owner is gunning for. You have Dash Growth's main proposal, 530 Dash, then a war chest proposal, then this Market Across PR proposal, and then this is just a one-Dash confidential transactions decision proposal. That's not very meaningful, but I just leave that checked. So this is the scenario where Dash Growth gets all their proposals passed, and then what's left is, you know, we have difficult decisions about whether these two proposals can't pass, or if mine doesn't pass...
[01:11:14.00] - Rion Gull And these pass. You can kind of see what's available. There are different ways to look at all this, but I'll skip ahead to scenario B. DCG is still getting everything they're asking for. You'll notice I haven't checked Dash Money's proposal in any of these. That's not necessarily because I don't like what he's doing, but I just don't exactly know what "hidden from the learned and clever" is supposed to mean. I've read the proposal. It seems like a lot of higher-level stuff that I personally am not prioritizing. But again, that's up to the network. This is a scenario where the Market Across proposal would not get funded yet. But I guess my pitch here is that there is a scenario where DCG gets all its proposals funded, all of Mikhail's proposals get funded, and my proposal gets funded in this scenario. The AutoShow AJC dev proposal, yours, Anthony, would not get funded. But the main thing here is this marketing push, the Market Across stuff. I just don't think we're ready for it.
[01:12:45.21] - Rion Gull I do agree that it's something we could try, but when it's compared against the importance of getting an SDK out that's working, functional, and a joy to use for developers, I think that should take priority over marketing that thing. So I do see a scenario where it's detrimental to us as a network if we push a marketing proposal and give a bunch of money to a third-party marketing agency. Not Joel, because I'd be more than happy to send money to Joel, but a third-party marketing PR company, I don't think that's the priority for me right now. There is a scenario where we can get most of the SDK stuff funded, and then the marketing stuff can wait. It's a four-month proposal, as you can see here. So if that comes later, I think this PR firm can wait until we have good developer tooling. I think Joel was hoping that the marketing push would help increase the price of Dash, but I think we've done that before. We've tried to contract out to marketing firms to get the price of Dash up, and it just hasn't happened as far as I can tell.
[01:14:15.02] - Rion Gull And I don't expect it to happen. But again, it's not up to me. It's up to you guys. I'm just making my case for postponing, not necessarily rejecting, the Market Across initiative until we have better developer tooling, so that we can say not only are we marketing something, but we have something to market.
[01:14:46.01] - Anthony Campolo And have you considered partnering with Hawk Tuah? That might get the price up.
[01:14:51.19] - Rion Gull Yeah, I'm sure a lot of people have considered it. I. I don't really. I never even really got into that stuff.
[01:15:00.15] - Anthony Campolo Thanks for putting all these scenarios together. This is very enlightening.
[01:15:04.23] - Rion Gull Yeah. And again, I'm not trying to suggest that this is necessarily what people should vote on or what they shouldn't vote on, but I'm trying to give people an opportunity to make an informed decision. I personally think the SDK work is the priority right now, so that we can do grassroots marketing with real applications and utility. And I think we're pretty close with what you're doing, Mikhail, and what Matt's doing. I think there's a scenario where we can get that done relatively quickly, maybe two months, and then fund the evolution, the marketing war chest, and the Market Across initiative two months from now. That would be my preference. But we'll see how it goes. The MNOs do their Tetris moving a lot in the last three days, and it's always exciting, I guess I'll say. Any last thoughts from you guys after seeing that? Just any last thoughts that you wanted to share after having that little discussion?
[01:16:38.08] - Mikhail Yeah, it's a pretty tough month, going to be, as well as the previous one, you know. But yeah, it's pretty cool. We have something about the SDK, which I really like, how it's going. I would just like to say some good things about it. Nothing much from my side.
[01:17:13.24] - Rion Gull Okay. Yeah.
[01:17:17.19] - Anthony Campolo To your stream, to your space.
[01:17:20.28] - Rion Gull Yeah, I'm gonna go jump on that. I do think that marketing is important, but I think it should be grassroots marketing. I think it should be that type of marketing, like with the Twitter Spaces. I'd actually like to do a lot more of that. Joel has said that he would be happy to give me the Dash community Twitter account to play around with and try to get some more discussion from Web2, Web3 kinds of things and TradFi versus DeFi kinds of things. So I'm hoping that that will still work out. Vijay, welcome back. Any final remarks from you?
[01:18:05.08] - Vijay Yeah, I hope that I'll get some support this time. I only got one month of funding, and then you helped me, and I'm thankful for that.
[01:18:18.03] - Rion Gull Yep. Yeah. And like I said, if by chance your proposal doesn't pass, but mine does, I'm happy to send you that 50 Dash your way as well. We'll see what happens. Thanks everybody for tuning in, and I'll see you on the next Incubator Weekly, or on the Space, or whatever, in the Discord. Bye, everybody.
[01:18:41.29] - Vijay Yep. Bye.