 been markup language for smart contracts on a variety of different frameworks, including hyperledger fabric. So another meeting is just wrapping up, and we'll get started in a minute or two. I'm going to wait for some more people to join. Awesome. Thanks, Jim. And yeah, let's give it a few more minutes. Also, Damel, being all caps, has proven to be very misleading. Damel actually used to be a different language, which was a markup language of sorts. But Damel today is actually a functional programming language based on Haskell. And we've actually recently dropped the cap. So I'll actually hop on video. And you can see I have an old t-shirt where Damel is still all caps. And this is no longer on brand. I probably will be chastised for wearing this. OK, fair enough. I'll just put a comment in the chat right now. So the question is, before you even start, we'll wait for more people to join. But would you categorize Damel as, I'll call it a DSL, a domain-specific language built on top of Haskell that basically compiles down to that as a runtime? Yes, somewhat. It's built with Haskell. So it compiles down to an intermediate language called Damel LF. But it's very Haskell-like. And we actually use the GHC compiler on the back end. So yeah, it is kind of a DSL for these things, though. Yeah, yeah. Cool. And Jim and Anthony, I don't want to interrupt. But just to let you know, the live streaming is now up. I put a link to that in the chat. And again, as you know, there's also a chat on the live stream page. So when you get to the Q&A, you'll probably just want to look at both places. And I need to jump for another call. But Jim, your set is the co-host. So I think you're all good. I'm all set. Great. Awesome. Awesome. Bye. Thanks, David. Let me grab the live stream here. Anything that makes blockchain easier to build and support is always interesting. So we do have a number of people listed here. And everybody can see my screen, right? Yeah. So Anthony, is your company based out of Boston? No, we're based, I guess, out of New York and Zurich, where our two largest offices are. Yeah. And now Boston, well, I've been up there many, many times. Yeah, it's gotten worse now than we do today, for sure. That's surprising. But yeah, we had so much snow. It's still going, actually. It's quite incredible. And I'll give it another minute, and we'll get started. So there's certainly a lot of interest in space. The other thing that's a bit of a challenge, I assume on your end, is the blockchain architectures underneath are not stable. Much like, I guess, Yosemite or Yellowstone in that area, I would say that the architectures change frequently. So that must create some challenges on your end for the mapping there. Yeah, it does. And it doesn't create challenges for me, but it creates challenges for some of our engineers. But yeah, in general, there's definite change. And it's not been too bad, though, for some of the upgrades. And I haven't been too intrinsically linked to them. But yeah, it is something that sometimes versions might fall behind by a release or so for what Dama will support just because you have to play catch up. Hopefully, as time goes on, we'll be able to establish longer, more solid relationships with some of the larger blockchain developers and then get a little better on that. But yeah, there's definitely a bit of a delay. Yeah, I will say the open source ones, at least for the most part, do a decent job of showing you potentially what's coming. If you're the guy who has to map Dama to Fabric or Ethereum or one of those, they usually have a backlog of RFCs that are prioritized to give you some clue of the challenges that are coming your way. Yeah, exactly. Well, so with that, let me just stop and reintroduce our meeting today. We'll get started. So we're going to talk about Dama, a new smart contract language that runs on a variety of different blockchain platforms. And we have Anthony Sardi today to talk about it, who has a long background both in Bitcoin and smart contracts and has been working in the space for about eight years now. And he's the developer advocate for digital asset. And so with that, Anthony, I'll turn it over to you and you can give us in detail on what Dama is all about and how we can get started. Awesome. Thanks, Jim. Yeah, I've been in this space for a while. First, though, I wanted to say thank you, Jim and David, who had to hop off for another thing. But thank you both very much for helping put this together. I think it's really great that you've been so open to giving us a platform to talk a bit about this language that we produce. It's just really, really great. So thank you very much. And yeah, to introduce myself, I've been interested in this space for probably about eight years or so now that we're in 2021. I've been more because I had a passing interest for a few years and then I started developing a much stronger interest as time went on. So probably around 2015, 2016 is really like when I first really got interested in the space and got really interested in things like Ethereum and Bitcoin. I got interested in Ethereum because I thought smart contracts were really cool. Actually, back then I didn't understand Bitcoin's monetary proposition. So that wasn't that important to me. So I was really interested in smart contracts. And I think smart contracts themselves actually, while Bitcoin really established itself, smart contracts themselves are really still emerging and are a really exciting space. So I'm actually really happy to be working on them full time. And yeah, so that's me. Now I'm at Digital Asset working on an open source smart contract language called DAML. And essentially what DAML does, and I'll talk about this more as we go on, but it is a language that has an intermediate runtime that essentially we use the underlying ledgers like fabric, sawtooth, and others to commit data and to give us our consensus over our application and its state. But it doesn't actually embed itself into where it's actually executing within the same fabric node, for example, in the same way that chain code would. So that's a slight difference. But I'll actually discuss that a little bit more later. Also, we are giving away some t-shirts today. So the first five people to ask a question will get a t-shirt. If you want one, the designs actually that we have up are even a bit nicer than what I have on. Not to say that this t-shirt's not nice, but our newer t-shirts are very pretty. And you could just see them all over here. And yeah, I actually have this one too, but it's in the wash. And anyway, that's what we're giving away. So if you're interested at all, go ahead and check that out. There really are. Go ahead and ask a question. Sorry, I was doing too many things at once. I can keep back what I was saying. Anyway, so basically the first question you could have for smart contracts and really programming languages in general is, don't we already have all the languages we need? And my answer would be, we don't. And what we actually have are a lot of languages that do the same thing in different ways. So for example, if I were to write in Python, I would basically be writing not 100% similar, but about 80% similar to if I were writing in C-sharp, other than some things about how I actually structure my classes and those types of things. But really, in general, we're doing imperative languages and we're doing class-based languages. And so Dan was trying to do this in a bit of a different way. And so even when it comes to languages for blockchains and distributed ledgers, we're finding that they behave like they're contemporaries and that they also manage very low-level concerns. So what I mean by the first part here is that when you're behaving like you're contemporaries, we've seen things like, for example, Ethereum, several years ago, had a re-entrancy attack on one of their largest smart contracts. And that was because, essentially, the way a blockchain actually works and commits data was incongruous with the way that solidity code really was structured and in such way that you can actually execute other code inside loops and you're not getting the guarantee that previous things that you thought terminated have actually terminated. And so that was a very interesting learning to have. And we're actually getting a lot more of those when we try to fit these very imperative languages sometimes to the structure of, no, we want to commit a block of transactions and we want those to be final. And along with that, we're also finding that we're having our languages deal with very low-level concerns almost to the level of you're programming the database directly and when it comes to current modern languages, we don't really do that in general outside of blockchains and distributed ledgers. We actually have a good deal of abstractions that make our life a lot easier there. We have a question here from Sam. Is it a common runtime being leveraged across platforms or are you having to write an implementation of the runtime model here for each chain? Also, is this runtime code formally verified for mathematically? Okay, for the first part, the question is basically, do we need a different implementation of the runtime for each chain? In general, in somewhat, yes, in somewhat, no, we do have, for example, demo on KV is kind of for when we're doing key value stores, that would be the base and then they would essentially make it talk to each and every one of those. And then in other cases, yeah, it is completely custom. But there are some efficiencies there, but essentially, yeah, each time a runtime has to be custom made to the type of architecture it's running on. So there's a custom runtime for fabric, there's a custom runtime for sawtooth, there'll be a custom runtime for Bessu. And also, is it formally verified? I don't know if the entire thing is. I know we have rather large test suites, obviously, but as far as formal verification, I don't believe we're fully formally verified, but that's actually a very interesting question. So if you wanted to, you could always ask on our forum and say, what's this that is of demo drivers? Which demo drivers, by the way, is what we call runtimes? Runtimes with respect to formal verification. We could just ask that in questions. Do you have a formal verification tag? We do not, we should. Formal verification. No, you can ask if anything. And we'll probably get an answer in a little bit. We're also fairly active forum too. So if you ever have a question like that, I can't answer it, I'm sorry, but I'm sure somebody will be able to. And that is a great, great question though. And so, yes, just to go back, demo now really differs in what it does. And demo basically is a portable language for DLTs. And so that gives us quite a lot of neat features. And so when we think about this, we can think about some of the things that being this style of language and how we actually structure demo, we can get very concise applications in terms of the code written for them. We actually have a couple of blog posts where we compare code written in one language versus another for demo and others. And what we find and what anybody will tell you when they're working in functional programming languages like Haskell, for example, is that they get a lot of these pool efficiencies in that they can write a lot less code. And so that carries over to us as well, which I think is great because we're really when we're doing it and I'll show you some actual code. We're talking about use case, we're sorry, not use case, we're talking about business logic. And we only really write the business logic and the runtime figures out everything else for us in terms of data persistence. And then the ledgers also figure out the actual transporting of that data and consensus for us. And then it's very efficient because we get a good deal of security and privacy without writing additional code. I'll actually explain that kind of how Damol has the separation of concerns and kind of similar to how UNIX has read, write and execute operations. Damol has signatories observers and choices, which kind of map one to one to those respectively. It's also designed for multi-party systems where you're dealing with multiple people. And so like all these things are expressed as intrinsic parts of Damol. And it becomes very portable in that we end up with Damol applications that when we write it once, we can deploy it anywhere across platforms. And also we're working on making these things much more interoperable. So right now, obviously, Damol applications can be interoperable with each other within the same network. And we also have a technology called Canton that will allow for intercommunication between these different networks. So if you have a Fabric node and a Sawtooth node and you want the same applications to deploy to both of them and talk across them, that's something that we're working on. It's actually at canton.io. I'm not going to talk really about Canton right now. It's still very much in development, but it is there and you can actually try it out too. But anyway, that's that. And so at a high level, we can say that Damol is a consistent language for distributed and relational databases, especially if you're a developer, that's probably what's most important to you. But it also reduces complexity when developing your distributed application. So if you're a developer or project manager, that's probably something that's really important. Also, when you're writing your Damol application, you don't have to think too much about what you're back and did for structure is going to be at. You just have to make sure it's going to be at least one of the things that Damol involved. That it's going to be one of the things that Damol supports. And there's another question from Sam. Does Canton involve state channels? That I'm not sure how Canton implements it, but that's a really great question for the forum. I'll definitely also make sure to ask that once this is over, because that's a good question. No worries. I'm fine talking about it, Sam. If anybody has any question about Damol or the associated things, even if it is Canton, feel free to ask them whenever you want. But anyway, this ultimately translates to we get a lot faster, more accurate development of distributed applications. So no matter who you are, and especially if you're a decision maker, this is really important because you don't have to worry about, oh, this infrastructure wasn't right for me. I want to switch to this other cool technology, but I can't now I have to reimplement my entire application. So you can really avoid that. And we actually see too, a lot of people really love Damol for prototyping. And then you can go ahead and take that prototype and just expand upon it, because it is written in such a functional language and everything is so composable. The concerns are so explicit that it's really like, you don't have to discard your prototype because truly, as in any good functional programming language, there's generally one or two correct ways to write an application in every other way is hopefully impossible is how we try to do that. But anyway, let's talk a bit now about kind of what Damol looks like. I could even show you it in Visual Studio Code. Obviously we have a light IDE and development toolkit and command line assistant along with this too. But just since we have it on the slide, here we have our two templates. They're called beer proposal and beer IOU. And this is also where the talk gets a little more technical. And you can kind of think though of these templates, kind of as if they were classes within an imperative class-based object-oriented language. And essentially these templates, when you use them, they get instantiated as something we call contracts, which is the actual instance of it. So in the other way, you can think of these, which is fun because Damol does so much of this work for you, is that you can think of beer proposal and beer IOU as actual tables within a SQL database or just for thinking about it, in that way or... Sorry, everybody can just mute themselves, thank you. And anyway, what I was saying there is that this is another cool thing is that Damol's concerns are such that not only do we get a class here with this declaration, no worries for the noise, it's okay, but we also get a description of what our table is going to look like or really what our data structure is going to look like. I'm gonna talk about it in terms of SQL, but I don't actually mean SQL SQL all the time. Also Sam mentioned that my slide mentioned relational databases, does Damol work with other databases? It works with relational databases such that it works with other databases and it will eventually work with Oracle DB, it doesn't work with any RDF or GraphQL or other databases right now. So it's really the SQLs and the blockchain slash distributed lectures of the world. But yeah, that's a great question. Anyway, so we can think of these declarations here now and then we can think of these declarations here now and then we can think of these declarations these declarations here now with with are basically kind of like rows in our tables or columns in our tables and then we'll populate them with contracts that are rows to break that down into the SQL metaphor. And then we have some fun things here is that because we've been so explicit, now we can also be explicit not only about what data we're storing but who has rights over that data. So we have signatories to a contract which basically mean this is the person that has instantiated the contract. That basically has the authority to write the contract. So obviously you can instantiate this template as many times as you want into separate contracts but each and every one is going to have a set of signatories. And in this case, our signatory is going to be our beer.giver which comes off of our beer RRU template here. The observer, you can think of this kind of as the read permission who can see the contract is the recipient. So they can see that proposal has been made to them while the giver can actually write and instantiate the proposal. And then we have some guarantees and then we have choices which are essentially like execution permissions. We basically are saying for each of these choices we can have various controllers that can actually exercise the choice. So the recipient can actually choose to go ahead and accept the beer in which case they will create it and instantiate a beer RRU contract between the giver and recipient or they can choose to reject the beer or the beer giver, if the proposal hasn't been accepted yet can actually go ahead and cancel it. And one very nice thing about all this is that these are all structured as UTXOs similar to as it is on Bitcoin where when you have a beer proposal contract out there in the world, you can only use it once. And when you use it, it gets essentially archived and can't be used more than once. So everything stays nice and atomic. And so that means that we can end up in a situation where the giver and the recipient have a race condition where maybe I as the giver and Sam as the recipient are trying to cancel and accept the beer respectively at the same exact time. And we end up in a conflicting state where the dammel's runtime driver is basically guaranteed that this isn't going to happen. And the other nice thing about this is that with the signatories and observers we can create obligations between parties that we haven't explicitly signed off on. So what you might notice here is that in order to actually make this beer IOU template we need a Sam here, for example, in the accept beer to sign off on actually accepting it because I can make an obligation that says IOSAM a beer via this beer IOU on the right hand side without Sam actually agreeing to it. And the way that's enforced there is that basically authority and signatures on these contracts propagate downwards to child contracts. So what happens here is I put my signature on a proposal and then Sam as the recipient can go ahead and accept the proposal and put his signature on it. And then once Sam's signature is on it we can go ahead and actually instantiate the beer IOU contract because now we will have signatures from both the giver and recipient. Sam says, thanks for the beer, what do I owe you? Nothing, the questions themselves were more than worth going to beer. And very funny. And yeah, so that's kind of how this works as the contracts. And then I'm actually going to deploy this application very soon, but we're essentially talking about quite a lot of things here that we get out of this small bit of code for free. So we get our data persistence. We get consensus by connecting it to a ledger. We get a JSON API that we can talk over and it's a common API that's very similar no matter what type of application we're working on. We get separation of concerns and we get all these very, very fun things. And with all that, we're actually powering a UI that looks like every other UI out there. We actually have React libraries to interact with our application with our back-end code. And we have a code gen that generates JavaScript and Java that also interacts with the back-end code such that it basically creates classes and other nice cities that directly from the code we've written here so that we can just import it into our Java code. And actually I show that right now because it's fun. So here's your dot-downal and we have this code here. And what'll happen is, and I'll actually walk through the steps in a moment is we can actually go ahead and import all of our contracts and templates here as JavaScript code. And we can actually go ahead and use it in such a way down here. So this is all, this class basically comes from auto-generated code, which is very nice. It makes it very easy to consume our applications. But I am kind of jumping ahead of myself. So I'm just here. And we're going to hop over to our Ritual Production app. And much the same way that IOSama beer, I'm going to actually show how we can do this now. How we can actually deploy this application where we basically pass around IOS between each other for beers. And so the first thing I would want to do is I would want to start up a little network where I can get these things going. And so I'm going to head over to our demo on fabric repository. This is all open source. I think it's under Apache too. And I'm going to go ahead and download and install demo. I mean, demo on fabric, which is basically the demo driver for talking to our demo ledger. The one thing though I'm going to skip here is I'm going to skip the actual cloning and installing some of the hyper fabric tools because that'll take a few moments. So some of this I have already done. But anyway, our first step is actually going to be to navigate into this directory here. And then as we see here, we're going to run our gen.sh and restart fabric.sh commands. And the first one is just going to generate our fabric config file. Obviously, if you have your own fabric network, you could also set this up to talk over your own network, but this is basically for nice and easy development. And then we're going to go ahead and start up our fabric network. So we're starting up our fabric network here and it's up and running, beautiful. Now, next we need to go ahead and deploy our demo application. So I'm going to head over to the deployment guide. Deployment guide, by the way, here is actually written for another project called create demo app, which is another example we have that's available in our docs. And while it's specifically for that application, it's very generalizable to what we're doing here. So normally we would go ahead and build our application, but I'll build that separately. We've already cloned our demo on fabric and got that up and running. And so now what we're going to do is we're going to start up our demo driver, this case with this command, sbt. And that's just going to take a moment to start up. So while that's starting up, I'm going to go ahead and actually build my application so that we can be ready for that. So I'm going to go ahead over to my repository. I type the zero instead. And right over here, we're going to see building it is fairly easy. We basically need two commands and then we could start our UI after that too. So to build our application, we're going to go ahead and run demo build. And that's going to compile all of our code from demo into an intermediary language called demo.lf, but you don't need to worry about that. But it's actually very similar in respects to Java in that it's compiled all the code and everything that is necessary to run the application is zipped up into this file that's called a .dar and that's very much akin to a jar file in Java, for example, that it's all one self-contained set of code. And then we're going to go ahead and run our demo code gen. And like I talked about before, that's going to go ahead and generate nice little classes that we can use within our JavaScript application to interact with our contracts without having to be so specific about it. And if they update and we change them, then we can just run code gen again and that'll properly reflect the current state of our contracts. And now going to head back and let's see if our demo on Fabric driver is up. And it is, we can see right here, it's talking to a ledger called Fabric-ledger and it's on port 6865. So perfect. Now what we're going to do is take that code we compiled and actually go ahead and deploy it to that port because that's where our demo driver is running. And we'll see right here that all the files are being uploaded and written to our actual ledger. And we can actually see two over here is that the data is being written and recorded in Fabric itself. So that handles all that for us and it's very, very nice. And now that our code is actually running, we can go ahead and expose our JSON API. So again, we haven't written any code for our JSON API. We're just going to go ahead and point it at that same port 6865 and then I'll serve up my JSON API on 7575 where our UI will talk to it. So this will take just a moment and now it's up and running and now I'm going to head over and build the UI. So if I go back to my OPR, the readme says all I have to do really is yarn install. I've done that already just to save us a few moments from having to install all the Node.js requirements and then go ahead and yarn serve. And that's just going to take a moment and it'll spin up our front end. And so now we've started up. I'm going to go ahead and just come here and log in. I'll log in as one of our test users Alice and I'm going to offer a beer to Bob and you can see it's been offered. There's no trickery here. If we go back, we can see right here that we've, I'm missing a header, but it's planning because it's actually receiving data. Then we can see right here a few seconds ago the data was actually written to Fabric and Fabric actually went ahead and recorded it. And so that's great. We're going to have Alice also offer beer to Carol and that's kind of where we're going to see that the separation concerns. So if I go ahead and log in as Bob, now I haven't on the back end written any code that basically make sure that Bob can't see Carol's transactions or that they're separate. And in the front end, I'm also not querying in a way that is going to be very cautious about what proposals I'm getting back. I'm literally just going ahead and querying and saying, I'm Bob, I want all the proposals. And the ledger goes ahead and says, okay, Bob, here's your proposals. And Bob doesn't know anything about Carol's because they haven't been disclosed to him. And so Bob can actually go ahead and accept the offer. And then when, and I'll go ahead and exercise as well writing to both writing through the Jason API, to the demo driver and finally to fabric. And then once, you know, Alice and Bob have agreed that Alice's, once Bob agrees that Alice has given him the beer that she owes him, he can go ahead and mark that as received. And all the while, Carol's is unchanged and private to her actually well between her and Alice. And, you know, Carol can also go ahead and say reject. And what that'll do is it'll exercise the proposal and then by default, every time a choice is exercised on any sort of contract, it archives it. So there's nothing else to do on it. And then it goes away. And so, yeah, that's pretty much demo. Actually what the other fun thing I can do now is I can take the same application and with just a very minor tweak to my UI, I can just deploy it elsewhere. So what I'm gonna go ahead and do is I'm gonna take down all my Docker containers and I'm actually going to make sure I stop all my Docker containers too. Say, oh, I'm really bad at running Docker. What's the demand for that? Oh, there we go. Stopped all my Docker containers. And I'm going to delete them as well. So now what I'm gonna do though is I'm going to head over to my demo on autof. And I'm going to deploy the same exact application there. Obviously I've taken it down from the other place. So there's no need for data persistence there. And yeah, let's go just try this out. All right. So let's head over to, is this, is that sound? Perfect. So now we're gonna head over to demo on sawtooth. And we're gonna follow basically similar steps. So this one runs slightly differently and that when I started, it'll actually go ahead and start up both the sawtooth instance and the demo driver in one go. Oh, I need to actually build something first. Let's build it. Okay. It's this little isolation ID. And then we're gonna just run bin such build a stage. And that'll actually take a moment. So if anybody has any questions now, that would be fine to ask just because this is gonna take a moment to build. I hadn't actually realized that I didn't have it built. But while we're doing that, I can actually go ahead and show you through some of the things you can do with demo. So actually let's head to discuss.com.com slash start. And this is actually the same link as over here, bit.ly slash try demo. So you can go ahead and check that out here. And what you can do basically, obviously you can go ahead and try out and install the demo connect SDK slash toolkit. We also have demo.com slash learn though, which I think is a really great way to kind of just dip your toes into demo because everything here are basically self-guided documents where you can go ahead and try things out yourself. So if we wanted to actually not do it locally, I could actually run through a deploying demo on sawtooth in my browser here and start it up and deploy it over on a server that I don't, that I don't have to worry about. So you can do that all within your browser. You can learn all sorts of concepts as well. So we have a large variety of tutorials that basically go into fundamental demo concepts that I think are very useful and obviously necessary for when you're working with demo. So there's that. There's docs.demo.com over here and getting started or actually under running demo and introduction to demo. This is basically the book on demo that Bernhard, a co-worker of mine has written and it's absolutely great for learning the language in depth to really know every, all the basics you need to know about demo. Really actually it's a bit more in depth of this basics though, have a scope there. Then we have discuss.demo.com. That's of course our forum where if you have any questions, you know, if you spent more than five or 10 minutes trying to figure something out, you can go ahead and post your questions there. Then we have our certification, which as you might see over here, there is a 100% off demo associate exam code as long as you enter in HL Boston and basically for the first 10 people that go ahead and sign up for it, you don't need to take it right away. You can go ahead and register it and take it later, but you can go to demo.com slash certification and click on purchase the exam except you won't have to pay for it, which is beautiful. Everybody likes that for free. And yeah, then lastly, we also on the business side, obviously if you're more on the decision-making side of your organization, we have digitalasset.com slash services and the entire digital asset website where you can learn more about the productized and solution options that we offer as a company in general. I won't talk too much about that right now since we're talking about download self here. So let's go and see, oh, we're still downloading and compiling. So that'll take just another minute. And yeah, that's mostly what demo is, but I just wanted to prove to you that we can write this code once and deploy it anywhere. And actually while doing that, I will update this one little thing where later our application will want to make sure it's talking to the right ledger ID and it'll get upset if we don't narrow out. So let's do that. So Anthony, two quick questions while we're waiting, I guess this is the problem. One, we have PII information a lot of times about me, you know, whatever it is, whatever we're tracking me in a golf tournament and you don't want all my personal information out on the ledger. How does, you can tell us how demo would handle that? Yes, so in vanilla demo, the way you would handle that is making sure that when you're structuring your applications that you have kind of a separation of concerns. And let's see, Bernhard actually wrote something on this forum about attachments and kind of how to do that. So I can actually go ahead and share that link in the chat, but basically there are very good reasons like you mentioned, especially PII, not to store all of that data on ledger. So there are ways to work around that with vanilla demo. And then the other option, of course, is Canton will eventually have pruning. So that would be another option you have such that you can delete data off of the ledger whenever needed. And so those are the two options that you have right now. Obviously, Canton extracts that part away from you a bit and makes it a bit easier to deal with. So it's one approach, but if you're dealing with vanilla demo, you have to give some thought to what data you're storing and where. And I think that's actually a good thing. Obviously, slightly more cumbersome than we will like him, which is why I'm very excited for a Canton approach, but it's very good to actually think about what PII you're storing, where and when and who can see it. And by forcing you to think about it, it may help long-term make people more cautious and better about storing PII. But that's a great question. And yeah. So now demo on Sawtooth is all compiled and should be ready to go. So I'm gonna head up to anything about the directory. Not everyone's at a stage start. And so this is going to start up simultaneously. So slightly different from fabric. Like I mentioned, it'll start up the Sawtooth node itself. And at the same time, it's also starting up the demo driver that we'll talk to it. So you'll see that in a moment, it'll say RPC is what they were calling it internally. And that'll get started up in just a moment. And then really, once we have that up though, we're basically going to work through the same exact type of deployment. You'll actually see together the deployment. Now we know. It's going to basically be the same exact deployment steps after we get the demo driver up. And so RPC is up, except this time we're running on port 9,000. Our ledger ID is called test. This is a test network. So we're gonna go ahead and run demo build again. Actually, we don't need to run demo build again. We don't need to run demo code gen. Again, we can just actually go ahead and demo deploy. So I'm gonna skip those two steps and run my same demo deploy command, except this time I'm just gonna deploy to port 9,000, which our saw two things since it's running on. Gonna go ahead. I led your port here as 9,000 and serve the JSON API. Again, none of the code has really changed. Oh, demo deploy actually does recompile, but that binary should basically be identical to the previous one. So there was no special things we had to do there. And then go ahead and yarn serve. And that'll start up our UI again. We can go ahead and connect to it again. And we'll go ahead and log in as Alice. Alice can go ahead and offer Bob a beer again. The first time it does this, it actually takes a moment and that's just because it has kind of a just some time compiling compilation going on. And then it speeds up after that. And as you can see, we've received some data through our JSON API and it's gone through both the demo driver, demo RPC over here, and then getting stored in blocks itself on saw two. And yeah, that's basically demo and how it works. And so we have a few minutes left. So if anybody else has any questions, feel free to ask. But otherwise, yeah, this has been a great presentation. Thank you, Sam, for the very, and Jim for the very great questions. They were awesome. Yeah, if you wanna ask a question, please just unmute yourself. All right, so I'll take the gap that I have on nobody asking questions. I'm unmuted, you're now on deck. One of the challenges we talked about, you've got multiple platforms here that you're writing to. And the one thing in fabric, I'll give you an example of a feature that I don't know how you map to it, is in a fabric network, if it's, I'll say suppliers and customers kind of a thing, vendor relationships across a network. You have 10 companies and summer vendors to others that are in a sense purchasing from these vendors. In that world, in fabric, we can say, okay, vendor A is gonna sell to company B and they're gonna have a contract. Well, the contract does go out in the network in fabric, but we would want the terms of the contract to be quote private between them. So the rate that they're selling and all that would be private, it wouldn't be shared, even though the contract itself winds up getting distributed across the network. The terms of that contract are private between A and B. How does DEML support a feature like that? Yeah, the way DEML does that, and obviously some ledgers are more gossipy than others, but the way DEML does that is it only discloses the information that needs to be disclosed to the nodes that need to know that information. So for example, if Bob is running a node and Carol is running a node and Bob and Alice have a contract, Alice's node is only going to send the data about what they're doing to Bob. And simultaneously Alice's node is only going to send the data about what they're doing to Carol for the contracts involving Carol. So that's kind of how it deals with that is it doesn't share data where it doesn't need to, it only shares data on a need-to-know basis. Excellent, okay, thanks. Okay, anyone else have other questions? Once again, it was a great presentation on my end. I think it's interesting because it does have potentially a lot of applicability. It sounds like you got the resources on the site if we go there to easily start learning this with the guides, the support community channel there. I think that's your questions. That's a good set of resources. And then this thing where if anybody's interested to get a free certification is unusual. Folks, are you able to hear me? Yes. Yeah, my name is Mayapan. I joined very late but I got the gist of a great presentation. I have one question. This just because the lack of knowledge is bad with me. Is there a way from sort to integrate any cryptocurrency into sort to the ledger or hyper ledger? Any cryptocurrency can that be integrated into the transactions? Obviously, you can store any type of data or state you want on a sawtooth or fabric ledger or any ledger. It really depends on what you mean by that. I think in general, when we think of things like sawtooth and fabric, we think of private distributed ledgers that are only concerned with certain parties and have some sort of ultimately permission type of architecture, even if part of that is anybody gets the read permission. But when you think of cryptocurrencies in general, like for example, Bitcoin, you think of those as much more public types of blockchains where really something like really public blockchains would be better suited to those things. I would think in my opinion. Yeah, so let's say I'm making a purchase of a pound of cotton yarn from a supplier, right? So I'm willing to, it's a hypothetical thing that I'm really trying to do. I'm calling this product textiles. So we are trying to ponder on that. So when I make the purchase, instead of making a payment using dollars, can I, and I can capture all the letter of credit and all the documentation associated with it in sawtooth, but make my payment through the exchanges and can I reflect that just that amount into sawtooth where my contracts are? Can we make a bridge between the two, by getting the data from the exchange from my wallet? Yes, and so now, yeah, I understand your question a bit more. So yes, we actually even have an example on that for crypto inventory management. And basically this here simulates a dealing desk for selling cryptocurrencies. This one, for example, on Bitcoin. But yes, Damo can basically talk to any sort of other network that is out there and you can use data from Damo in order to communicate to those and kind of get data off of it, pull data from the blockchain to see what it is and then perform actions based on that as well. So yes, to answer your question very briefly, yes, Damo, can you interoperate with any system out there? Excellent, thank you very much. And can we apply also like somebody raised a question on the PI, right? PI data or even blocking the contract information beyond two parties. Can we encrypt that data and put the encrypted contract into the ledger so that when only those two or maybe those three or maybe associated parties for that transaction can see it. Can we do that? All right, yeah, you can obviously encrypt data before committing it to the chain and do it that way. You could store hashes, which is another option for that type of data privacy. Yeah, there's several ways to basically protect data beyond just having permissions sharing of it. And some of that I think we talk about on the forum as well. Thank you very much. That was a great question who raised that. Because the data is so public now. Yeah, it is. You're very welcome. Hi. Any other questions? Any others? Yeah, sorry, Jim. Yes, and Anthony, thanks very much for the presentation. I'm not a software developer or a product owner, but I'm just doing a master's in blockchain at the moment in the aviation industry. And I'm looking at Hyperledger for a particular use case that I'm looking at. But just on the Hyperledger uses private data collections as well to safeguard some privacy between, if there's information on a particular channel on the ledger, then you can use a private data collection between two of the nodes then to share data. Does Dabbel leverage that capability? Dabbel, I don't believe leverages private data collections just yet, but I know we've been talking a bit about those functionalities. And the other thing, I would go back to what you said earlier Anthony. The point is there's multiple ways to in a sense ensure private data. So I don't have to implement a private data collection, the implicit private data collections they have in Fabric. There are other options for that for sure. Yeah, absolutely. There are not Fabric specific, let's put it that way. Okay, okay, thank you. And back to the other point on tokens. Like Fabric doesn't have a native token. There was a movement to try to create one. As far as crypto and all that, the reality is there's an application we have that the team I work on wrote that actually uses the Stellar network and creates custom tokens out there. So some of these altcoin networks like Stellar's one, there's a few others that actually let you in effect say, hey, I wanna in a sense contract with you to create my own, either crypto or my own token, you can do either one on these external networks and trade there, but those transactions can get captured in Fabric as well. So anyway, anything else we've got to wrap up at one but if there's one or more two questions, I'd like to take them. I've got a question, no one else has. So in terms of keeping data linked, but also private and obscured, can you integrate zero knowledge proof data from other systems, either using canton or otherwise? Or can you also use just hashed values of things that can be verified within demo for other chains? On the zero knowledge proof side, I'm not 100% sure on that. So I wouldn't wanna misrepresent. I know that there's been discussions on the canton side of various methods to make data private, but to answer the other part of your question, yes, you can definitely use hash data in order to have some privacy that way as well. Yeah. One other thing, so Anthony, I will be able to get a PDF version of your slide deck. Yeah, I can definitely send that out. All right, great. And I'll take the meeting recording here from Zoom and the slide deck will post it up in the meetup. And then the last thing I'll say is you did point, in fact, maybe you can show it on screen again, is the URL to ask questions in your community channel. Because there are a lot of questions people have wherever that is. Of course. So what you can do is the shortest link to type would be bit.ly slash tryDaml. So I'll leave that up for a second, just so everybody can see it. And then the other sort of screenshot noise. The other thing is to go directly, it's discuss.daml.com is our forum where you can go ahead and ask questions with a very active questions category. So with that, I wanna thank you. This has been an awesome session. Certainly people are very interested in it. And it really does look like something that a fair amount of thought has gone into to try to simplify managing contracts across multiple platforms. So it does look promising. The fact that it's, quote, an open source initiative is a big thing as well. So it looks very, very promising. It's worth investigating, I think. And with that, thank you very much. And look forward to getting your slide deck and continuing to follow Daml. Thank you. Yeah, absolutely. Thanks very much, Jim. That was a great little wrap up. And yeah, thank everybody for the questions. Sam, Mayor Pahn, Mary, you all asked great questions. And if anybody has any others, like Jim said, you can go to discuss.daml.com and yeah, check it out. Thank you. Great, thanks very much. Thanks everybody. Thanks, actually. Thanks. Thank you.