Agoric Tutorials, 14 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How To Mint and Sell your NFTs

Description

Kate Sills, Software Engineer at Agoric, shows two simple dapps that we have as examples:
Fungible Faucet Dapp: Learn how to mint fungible tokens and give them out.

Card Store dapp: Mint non-fungible baseball cards and sell them.
Build your dapp using these examples for fungible tokens or non-fungible assets.

Resources:
https://agoric.com/documentation/getting-started/
https://github.com/Agoric/dapp-fungible-faucet
https://github.com/Agoric/dapp-card-store

ABOUT
Build Fast, Earn Fast - Agoric enables developers to rapidly deploy dapps and DeFi markets on-chain using composable JavaScript smart contracts. Safely get your project from vision to global market.

LINKS
https://agoric.com
https://agoric.com/twitter
https://agoric.com/discord
https://agoric.com/telegram
https://agoric.com/newsletter

Click the 'SUBSCRIBE' button to follow our Youtube channel!

A

B

All right, so, let's get started um so today we're going to be talking about two different dapps that we have. These are our two basic example depths and one of them is uh minting fungible tokens and giving them out freely through a faucet and the other is minting nfts and selling them in a store. So they're going to be baseball cards, we're going to sell them in a baseball card store, and I do have a cat. So you may actually witness a special guest star, um but hopefully not, but let's go ahead and get started.

B

All right and um currently feel free to ask your questions at any time um in the youtube chat or on discord. um uh Roland will be breaking in with questions um if you guys have them so feel free to ask them.

B

As the talk is going on like I said, we're going to be going through our simplest steps, so the fungible faucet dap is actually the default that you get uh when you do agorika knit, so you may have seen that already and that just meant fungible tokens and gives them out and then there's the card store dat which, as I mentioned, uh immense non-punchable baseball cards and sells them.

B

So this is what fungible, faucet uh dap looks like um basically, the only functionality, oh whoops, let's actually go to the real thing here.

B

um Basically, the only functionality is that there's this little button that allows users to meet fundamental tokens and, as you can see um it's connected to the wallet and currently, let's see oops, it is disconnected from the api server. Let's see if we can fix that.

B

Okay, there we go it's connected and uh let's see if this actually works for us, so we say meant fungible tokens. uh It says approve the offer in your wallets, so we have this offer here. We accept it and we have more fungible tokens than where we started than when we started so and back in the depth. It says that uh we've received a thousand more tokens, so that's the fungible faucet that uh let's go to the card store, so that is also disconnected.

B

So, let's try that all right, so the only functionality here pretty much is that we can click on a card. So let's buy a raw uh chamber chamber bling all right, uh we'll we'll be going into how uh what the origin of all these names were. um It's a pretty fun story so stick around, um but we can click on the card and that will send an offer to our wallet which we can approve, and you can see that we have. uh We have the raul uh chamberlain uh card now in our wallet.

B

Okay, so that's the basic functionality that we're going to be going through, but there's a lot of little pieces that um have been put into the dapps that make this actually work all right.

B

B

So if you're, following along we're, going to be starting with the fungible faucet app, so you can either look at the get github repository or locally. If you do a gorka knit with any kind of the my fun full faucet is just a dap name that you can change. um If you do that, the default depth will be the fungible faucet depth, so um I'm gonna go. I'm gonna do a brief overview of how all of this is connected.

B

This is kind of at a high level we'll be going into the actual code that implements this, but, as you saw um when I minted that fungible token, so I just I just clicked um on the um the fungible uh mint fungible token button that actually made a call to the back end to the api server and uh that calls creator facet make invitation which makes a call to the contract which actually makes an invitation with zoe.

B

So invitations are actually digital assets in and of themselves, but this is how uh you're able to invite other people to join your contract so as opposed to ethereum, where you have um you have contract addresses and you have the addresses of um of the senders of transactions on agoric. Everything is in object capabilities, so that means to be able to access something. You have to have a particular object that has particular methods on it um or, and you have to be able to present that object.

B

So the invitation object here is actually acting as that uh object capability. So we'll go into more of that later, but we make the invitation with zoe. It gets sent back to the app server. The app server sends the invitation and the proposed offer to the user's wallet. So that's what showed up uh in the wallet and where I accepted it.

B

So what this is really cool because it means that the app server uh it's it's setting everything up for us, but it's still allowing the user to make the decision in their wallet and it's making a decision in terms of offer safety. So we'll go into that more later. As well, but once the user accepts the proposed offer, then the wallet actually makes the offer to zoe on the user's behalf um and the contract, realizes that this offer has been made.

