 And you get some nice properties out of that too. But I'll talk about that in a little bit until we get started. But I'm gonna give it just one more minute because we can see some more people coming in now and then get going. All right, I guess we can get started and feel a pretty good amount of people in already and more people are joining but probably won't miss too much in my first few minutes. So first off, I would very, very much like to thank the hosts of this. I'd like to thank Aaron, Kamlesh, and Vikram for helping put this together. I really, really appreciate it. I think that these sessions are great and I'm just really happy that we were able to make something work. And yeah, just to give you a little bit about myself, my name's Anthony. I am a developer advocate at Digital Asset and we work on a programming language slash tech stack called Damo. Damo doesn't stand for anything, it's just Damo. It used to stand for something, it doesn't anymore. And yes, for myself, I've long been interested in the more public blockchain space and as of last January, not this January, I started working at Digital Asset because I thought Damo was a really cool language because it solves a lot of coordination problems and private blockchains do in general that I think get overlooked a bit and are just really interesting problems to solve. So one other thing to mention before I get started too is that at the end of this, we'll be doing a little giveaway. We have a Damo certification course and so the first certification in that course or exam in that certification is the associate one, which is the very basic level, but we'll be giving it away for free and there'll be a coupon code on the last screen about that. So at the end of this, you're interested in learning Damo, you can pick up the coupon code and then go ahead and try out Damo a bit and then if you like it a lot, you can go ahead and just take that exam. And of course, you can register it ahead of time too. So I would snatched up if you're all interested once it's on screen. And lastly, you can ask questions whenever you want, more than happy to answer them. So I'm gonna be talking of course about Damo and Damo is a very interesting language in that it's designed to be right once and run anywhere with respect to your persistence backends and other parts of your tech stack. And so the first question most people might be asking themselves and probably been asking themselves for the past 10 years is don't we already have all the programming languages we need? And I'd say we don't. I would say that we have a lot of languages that do the same thing, but in different ways. And even when it comes to languages that we have for blockchains and distributed ledgers, we find that they behave a lot like languages that are for their contemporaries for parts of the tech world that aren't like blockchains. So we have languages that really act as if they weren't running on a blockchain or distributed ledger. And partly because of that, but on top of that, we also end up in a situation where we're managing very low level concerns in our code. Damo's a much higher level language that I'll get into. So really Damo differs in what it does. And what it does is becomes a portable language for DLTs that really abstracts away the ledger itself for you. It's not a great analogy but you can think of this like how you don't always write code to commit to SQL led, to SQL databases anymore. You kind of use libraries that do a lot of that for you. And you can think of Damo sort of like that but it actually goes far beyond that. And also this portability gives us quite a lot of features. So really when we're talking about Damo, the things we get out of it, and I'll actually go into this with some code examples and I'll show you Damo running live, but we end up with Damo being very concise. It's really quick to prototype your use cases and you only focus on your business logic, not your infrastructure. Damo actually from your templates which you can kind of think of as classes in another language and I'll show an example of them, just derives everything that it needs for the backends from that because Damo is a very strongly typed language based on Haskell. And if you've ever written Haskell or another functional language, you might know that oftentimes when you're writing in those languages, you have to write a lot less because the compiler and in Damo's case, the runtime actually does a lot more of that work for you. And Damo's particularly efficient in this too. Damo is very secure by default. So what I mean by that is we have these concepts called signatories, observers, and choices. And these basically correspond to read, write, and execute permissions in a Unix system. They're similar in that way in that when you're writing Damo code in every single template you write, you are very explicit about which parties can create a template, can be responsible for being a signatory on it, which parties can read a template, can basically be an observer on it, and which parties can execute what on a template, basically having different choices on that contract that they can exercise. So these are all explicit up front and that gives you a lot of very nice security and privacy properties. It's also very fit for purpose here. When we're talking about distributed ledgers, we're talking about multi-party systems and Damo is really designed for multi-party systems. It's not so much designed for single-party systems or systems where essentially one bit of code is responsible for the entire thing. Damo's not really designed so much for that. It could do it, but I think you might find other tech stacks more useful in that case. Damo's also portable. So when you write your Damo app once, it works across multiple platforms and that means that you don't actually have to change any code, the same code that you, and I can actually show this if we have time for me to show it, deploying on both, but the same code you write for fabric and deploy to your Damo runtime, you can then compile it and deploy it to a Damo runtime that's connected to Sawtooth, for example. And lastly, Damo also is becoming much more interoperable. We're still working on this, so it's not perfect yet, but we have another part of our tech stack called Canton that is essentially going to enable different disparate ledgers. So if you have a Sawtooth node and a Fabric node and you have a Damo application and you wanna run it on both and get communication between both your Fabric and Sawtooth node via your Damo application, you'll be able to do that. You can actually try it out now at canton.io, but it's not, I wouldn't say it's ready for production in all cases right now. And yeah, so that's basically the Damo tech stack. And so just briefly, we can think of Damo as a, and really it depends on who you are. So if you're a developer, it's kind of a consistent language for distributed and relational databases and you only need to know one of them. In that way, it's also very similar to SQL in that you have a very common language for talking to these different ledgers. It also reduces complexity when developing distributed applications. So if you're a project manager or a developer, that might be very interesting to you because there's a lot less boiler play code and a lot less, I like to call it scaffolding that you need to put up in order to get your application running. And this, of course, if you're a decision maker, results in faster, more accurate development of your distributed applications because there's a lot less concerns for your developer staff to worry about. And so now we're gonna get a little more technical. This is starting into the technical portion of this presentation, but, and of course, if you have any questions at any time, always feel free to interrupt, I really don't mind. But here's how Damo looks and Damo, this is an actual application that I'll show in a little bit. But Damo essentially has these concepts called templates. And what a template is, is kind of like a class in an imperative language. And so when you're using Damo, what you're doing is you're instantiating these templates much the way you would instantiate a class. And then that's basically a sort of contract on the ledger where different parties can do different things. So Damo's very explicit. So let's get a little into this. You can see on the left under the proposal template, there are arguments that it accepts. So here, the beer proposal accepts a beer IOU. And then that's basically the things you need to instantiate your template. So you need to provide it a beer IOU in order to instantiate the beer proposal. And the reason we're doing this, instead of just doing this in one template, where we would just have the IOU is because Damo, like I said, is very explicit. So this beer IOU, if we look over here, we see that it requires a signatory of giver and recipient. That means it needs two signatures from two different parties in order to actually be instantiated. So the way we go about this is we create our first template, which has our signatory, which is the giver. This is the person offering it, the observer, the person receiving it. These correspond to the giver and recipient on the right side of the screen. And then we have some things we're ensuring. And then we have a set of choices. And we have choices where the recipient can choose to accept this offer or reject it. Maybe they don't drink beer or maybe they don't believe that this is an offer that they want to accept because they don't wanna owe somebody something later. And then we also have the option where the giver can actually cancel this proposal. And one nice thing, one nice property of Damo is this proposal here, when you execute a choice on it, it's atomic and it archives that proposal after that choice is executed. So that means you can end up in a situation where both accept beer and cancel beer are called at exactly the same time and both go through. There's no real worrying about race conditions here because Damo is a UTXO-based piece of software that essentially makes sure there can't be any conflicting state here. Everything is nice and atomic. And so the other thing to note here too that's really interesting and cool I think is that the giver and recipient, you can end up in a situation where somebody is reading code where for example, I have an obligation to somebody else for this proposal. Like I can automatically make my obligation for somebody else. Like I can automatically say, okay, I owe Aaron something. Aaron has to agree that I owe him that thing. And that really helps avoid a lot of just issues down the road where people may end up having obligations to each other that they didn't intend. And so it's really nice that everything's explicit there. And then because somebody signed off because Aaron goes and says accept on this IOU, what'll happen is it'll go ahead and create this IOU and it can do that because now the proposal contract had my signature and the one other signature required for this IOU was Aaron's and so then it gets created. And then later Aaron can actually mark that as received. And it is actually quite a lot of functionality that we're getting in about 30 lines of code. Oh, I'm sorry, I haven't had the chat up. So I haven't seen the questions, I apologize. Rafael says it's impossible to find anyone who can reject a free beer. Yes, exactly. So that's often though when you think when you're coding these things and then you end up in a case where somebody would. And Ram has a good question here, what does peer do? Peer basically within this functional context is similar to what it does in Haskell which is it just does nothing. Peer is basically just kind of returning, I forget what they call the thing in parentheses but it's basically returning nothing. And what that does as a consequence of the Damel contract is it archives the beer proposals such that no other things can happen. So beer proposals is instantiated, somebody calls reject or cancel, that exercises peer and by the very action of calling that choice this proposal gets archived. So that's why rejecting cancel are the same code. These are kinds of really just niceties. Actually as the giver, I wouldn't need this choice down here, cancel beer because the signatory who is the giver here doesn't always has the option to archive a contract. Archiving the contract is basically a choice that the signatory always has. And so that's kind of how that works. So how enforceable is this when we are trading slash settling stock? Damel actually is being used within the Australian stock exchange, Hong Kong exchange. So if they trust it, I'd say anybody could trust it but it is really actually designed for making sure that when you're settling things between multiple parties that it is as safe as you can possibly get it. And yeah, so that's a great question. And then Giovanni has the question here, choices seem to be actions or possibilities that a signatory can perform, probably confirm, yes, a signatory or observer like you said there can perform these choices but each and every choice also has a controller. So you can have a controller who's a beer.recipients and can control some choices and the beer.giver can control other choices. And say this IOU here had a third party on it but they weren't in the signatory or observer. You wouldn't be able to actually have them do the choice. They would have to be specified as an observer at the very least in order to control choices. How do we query proposals for proposals still in flight? That's a great question. So you can query for things, commands submitted to the ledger that are still in flight. There's a variety of ways to do that especially through the ledger API, the JSON API. I believe there is a way to get the active contract set so you can do that. So I can actually show you how it works in this code too is that when I go through the code here, what I'll show you is a query where I asked for all the beer proposals and then get them back for the user that's asking for them. And I actually asked for them in a very broad way where I try to get back more data than I can than I should and DEML then goes ahead and enforces that I only get back the data that I'm supposed to see. For a choice to enforce, do we need controller signatures? Yes, sort of for a choice to execute you basically need the controller to be the one submitting that transaction to the ledger. So for example, this reject beer, the recipient needs to actually sign a transaction themselves with their authority to go ahead and reject the beer. And yeah, that's kind of how it works. Also signatures are a little different here in that they're really managed by the node that you're talking to. And then you have a permission layer in between that, say OAuth or some other IAM that is responsible for making sure that it itself can sign for that recipient that that recipient has the right token to say they're the right person or the right party because parties aren't always people. Sometimes parties can be organizations or groups within an organization. So that's what DEML looks like. And these are great, great questions. So always feel free to keep them coming. And then DEML actually goes ahead and produces or powers front ends that look exactly like this. This is all the code I wrote in view.js for my DEML front ends. You can actually though write code. DEML has support for Java and JavaScript essentially for easily making a variety of classes that it just generates from your code that make them very easy to interact with your underlying DEML ledger. And the nice thing there too on the JavaScript side is it actually generates TypeScript but you can use that from vanilla JavaScript. Like I did here, you just don't get the nice type enforcement that TypeScript gives you. So let's actually go ahead and check out a toy production app. And we're going to check out the OBEER app like I talked about before. So what we're gonna do now is we're going to live deploy this application. So I'm gonna deploy this to Fabric. And what I'm going to do is go to our demo on Fabric repository. What I would normally do is I would make sure my fabric tools are installed. I would set up my path and then I would go ahead and get clone. The one thing that I'm gonna skip here is the cloning just because once I get down to these steps it starts downloading a bunch of Docker images and building them and that takes a little bit. So I've already pre-built these so that they're ready to go. And one thing I'm going to do before I do this is make sure I'm not running any other Docker images right now. That was running some stuff. Take those. All right. Let's go ahead and navigate into this directory here. And then we're gonna run gen.sh which basically generates a config for us. You can actually manage the configuration yourself as well. It's in config.tx but it's in a different folder. And yeah, so that just generates a quick test config for us basically. And then we go ahead and start Fabric. And so what this is doing is starting up the Fabric instance itself. So that's up and running now. And now what we're going to do with our Fabric instance is we're going to start our Damel driver to run against that instance. So I'm gonna hop over here to the deployment guide. This deployment guide actually was written for a different application called create Damel app. But one of the nice things about Damel is that the deployment is so similar I can just use this one for my different application. So now we're gonna run the Damel driver which is basically the interoperability layer here that is going to talk between our Damel code and the Fabric instance and allow data to be read in, written from it. So we'll start that up. That's actually going to take a moment. So while we're doing that I'm gonna go ahead and build my Damel app. So the app that I'll be building today is called Obeer. It's for owing your friends a beer. It's actually a double on big old notation. And so what we're gonna do here is Damel build which will build the application. And then we're going to run Damel code GenJS. And in a little bit too, once I have the application up and running I'll actually show you some of the code behind this particularly with respect to the front end and how Damel enforces some of these nice things. So with code GenJS now what that's done is and actually I'll show you this now because it's a good time to is it's gone ahead and taken our Damel models with our over here. This is basically the same code that I was showing you on the slide plus some tests and what it's done is it's created all these other nice nice little classes here and we can actually go ahead and import this. So all the classes related to here so we'll have a beer dot beer proposal or beer dot beer dot beer proposal that we can actually go ahead and access. So right here we see that we have this nice little class that we just made for us and we can even see that it has all these choices on it and we didn't have to write any of this code or show teach our application how to interact with our backend. This was all just made for us, which is very, very nice. So I can go ahead and just query the ledger with that. We got another question here. Do we have to know Haskell to debug the runtime? I don't think you're going to end up in a situation where you need to really debug the runtime. So I wouldn't worry too much about that. If you wanted to modify or change the runtime, then I'm not sure because I don't actually work on that that's a great question. That could actually be the type of question that you could ask on our forum. And you can go to discuss.demo.com, click on new topic and ask the question in the questions category. But personally, I wouldn't worry too much about that because if you reach a point where there's a bug in the runtime, that's something that we have quite a lot of developers on our end at digital asset, you know, we are a company of about 150 people now, that yeah, I wouldn't worry too much about that. But I would imagine that I know the demo compiler is to more closely answer your question. I know the demo compiler does use GHC on the backend. So that's very much Haskell. And then the demo runtime, I imagine parts of it would use, would be related to Haskell because we have a lower level language called demo lf that's basically a stripped down demo that our demo application compiles down to. And then that is, then there's probably other code in there that is not Haskell, but chain code and other things and probably also depends on what ledger you're talking to. So yeah, I apologize, but I can't answer that question perfectly. So anyway, kind of related to that actually though is like I said, demo compiles down to a demo lf which is a lower level language that actually runs on our, on our demo driver. And it has a .dar file when it produces this. And that is actually very similar to a jar file in Java in that it's a self-contained zip file that has all the parts of the application that you need to deploy. And you're very welcome to add. Yeah. So anyway, now we're going to go ahead and deploy this application because I assume our demo driver is up and running and it is, you can actually see we're running on port 6865 over here. And then if we come over here, you can see that our fabric node has actually been talking to our runtime when the runtime was getting itself set up. So now we're going to deploy the code. And in order to do that, we'll hop over to our deployment guide. And right here, we have this nice little command demo deploy. I built this application, but demo deploy actually rebuilds it, but none of the codes changed in between so it doesn't really matter. So it's deploying and it's also allocating a couple parties that we're going to use for testing everything in a little bit. And what you can see here is that there was a bunch of data written that came through to our demo driver and then was also written to our fabric node. And so that's kind of how that works. And now something else we get for free is our JSON API. So this is actually, this is nice for two reasons. One, you don't need to build out your own JSON API. Everything is provided for you and is very easily implemented on the front end side. The other nice thing about this is that once you've written one demo application, you'll know how to use the auto-generated API that you get and you can go ahead and use it again. It's almost exactly the same why you're just changing out templates and what you're doing. So that's really, really nice to have. So that's going to get started up right now. That'll just take a moment. And yeah, so while that's getting started off, I'm going to set up the front end. With the front end, the one thing I do need to do is I need to make sure I have the right ledger ID. So depending on what you build this in, it'll be different how you specify it, but the front ends and the JSON API in particular want to make sure that when you're talking to them, you're requesting the right ledger. This is good for when you're developing so that you can have a ledger in called development and you can have one in call production. And then you never end up in a situation where your UI is accidentally talking to production when it should be on development and vice versa. So that's just a nice little thing there. Let's see if our JSON API is up, it is. And now it's running on port 7575 and that's where we're going to go ahead and talk to it. So the commands here are actually for starting up a little React app. So I'm going to do it slightly differently. Gonna hop over to my readme for starting my UI. I've already ran the on install since we don't want to wait for everything. And I'll go ahead and run yard serve within my UI directory. And then in a moment, we'll get our front end and be able to talk to our application. And so yeah, this is our front end. So I'm going to go ahead and log in as Alice. We'll see right here, I'm just typing in names. We do actually have facilities to do proper full authentication, but this is just an example app. And one thing we released or are in the process of releasing right now with the 1.10 release candidate and stable is hopefully coming out next week is a middleware for OAuth so that actually implementing the OAuth workflow is now very easy in demo. So I'm actually waiting to be able to update my application in order to take advantage of that. And so as Alice, I've just offered Bob a beer and a lot for Carol one too. And so we're going to get separation of concerns here. Bob and Carol aren't going to be able to see each others. And Alice is only going to be able to see the ones that they owe each other as well. And I can actually demonstrate how each of these users is really only able to get the data that they're supposed to. And that's right over here. You can see in get beer proposals, what Alice did when she logged in or I can actually log out and log back in now to just run that bit of code and make sure it's pulling it right. When Alice logged in, she said to the ledger, hey, ledger, I'm doing a query and I want all the beer proposals. I don't want them limited just to me. I want everything. And the ledger went ahead and said, okay, here are the proposals you can see. And she wasn't able to see any of the ones that she couldn't. So for example, I can go ahead and log in as Bob and I can see that offer from Alice. But as Bob, I can actually go ahead and offer Carol a beer too. And I'll go ahead and accept the one from Alice. So we can see that. But what we'll see is when we log back in as Alice, Alice went and requested every proposal. But Bob's proposal or Bob's offer isn't going to appear here because that was between Bob and Carol and Alice wasn't involved. And so Alice can go ahead and say cancel her offer to Carol and Bob could later go in and accept it, accept his offer from Alice. And then Carol can go ahead and accept her offer from Bob, for example, and mark that as received as well. And what you'll see too is that data is actually going, it's coming through the ledger API and then it's hitting our demo driver and then our demo driver is committing it to our fabric instance. So that's basically it all in a nutshell. But then, since we have some time and obviously I can also answer questions if you have any more, but what we can do now is we can go and take that code that we wrote and go ahead and deploy it not to a fabric instance, but to a sawtooth instance. So I'm gonna first just get rid of all my other containers and I'm gonna add to my demo on Sawtooth. And this one's going to just be slightly different. One of the reasons I like showing the fabric one first is that fabric, when we're going through the process of starting it, this one actually starts up a Sawtooth node and our demo driver together. So it's kind of nice to separate those for demonstration purposes. But yeah, let me show you that one. Did I take that in my UI? Okay, I did. So yeah, this is the forum by the way too. I definitely recommend if you get interested at all in demo, check out the forum and go ahead and click this link and you can actually have a bunch of useful links for you to check out to kind of learn demo and get an understanding about it. If you're interested in learning about it more, of course. Also bit.ly slash try demo is the other way to do that. You can just type in bit.ly slash try demo and it'll bring you right to this page as well. So anyway, we're gonna hop over now to demo on Sawtooth. This is actually built by one of our integration partners blockchain technology partners is what they're called. And yeah, so they've made this and a few other of them, I think. And yeah, it's really cool. So now we're gonna, don't think I need to run that build step actually. Let me skip that for a second and see. So what you would normally do though is you would go run the build doc, get Docker installed if you didn't have it, get clone everything and wait a few minutes for the project to build. And Ranga Swami is asking for GitHub links to the different demos we're demoing. Yes, absolutely. Let me actually share some of those. So share those in chat right now. This is demo on Sawtooth. And this is your repository and probably the most important of all is demo itself. So let me get you the link to that. And yeah, so you can go work through there and check that out. One other thing though, if you're interested in all of this is to actually go to demo.com slash learn. And there you can actually go and run a lot of these things just within your web browser to just kind of try them out and get a feel for them. Obviously we love people installing and trying demo on their local computers. But if like the first thing you might wanna do is you can go and try out deploying demo on production ledgers and this will go ahead and run through where you can actually deploy that same application. So you can for example, go and say, oh, I wanna try doing pulling demo on Sawtooth. And you can start that scenario and basically you can click all these commands in order to run an application and build it all in your web browser. This runs in the cloud on other instances of a Linux box. So yeah, that's another option for that. You can go to just demo.com slash learn. But of course, once you wanna really get started so I went to definitely install the demo SDK and then go ahead and try these applications out because obviously there's no learning like doing it yourself. And yeah, so first I'm gonna just try, I might have to build this project again. So it might take a moment, but hopefully I don't. And we're gonna do Docker slash run, let's start. Yep, so I need to build this again because I deleted all my Docker containers. I probably shouldn't have done that. So we're gonna run that. So I already have Docker and everything installed and then we're gonna run build.sh. And hopefully that's going to complete within the next few minutes so that I can finish showing the rest of this. But while we're doing that, I mean, we have plenty of other things we can kind of look at. So over here, if I come back to my little page here, installing demo itself, it's pretty easy. You can just, it does have a Java dependency. So sometimes that can hang people up on occasion, but we do have some instructions here for managing that. If you're on Windows 10, you have an installer that you can run. And if you're on Mapbar Linux, you can run this command locally and that'll go ahead and install, install a demo automatically. There is also a manual download. So if you want to verify everything or do some sort of non-standard install, you can go ahead and follow the instructions for manual install. And so there's that. Like I said, demo.com slash learn is a great place to try things out for the first time. docs.demo.com is a great place to really learn demo and dive into it. So we have the getting started guide. We were just there at its own SDK, building your first application, adding some features to it. We have that. Then we have writing demo. And this is mostly, I believe, written by Bernhard, who runs a lot of our demo product side. And he's just produced a great guide on really learning demo and really understanding it. And then we also have language references too, so you can dive into that and a whole bunch of documentation on everything else related to demo. Yeah, we also have our YouTube channel where you can see recordings of this video which we'll be up shortly after. And a variety of other ones. We have tech examples and we also have things where we explain different verticals and different use cases where demo is being used and where it's beneficial. And yeah, then we have a bunch of other things too. Discuss.demo.com, the certification, demo.com slash certification where if you wanted to get certified in demo, you can check that out. And then down here, the demo associate exam is the one that I'll be giving away for free at the end. Well, I could actually kind of just show you the code now. It's HLDelui. So if you were to go to demo.com slash certification, you could like purchase the exam, but then on the following screens when you're actually entering it, there'll be a section for coupon code so just enter HLDelui in there and you'll get 100% off. This is limited to the first 20 people that take it. So if you are interested, go ahead and take it ahead of time even if you're just a little bit interested. And then if you decide you're going to learn demo and later want to go through the certification to kind of test your skills, you can go ahead and do that. And that has a question here, is it possible to migrate existing go-chain code to demo? No, it is not. But what I would say is that the nice thing about having that chain code already written is you already know how your application is going to work and that's a major benefit just in general, obviously with any application, but with demo you'll be able to say, oh, all these concerns I had and all these different parties that I know about that I want to work with, that's actually really easy to transform into demo code yourself. But unfortunately no, we don't have a layer to translate it. We even do have, there are some blogs, there are blogs that go into kind of comparing demo code to others. There was one, I don't think it was Go, but it might have been Hotline or something on Porto where there was translating between it. And so there are blogs on it and just not sure I'm gonna do it. Moment, I'll actually follow up with you on that and send it out after this. So now Harsh has a question. Hi, I was using demo and went through the demo design pattern. So I wanted to know whether you were trying to achieve pluggable consensus using those patterns as they enable to write transactions to different layers only after certain signatures of those transactions. Only those signatures that we had to find. Yes, so basically it's not particularly consensus in the sense of the network achieving consensus. For that we leave it to the node, but when it comes to different parties having to consent amongst themselves like consensus versus consensus, yes, that part is something that we want to be very explicit about. And so the only way to write certain transactions to ledgers is to make sure that all the signatures that they require are present on those transactions. So hopefully that answers your question. That's a great question, Matt. Yes, thank you for that. So it is two way consensus, two times consensus, one at the code level and one at the ledger level. If you deploy in suppose say fabric. Yes, that's correct. So you'll basically have at the ledger level is you're making sure that different parties are consenting to the contracts that they are parts of. And then at the fabric level that's actually achieving the network wide consensus these are the valid transactions that happens when and where and in the order that they happen. So fabrics doing the ordering as well, everything that fabric does. And Anil is asking a question here. So I write once and can have sawtooth beers and HF beers but those sawtooth beers stay in the sawtooth world and HF beers stay in. Yes, so it depends. So like I had mentioned, there is, let me just show that really quick too. There is canton.io and this is our synchronization protocol that we're developing where it's going to enable you to not worry about that world and actually get interoperability. So right now with the demo applications that I'm demoing and deploying, yes, that's true. But if you use canton, your sawtooth and your fabric beers can actually cross-chat if you were to deploy it using canton instead. And so you would still have the same demo code but you would then have this additional layer that allows for that interoperability. And that's a really, really cool part of demo that's still being worked on and that's just at canton.io if you wanna check that out. There's a bunch of documentation on it and you can even go ahead and download it. I've also seen some interest from other times as I've given this talk. So I think we're probably going to eventually do a talk on canton as well, hopefully, if everybody's amenable to that, but that's something we could always chat about more in depth. But yeah, anyway, so now I have a second here. Okay, so now I've got demo on sawtooth built. So we've built it in time and answered a bunch of more different questions at the same time. And now what I'm going to do is I'm gonna start it up. So right here, well, Aaron's interested in learning about canton. So I think we'll definitely do something in the future on canton. I'm gonna make another one. Cool. And yeah, so right now our sawtooth ledger is starting up and it's going to start up not only sawtooth itself but also the demo driver you'll see in a moment, you'll see RPC going by and that's the demo driver. So you could actually start them up separately like we did in fabric. It's just that this little shell script that helps that out doesn't have that going on. So the RPC starting up and should be running in a second. So I'm gonna just hop back over to here. And yeah, okay, so we've started and we're running now on port of 9000. So it is slightly different. And so what I'm gonna do is I'm not gonna build the code again. I would actually like to show you this without truly building the code again but demo deploy rebuilds it. You can just trust me that this code over here has not changed in any way to be special to sawtooth. But I'm going to go ahead and deploy this code now to port 9000. And you'll see just as before we'll start committing transactions. Not sure why that's not responding. That should definitely be working. But that's the fun of live demos. Let me cancel that one quickly. I guess maybe this wasn't fully. I seem to have some awkward time out. Okay, I'm not sure what I did wrong here. Probably done something wrong. Yeah, anyway, if you want, you can go to youtube.demo.com slash demo driven. Maybe something's changed since I last built this and I need to file a bug report. But you can actually see that over there or I do have videos up of this talk previously where we went and deployed demo on sawtooth. But yeah, so that's the presentation ending on a high note there. And if anybody else has any other questions, you can feel free to ask me. You can head over to bit.ly slash try demo. And through there, you can go and see all the links and get to the forum and ask questions and no report logs if you encounter them. Like I just did that. But yeah, thank you very much and thank you all for asking the great, great questions. I have a couple of minutes left if you have any more, but if not, then I can give you a few minutes back. Awesome, I'm glad you've all found it very useful. All right, I'm gonna stop sharing then and yeah, this is.