B

It allocates a thousand tokens to the user and then zoe then pays it out to the user's wallet. So then we saw the tokens in our wallet and uh if we were to go back to the dap, we would see that we received a little notification that you've received a thousand tokens and um you can use these kinds of notifications for various things.

B

um I'll show you how all of that is hooked up all right, so uh the format of adapt, so by default, we've set things up so that there's three main folders in your adapt that you're going to need to change. There's the contract folder, and this contains your contracts that you deploy to the simulated chain in testnet.

B

That's a probably a good important thing to note is that when you're building you're building against a simulated uh blockchain, not the actual test set, um there are instructions for deploying to the test net and we can also help walk you through that. But it's uh it's good to get everything sorted out locally before you try to do that all right. The second folder is the api folder. um This is the code for the back-end server, so it's split into on-chain and off-chain code and we'll go into that later.

B

There's also the ui. This is the front end of your dap, of course, and uh special guests appeared um sorry about that. uh So the front end um really could be any kind of javascript framework. um So in the two example dapps that I'm gonna be showing today uh it's just raw javascript with um google's material uh ui.

B

So but uh we also have dapps that use react that I think someone has built something with view. um So there's a variety of different ways that you can actually choose to build your front end, and so you should build with whatever you feel most comfortable with all right.

B

Let's see, okay, so let's actually dig into the fungible faucet code.

B

So um this is the uh the fungible faucet uh application as you, um if you do a uh agora knit and you actually look at the folder, this is what you'll be seeing um so like. I said uh this is probably very small on your screen. So I'm sorry for that um increasing the font doesn't seem to actually increase this part of things, but there is a contract folder, that's what we're going to be diving into first, so let's go to contract source and then contract and let's just start going through this contract.

B

So first um you'll notice that there's this ts check. um That's just setting up the typescript checking that we have so we do not use typescript, but we do use a js stock that is compatible with typescript and so we're able to have typescript checking.

B

Of the types that we define without it actually being typescript, so we import all of the zoe types as well and probably the best way to get started with analyzing. A contract is going all the way down to the bottom and looking at what gets returned. So there are three things that can be returned in any contract: there's the creator, facet, the public facet and then a creator invitation and all of those are optional.

B

So this particular contract returns a creator facet and a public facet, and what facet means is that it's an object that represents some smaller part of the greater whole. So uh you can think of this like, uh let's see if, if you have, um if you have keys to an apartment, building or something like that, there's the master keys and then there's the key for just a particular apartment.

B

You don't want the person who just wants access to a particular apartment to have access to the whole apartment, building right, um so there's kind of like manager, keys and uh more attenuated keys and so object capabilities kind of work the same way except we call those those smaller authorities facets.

B

um So this creator facet uh so we've set it up so that the creator can make an invitation and they can also get the issuer of the token that we are going to be creating and uh the public facet is also able to get that issuer.

B

So, let's take a look into um uh how this invitation is actually being created. So a zcf is a um is what the contract every contract is given. So every contract has this format where it needs to have a start function, and then it will be passed dcf, which is the zoe contract facet.

B

So zcf has a method called make invitation and that takes in a function which will act as what we call the offer handler. So when someone makes an offer using this invitation, this code will run, and uh it also takes a description.

B

So um so this function is really quite simple. All it's doing is it is making an amount. An amount is just a description. It's not actually the minting itself, but then in the next step it mints that particular amount and allocates it to this particular seat.

B

Then it exits the seat so that the user gets their payout and uh we just return the string, so the this will be sent through to the offer result for this particular offer. um So you might have noticed that there was this zcf mint which, if you've looked through our ertp guide, will be unfamiliar.

B

So um if we were minting with a regular ertp mint that was remote, we would have to do an await on minting, because any kind of remote call creates a promise that we would have to await.

B

um So what we've done is in zoe, because we want most things that the contract interacts with with zoe for to be synchronous. We we made this dcf mint. That has a special interface, so it mints these tokens and then it directly allocates them to the seed. So we have documentation on this feel free to ask questions about it, but uh just so you know this is a slight difference than the uh the er ertp mint, but all of the digital assets are uh created exactly the same. The issuers act exactly the same.

B

Everything else is exactly the same. It's just uh there's a special interface kind of a wrapper all right, so I think we've gone through that. So the next thing is uh the deploy script.

B

So, um let's see so most of these deploy scripts are exactly the same. uh It's doing something very simple: all it is doing is it's taking the the code that we just saw the contract code, it's bundling it! It's installing it on zoe to create an installation, and then it's making an instance from that.

B

So let me let me explain a little bit about uh instances and installations so rather than like on ethereum having uh each contract that is running have its own address and then, if you want to verify the code, then you have to, like you know, hash the code and then see if it matches see if the hash matches right. um What we've done is that you can actually install the code on zoe, and then uh that gives you an installation object and that object you can use. So like.

B

Let's say you audit the code, um you see that it's associated with this installation object and then you can just save that in your wallet and then whenever it comes up again, let's say someone creates a new instantiation of this particular code. You can just check the installation and see if it's the same with object, identity so just triple equals, and this makes it really really simple to reuse code and then also to um be able to check that the code that you've already audited um is being used and not some other code, all right.

B

So we make that installation we and in this in this case the deploy code ends with putting all of this information in some in some configuration files that will be picked up by another deploy script. So let me explain a little bit about the board, um so the board is a shared on-chain object, that maps uh objects to strings and strings to objects, and these are just random numbers.

B

um So basically, what this is doing is allowing you to share things with other with other entities on the test net or your simulated chain.

A

And the reason.

B

For this is because, um in an object capability world everything is private by default. So, unlike on ethereum, where, um if you have a contract, anyone can hit your contract and you know you have to protect yourself from it. You have to check message, dot sender. You have to um set it up so that even if people are hitting all these different endpoints they're not allowed to get in on the um on the igori platform, everything is private by default.

B

So no one even knows where your contract is to actually hit it unless you give them some kind of access. So what this is doing is making the code for this contract available on the board. So someone else and including us in a later step will be able to use it to to actually make a contract instance.

B

So, let's, uh let's go directly. Oh, let's first actually look at some tests, so uh when you're developing your dab, um probably the best thing to do. I know you know, time is scarce in the hackathon, but if you don't want to set yourself up for pain later, probably the best thing to do is to test your contract, and so we've provided you with uh with ava uh ava.

B

Is our uh the testing framework framework that we're using um and we provided you with uh with tests of the contract, and so basically you can see what this is doing. It's installing the contract, it is getting. The creator facet that we saw uh alex is making an invitation for bob bob makes an offer using that invitation. He gets a seat. A seat is uh essentially the position in a contract, once you've made an offer, and we saw a c earlier on the contract side, but this is on the user side.

B

um It's essentially the same concept, just with some different uh different methods. Depending on what side you are.

A

B

um So bob is able to use the seat to actually get a payout and uh we get the issuer from the contract to be able to check uh in this test that the payout that bob gets is a thousand tokens okay.

B

So uh let's move on to actually deploying this so we're gonna move into the uh so we've deployed the the code, but now we actually need to create an instance unchained. So let's move to the api folder uh we're going to be moving to the deploy scripts. There.

B

And um so every deploy script is given this. This promise for home home is uh what you might have seen in michael's talk that just happened previously, it's what uh every user is given and it has a number of different, um a number of different on-chain things that you can use, so it has zoe.

B

For instance, um it has the board which we just talked about, um and what we're going to be doing is we're going to be getting that installation that we put on the board and we're going to be using it to actually make an instance, and so here we get the creator facet and the public facet.

B

We get the token issuer of the token that we've just created- and we put all of these things on the board such such- that other people would be able to use them. This is how we make things public, and uh I think one thing that is important to mention is all of these. Deploy scripts are ephemeral, so they run in node.js, but they're not running consistently and they're not running on chain, so to actually have something that is running uh consistently.

B

We need to uh be. We need to set up a handler, and uh let's see where is that here we.

A

B

So we need to to set up a handler and uh we're going to be passing in the creator. Facet, the board, http and invitation issuer from zoe we're gonna save some more things to our uh config files, but let's actually go into the handler and see that so this is a little bit complex, we're working on making it easier. um But you can see the things that I just said: you're passing in those are given here and uh this handler responds to a few messages.

B

So um it responds to the message: fungible faucet send invitation so I'll show how this is actually called in the ui, but effectively. What this is doing is using the creator facet that we saw in the contract code to make an invitation and then send it to a user's wallet.

B

So this depositfacet.receive, the user, has put up their uh has, has made public um their uh their purse in a way that is a deposit only facet. So no one can look at the balance and no one can withdraw anything, but you can deposit things, um and so this is actually sending the invitation straight to the user so that they can have the invitation in their wallet, and it is also sending the data about the offer to the user's wallet so we'll we'll see how that is handled in the front end. So let's go.

B

uh Let's go back to the front end um so under public under uh source and then main that's where all the magic happens. um So again, this is a little bit complex, we're going to be working on making it simpler, but you can see the config files that we saved we're taking all of that stuff out of here and using it in the front end. um Let's actually start with uh with the calls that are made.

B

So once things are connected, uh what the main thing that we do is that we set it up so that the uh the mint fungible tokens button on click it'll it'll actually create an offer. That says that uh that the user will want a thousand fungible tokens into their token purse, and it will send that message to the handler that we just saw.

B

So, let's go back to the handler, um so you can see that this case matches what we just saw here and it will um tell the handler about the user's deposit facet for zoe invitations.

B

Okay, so um so there are two two pathways that are set up here: one is um the wallet, so the the dac ui going to the wallet and the other is the uh the dap ui uh going to the uh the back end. What we just saw so when we do that we get a response and that is handled in this api uh received.

B

So that response is send invitation response. um We get the offer that is sent back there, and then we do a send to the wallet. So we tell the wallet to add this offer to the list of things that need to be approved by the user.

B

All right, um you can see that uh there's a similar thing for the wallet. So when the wallet sends the ui messages we handle that here, so the wallet will, for instance, tell us about that deposit facet id we save it.

B

The wallet will tell us that our dap needs approval. uh So what we do is that there's a uh a dialog that opens- and so we open that here it will uh tell us about the purses and their current balances. We don't actually use that much in this step, um but if we did, we would be able to get it and display it from here.

B

um It tells us when an offer has been added, so this instructs the user to go. This gives like a little in material ui. They call it a snack bar the little notifications at the bottom of the screen. It tells you to go to the wallet to approve your offer and you can see once the offer is handled. We close that and once we get the offer results. So that means once the uh the tokens have been minted and deposited in the user's wallet, then we can give um a little snack bar notification for that.

B

Okay. So, um let's see- and these are just the definitions of the uh the little snack bars if you were- and again this is meant to be simple. So if you're dealing with react or something like that, um you'll have kind of a much more rigorous way of dealing with state. At this point we just um we just define these and we trigger them as appropriate.

B

Okay, so let's go back um so that's kind of the explanation or exploration of the fungible faucet code. uh Let's actually go into the card store code. So uh again you can look at the github uh repo. For this or locally you can do a gorgonit. The only thing is to use anything other than the the default stat template you're going to need to use this uh configuration dap template with the name of the repo okay, so uh the card store.

B

So this is a little bit more complex, um but again, let's start with the the contract code. So what this contract is doing is it's minting? Non-Fungible tokens, uh we're gonna, uh do this in the form of baseball cards and it's creating a contract instance to sell the cards in exchange for some sort of money.

B

So we'll see a little bit of the composability here um so, unlike the fungible faucet, we're not just mentioning these things, we're also going to put them into a separate contract entirely to be able to sell them securely, so um we're going to be selling them for money, not giving them out okay.

B

So um uh here we are actually going to be using the default uh ertp language for this, so we're not going to be using the zcf mint that we saw before so um we're calling make we're uh importing make issuer kit from ertp and also math kind, which will this is how you define whether something is a fungible, token or non-fungible token, and how it should be described.

B

um So in this case, we're using math kind string set, which tells you that it's a a non-functional token and that the descriptions or how each um how the the value of the digital assets is described, uh will be strings.

B

So the the set version of this allows you to have object records, um so you might have like, for instance, if you're selling like event tickets, you might have an object record with properties like event, time event date, uh who it is, what the seat is that sort of thing, but for our baseball cards, we're just we're. Just gonna have the names of the players. Okay, so we get, uh we get an issuer, we get a mint, we get the amount math um amount.

B

Math allows us to add and subtract uh and see whether certain assets are uh greater than or equal to um without having to care, whether the token or the digital assets are fundable or non-fungible or whatever they are. um This amount math works uh over all of those cases, so that's great because that means, if you're building something like zoe or if you're, building a contract that could buy and sell different things. You just use the amount math and you don't have to handle any of the special cases.

B

uh It's all predefined, for you all right. So again, probably the best way to start analyzing a contract is to go down to the bottom. uh We are returning a creator facet here and no public facet and the creator facet.

B

This particular view gives us two methods: a sell cards method and a get issuer method. So let's actually look at the sell cards method, so it takes in uh new card names, which is an array it takes in a money issuer. So this is our way of specifying what kind of money you want to sell your cards for. So what are you going to get back out of these transactions and it takes a sell items, installation so I'll get back to that in a second and then it, but it also takes a price per card.

B

So this is an amount in the same brand as the the money issuer. That is the price that we will be selling the cards for okay. So this sell items installation, um like I said earlier, the way that uh we're able to share and reuse code on the igori platform in terms of in terms of smart contracts is creating installations and then sharing those. So let's actually take a look at what this sell items contract looks like and so we're going to be.

B

Using this installation to make it a fresh instance, but we're not going to be writing the code ourselves. This is actually coming from agorik sdk.

B

So, let's see if we can find that all right, um okay, so sell items um allows you um to sell any kind of items uh for for money, and so this is not uh specific to the baseball cards that we saw earlier. You could sell event tickets. You could sell whatever through the same contract. So this is a reusable component in our system, where you don't have to write the code yourself, you don't have to install the code. All you have to do is use the installation that already exists and create an instance from it.

B

In that instance, uh you will have soul control over all right. So um in this contract you specify the uh the money and the items brands, and then you save those issuers to zoe and you are able to um to get the amount map for both of those um you're. Also, uh in the terms, you should also pass the price per item so we'll see that in our card store contract in a few minutes, um let's see uh let's go down to the bottom okay.

B

So um when this contract is instantiated, when we create a new instance from it, we'll be given a creator facet, a creator invitation and a public facet, so all of the optional things will be will be present. Okay, so the creator facet, uh it allows us to sell, uh sell the items. So we have this offer handler called cell. So let's go up to that.

B

Okay, um so sell um saves the seller seat, uh and that is the only thing that it does.

B

um So, let's take a look at the creator facet, so the creator facet allows us to make invitations for buyers, so we can invite other people to buy our our non-fungible tokens or whatever it is that we put up under the items keyword.

B

It allows the creator to see the available items that are still left and sorry more guest stars. um It allows uh the creator to see um or to get the items issuer, okay and then the public facet.

B

The public facet is very similar. We can see the available items, we can get the items issuer okay, so the most important thing here is the buyer's seat. So let's go into that.

B

So when we make the buyer invitation first, we check that uh there is, has been a seller seat, so the sellers see the seller has actually put up their items for sale. um We check that the items for sale are not empty and then uh we make an invitation for the buyer and that invitation has this offer handler called buy okay. So we we check that the buyer's proposal has a certain shape. We check that they want the items and they're giving us money.

B

We get the items for sale and we provide money or the sorry. The buyer receipt provides money.

B

Then we check and see if the wanted items are still for sale. So, like I said, um what's really special about ertp as a library is that it doesn't matter whether it's fundable or non-fungible or whatever it is. We can still use the same methods so here we're asking whether the current items for sale are greater than or equal than or equal to the wanted items, and so this works no matter what the kind of items are uh greater than or equal to has been previously previously defined in the amount math code, all right.

B

So um if, if those items are not for sale, then we fail um and what this does is. Basically it gives the buyer their their money back as a refund and and uh and that's it and then, um if we do have the items, then we make sure that the buyer has actually given us enough money to um to buy the items. So we get the total cost of all the items that they want.

B

We check that the money is greater than the total cost and then, after doing all of those checks, then we reallocate so we're using this helper called trade that allows us to specify the gains and losses so in a very declarative manner. It specifies the gains and losses of the different seats, so we can see that the seller seat is gaining the money and the buyer's seat is gaining the items. So once that's once yeah roland.

A

Hi, kate, sorry! So we we had a question come in and chat and uh it was a few minutes ago, but I figured I'd surface it. uh So the question was from matt durkin uh our wallet still associated with a uuid flash address.

B

um Let's see so, uh I think I need some more information so uh like a uh an address in terms of like uh um like as if they were a uh an actor on ethereum or do we know anything more about that.

A

That's how I take the question, uh but matt feel free to add more. If you want.

B

Okay, uh no so um michael figg is actually probably a good person to ask about the the internals of the wallet, but um the wallet is essentially a uh it's an object that uh every user is given on their particular machine.

B

So when they, when they so a, we have our simulated chain and we have our test net and then basically the client machine that people get. We call an ag solo and a wallet is one of the one of the objects that is available there. It doesn't have any kind of identity that the chain knows about all it's doing is holding all of these objects that have meaning on the chain for you.

B

So I don't. I hope that answers your question.

A

B

Thank you feel free to feel free to ask more.

A

Yeah I'll pop back in if there are more uh sorry to derail you here.

B

No, no, that was perfect, um yeah feel free to ask questions as we go along. I'm sure a lot of this uh will um probably not make sense until we've gone over it. A couple of times so feel free to to you know, ask more questions as as we're going all right. So um so we trade so that the seller gets the money and the buyer gets the items uh we exit the buyer's seat.

B

So that means that they actually um they get their payout from zoe um and then we check and see if all the items have been sold. If so, we shut down the contract and uh we will return to the uh the buyer's offer result. Just the default acceptance message, which is uh the offer, has been accepted in which the once the contract has been completed. Please check your payout all right, so um so that is the cell items, contract, um which is in agorak sdk currently- and we are using this as a reusable component.

B

So um let's let's go back to to our uh contract in the dapp store. So um we have the sell items, installation which is the contract that we just saw that is installed on zoe. um We take the new card names, we create an amount. We actually meant those those cards so now we have then, all of the non-fungible tokens that we wanted to create in this. In this call in this payment, then we uh we make an offer proposal to the sell items contract, um but first we we actually start the instance here.

B

So we take that installation. uh We take an issuer keyword, so we are setting up the items to be the uh the non-functional tokens that we just created in this contract. We're setting up the money to be the money issuer that we specified in the terms and then um and we we also set uh the term price per item, which is the price per card that we passed in in the terms here. So we start this instance of the sell items contract. We get uh these things that we just saw.

B

The creator invitation the creator facet, the instance in the public facet and now we're going to use those we're going to use the creator invitation here to make an offer to zoe to that sell items contract with the things that we want to sell and we will get back a sell items creator seat. So we will return all of these things to the user.

B

This part is a little complex, but we, we basically are going to make all of the things that were available in the sell items contract available to whoever calls the sell cards method. Okay, so that was a little uh complex. Let's actually go into the tests for this. I think this will make things a little bit clearer.

B

So, um let's see so, we are going to be um using an imagine. Imaginary currency called moola as the money that we want people to give us in order to buy the baseball cards, um and we are also going to install the sell items contract from the gorg sdk.

B

This will already be installed for you to use, um but here's the installation that I talked about earlier all right and we are going to um create an instance of our the contract that we just saw over here and we're going to call that um we're going to call the creator facet that we get from that the baseball card seller facet all right, so the baseball card seller facet has a cell items method, which we just saw. That was uh see that was this, and uh so we're gonna pass in our uh our arguments.

B

So all of our card names um for this test, our baseball card players are just gonna, our baseball players are just gonna, be alice and bob uh we define the money issue or to be moolah. The price per card is going to be ten moolah and we are using the cell items installation that we just installed. So we get all these things back all the things that we just saw.

B

All the things that we just saw over here, all right so alice, is going to make an invitation for bob, so she makes a buyer invitation uh she gives it to. Bob bob is going to buy his own baseball card, so um he gets the card issuer. He gets the card math. um He looks at the cards for sale and we check that the cards for sale have the names alice and bob.

B

um He gets the terms he makes uh the amount, so he he um he makes a description of the cars that he wants of the cars that he wants um using uh his own name to identify the card that he wants, because the the cards are alice and bob he's buying his own card.

B

He makes proposal so he gives tinmula in exchange for the card that has his own name and uh he specifies that uh or he uh he specifies that the payment that he's going to give is under the money keyword he minced that payment here and ordinarily users are not able to mint their own payments, but this is a test. So we can do this here. Bob would have this in his wallet.

B

um He makes that offer he gets a seat. uh His payout is going to be his card payout and uh bob obtained is the description of his payment here. So um we can see that bob bought his own baseball cards and that's enough selling for now. So what we're going to do is that the seller, in this case alice, is going to exit she's going to get all of her money and she's going to get any remaining cards and the only remaining part is alice all right.

B

So so that was a lot we just went through a lot, um but going back to this contract um you can see. The really cool thing here is that, within a uh within a zoe contract, we are able to instantiate other contracts, we're able to make offers, as if we were a user and um and all of those things were able to do because of the composability- that the work platform has all right.

B

So, let's go and let's see we have 20 minutes left, let's go to uh the back end for this or actually, let's go. Let's first go to the installation, so um this deploy script is going to install the sell items contract. um It is also going to install the um our particular contract.

B

So, let's see where that is then: okay, so the contract. That's in contract.js we install um the sell items contract from a gorg sdk. We install here and you can see how you can. um This is how you would install something that is just uh local, something that you install from npm. You can use require.resolve in this way, so all of our contracts that we have pre-built for you are under uh zoe source contracts, and so you can take a look on our github repo under aguerk sdk see the contracts that we have there.

B

We also have documentation on our website um and you can reuse the contracts like this to actually install them alright. So we uh we put the we make those things available on the board. We put it in our configuration files, as we saw in the uh the first app and now, let's move on to the uh the backend server.

B

So um let's see so in this case, uh these two daps are actually uh connected. So the money issuer that we are going to require to sell our baseball cards is the fungible faucet uh token brands that we saw earlier so this is this is the logic of uh of getting that, um let's see and more logic of getting that, um so we actually call sell cards with all of these card names and these card names come from uh this file.

B

So um so this is kind of a fun easter egg. So um I think in the 80s- or at least the story goes, you guys can check out the suite for more information.

B

um There was a a japanese software engineer who was making a baseball game and uh he was required as for his job, to come up with these names of fake baseball players. um So we just we. We took those names um and there is uh there's another easter egg that I'll go into later, um but uh yeah take a look, take a look at uh at this tweet um and uh take a look at the baseball cards.

B

So let's go back to the deploy script, so we have all of those card names. We have our money issuer, we have the sell items installation and we have the price per card. Let's, let's take a look okay, so our price per card is 10, 10 tokens all right. We make those available on the board. As we said earlier, we launch our uh our handler and so let's go into that.

B

um Our handler is basically the same thing that we've seen before, there's a send in the invitation uh case that we handle- and uh in that case we make a buyer invitation, we send it to the user's wallet. There is also a get available items call. So the front end is going to use this in order to find out what it needs to display.

B

um So, let's go back to that deploy script, so that's the handler that we just saw, and uh then we saved these these board ids to our configuration file. Okay. So let's, uh let's look at the front end for this, so uh in maine uh it's a lot of the things that we've seen before we have. um We have the deposit facet for the user's wallet uh in here. um We have, uh let's see we have. We have code for just handling, um uh just creating the uh the baseball cards um so right now.

B

So if you want to put assets in your in your front end, the way that we have it right now is that there's just a file called assets and all of these things get pulled in.

B

You can see that we handle the messages that the wallet receives in the same way.

B

um If needed to, we update the card so, for instance, if someone buys a card well, it's no longer available on our store. So we need to get the the cards available from uh the backend server the handler, and then we need to use that to sort through what we actually are going to display, and all of this is meant to be very simple. So if you're using something like react, this will be uh less ad hoc and more organized.

B

um So, let's see so. The send invitation response is the same as the fungible faucet. So we uh we send a message to the wallet to add the offer and the user will be able to approve that the get items response um calls. uh What's uh what we're just going through the update the cards once it gets the items that are still available and- um and that is that is basically it.

B

So one thing that I didn't mention earlier is that every dapp has the ability, once it's approved, to suggest uh names for the things that it has. It is involved in so, for instance, um the installation that we saw earlier uh for this uh for this card store. The wallet can suggest uh that to the dap as a pet name. uh Pet names are basically like uh in your in your um in your phone book for your phone.

B

um You might have people under mom, you might have uh someone under you know bob uh those aren't their real legal names. Those are your pet names for them, um so the wallet has a collection of installations. Instances issuers things like that with your pet names for them, and so adapts, are able to suggest pet names, um but it's up to the user to actually approve those things, so um so we're gonna suggest uh the issuer.

B

uh We're gonna call that card issuer, um and so in our wallet, let's see so in our wallet, um we can see that uh the card issuer is here under card, so this is a pet name and.

B

Here we go here's our list of issuers.

B

um We can actually uh go in here and change the pet names, um but you can, you can see how it actually gets displayed in the wallet all right, so that is most of the card store code feel free to ask questions, um but I just want to go over again some of the composability and features that we saw so we're able to use the same cell items, contract installation as other people are and we're able to benefit from their audit so because the contract installation, because the the code once it is installed, is, uh is instantiated in the form of an object.

B

We can just do object comparison to see if it's using the same code as something that we've already audited or someone else has already audited. So you don't have to do something complicated like actually look through all of the code, for you know slight changes or compare hashes or anything like that.

B

Another cool feature is that we can create contract instances inside other contracts, um so we don't need to. um We don't have to do this from the outside as a user, even though we can and a contract can act as a user to another contract. So in the sell items contract, what we saw is that it's a contract between sellers and buyers and what we use the sell items contract as we took the buyers for sorry.

B

We took the the seller's perspective, but we acted as the seller in our contracts that we wrote in order to sell baseball cards specifically so the sell items contract was generic, we could have sold event tickets, we could have sold whatever it is that we want, but we used that in a very specific way. We reused it. um We reused it in terms of using installation that was already installed um to sell baseball cards. So that's a really cool feature that we have all right.

B

So um some of the resources you might have seen in an earlier presentation, but our hackathon documentation is up. um All of this code is in igork sdk um in terms of uh ertp and zoe, and all the things that I've talked about. We have a number of contract examples um which are also in agorak sdk and then, uh if you are looking once you've kind of gone through some of these basic demos, if you're looking for more that is specific to uh to oracles uh try looking at our price authority api.

B

uh This is what can be hooked up to the chain-link oracles and so in later, talks we'll go through two contracts that use this there's a loan contract, which is kind of like a maker vault in a way there's a call spread contract, which is a financial instrument that allows you to take a certain position on what the future price is going to be of an underlying asset and if you're interested in more adapt templates and examples, you can also check out our documentation on that. I think we have maybe 10 of them.

B

At this point and, like I said, some of them use react some of them use um swelt. uh I think, there's a view one as well. So uh if you're interested in different formats and all the different situations that might arise, uh definitely check that out, we have a. We have one for automated uh market maker with a constant product, invariant so very similar to uniswap so check that out. It's called autoswap. So that's one of the daps that we have and- and that's it thank you so much guys do we have any questions.

A

Hi kate, so there's been a long conversation uh regarding wallet in in chat. I think dean has taken quite a bit of it. I actually have a question for you, as you were, going through uh some of the building, some of the ui out for the uh baseball card store for people that are looking at um the prize around best user experience. All right in your mind, are there easy uh or clear enhancements that we should make or that users should be targeting or things that you wish that you had.

B

That's a really really good question. um There are definitely a lot of enhancements that we know that we want to make and a lot of them are in the wallet. So that is a editing. The wallet is a bit more complex than editing your own dap, but we would be happy to help people through that. um The wallet is within the agoric sdk repository, so you would be making a pr against that um to be able to edit it or have your own fork of it.

B

um I think the things that I would want to see so um so, as you saw, there's a lot of uh there's a lot of back and forth between the daps and the wallet.

B

One thing that we've been working on internally is figuring out how to have a wallet functionality safely within the same web page as the deck, so you might be able to actually import a import, uh whether it's in the form of the iframe or or something like that- hopefully not an iframe. Hopefully it's simpler than that, but just import. You know a button that says approved app within the dap webpage in a way that is entirely safe, and so this is.

B

This is kind of the the solution that is very complex, but it's the simplest from a user perspective. Right I mean just being able. You know, you click something in the web page it's safe and you don't have to go to the separate separate web page. You know, which is your wallet right, um so that takes advantage of some of the things that we've set up um under the hood.

B

So we have cess, which is a secure, ecm script, um which allows us to run code that we do not trust or uh or run code that we do trust in an untrusted environment in a way such that the the those two entities cannot talk to each other and we can provably ensure that they don't talk to each other. So there's there's a lot of work that would go into that.

B

um So I don't suggest that people uh try that one first, but we would be happy to help people improve both the wallet and the the dapp communications as well.

A

Great yeah, I think, for those of you that are looking for honestly any of the prizes, but especially uiux. Please do reach out to us. We have ideas. We know we know areas that we would love to have made more progress on and will eventually but could use your help. So thanks a bunch kate,.

B

Thank you we'll be around for questions.

A

All right looks like one question just came in from suhail: uh why would the wallet uh be unsafe in the dap.

B

um So it's more that the dap could potentially change things about the wallet, um so the the uh the threat would be. um The dap make some kind of proposal um in our current implementation. When the dap makes proposal, you have to go to your wallet to be able to look at it and approve it. um So the threat would be that the dap somehow changes that proposal to make it look like something that you approve and it actually takes all of your money.

B

So um so that's the kind of complex uh interactions that could happen if you're, not careful. When you put things in the same web page.

A

Great thanks we'll give it a few more seconds here in case any other questions come in. um Obviously, as we've been saying, we know a lot of you may be watching this acer asynchronously. So please reach out on discord. If you have questions, we're we're all manning discord for the next.