Agoric card store dapp

[usamacs95]

Description

Modify Agoric’s dapp-card-store to allow users to list their own cards for sale. Make the following modifications to the UI:

• Add “My Cards” page which displays the cards owned by the user
• Add “Marketplace” page which shows secondary sales listings
• Current dapp page which sells cards to user directly becomes “Primary Sales”

User should be able to list their card for sale. User flow:

1. User navigates to “My Cards” page
2. User selects a card to list for sale
3. User chooses the sale mechanism (currently only one - Fixed price sale)
4. Choose price for listing in RUN
5. Optional for user: Choose end date & time for the listing
6. User confirms choice and creates listing
7. User navigates to “Marketplace” page and can see all marketplace listings and filter to his/her own listing(s)

Context

Agoric has an example dapp which allows users to purchase Baseball card NFTs directly from the application for a fixed price. The dapp instantiates a separate contract to sell these items and includes a basic front end.

For this project, we’d like you to extend the Dapp card store to allow holders of baseball cards to offer theirs for sale at a fixed price.

Current Implementation:

https://github.com/Agoric/dapp-card-store

Additional Notes

• There is an agoric card store dapp. Set it up and get its default version running. You’ll find it on the agoric github or website. Start implementing the designs for the new card store.
• Aamna will provide the designs. We had already worked on it.
• You two can divide the tasks between the two of you and figure out who wants to complete which part.
• One thing that is important to understand is the web socket connection in the dapps. Basically, there’s the application context that communicates with the agoric wallet through a web socket connection. Try to understand this architecture.
• Read up on the Zoe framework and the rest of the Agoric components and try to understand how it works. They have extensive documentation. Would be good to go through it and get an understanding of the brand, amount, and other similar agoric objects that are used.
• Read about Nat values, big integers, and Agoric’s safeMath and ratio libraries that allow you to perform mathematical operations on nat values.

[aamnasarosh]

Agoric Dapp Design - Dev link: https://xd.adobe.com/view/d825c6e4-887c-4432-9c98-5fce91a25cb2-8d76/

[haseebasim]

Update 17 December 2021

• Explored the original repository of the card store dapp and followed the instruction to run the app on the local machine.
• Modified the BaseballCard Component according to the design.
• Pushed the changes to Haseeb-branch.

[Hussain-7]

Update 17th December 2021

• Read in detail about Web socket connections in dapps
• Read about ERTP.
• Read up on the Zoe framework and the rest of the Agoric components.
• Installed and ran the dapp-card-store from github link provided in agoric documentation.
• For dapp-card-store to run succesfully dapp-fungible-faucet was required to be setup first.
• Completed the header component for the dapp-card-store as provided in the design files.
• Header still not mobile responsive as of yet
• Pushed the code on Hussain-branch in agoric-card-store repo.

[haseebasim]

Update 20th Dec

• Tried integrating tailwind both v2 and v3 but was facing some ES module issues.

• When tried to integrate the tailwind v2, similar to the agoric-amm dapp, faced ES module issues in craco.config.js, found two solutions for this:

  1. Change the format of the config files to ES6. (The compiler didn't detect the change and the issue persisted.)
  2. Remove type = module from package.json (On doing this the app crashes and is unable to import Asset Kind from @agoric/erp)

• With v3, I faced the same issue, i.e. the app crashed and was unable to import Asset Kind from @agoric/erp

• I will try to solve this problem tomorrow but if it still persists, then we will have to create a new UI from scratch.

[haseebasim]

Update 21st Dec

• Fixed the tailwind-css integration errors
• Modified the header according to the design but didn't connect it with the display card component. That will be done after display card is modified using tailwind-css.
• Modified the baseball card component according to the design.
• Pushed the latest updates to ui-tailwind branch.

[haseebasim]

Update 22nd Dec

• Updated the card display component using tailwind CSS according to the design
• Updated the modal using tailwind-css.
• Modified baseball card component for modal use.
• Created components for Fields and Button so that they can be reused in multiple components with little modifications.
• Completed Sell Product Modal.

[haseebasim]

Update 23rd Dec

• Completed modals for Sell product, Edit product, and Buy product.
• Completed modal for expanding image of a card.
• All UI components have been developed using tailwind-css.

[haseebasim]

Update 24 Dec

• Fixed some UI bugs in the Modal and Card display components.
• Linked the header with card display component and linked modals to baseball card component.
• Explored the web-socket connections and the contract and API scripts of the card-store dapp.

[danishyasin33]

TODO:

• [ ] Change app icon to agoric logo
• [ ] Copy readme.md from agoric repo and also highlight that the fungible faucet app needs to be running

[danishyasin33]

Moreover, today research on agoric card store API and learn how they store the player names. The question that needs to be answered:

• How do transactions work?
• How does the contract keep track of ownership of assets?
• How do we exploit the existing implementation to store urls instead of player names and map them to the actual agoric wallet.

Basically help me understand how the existing contract and it's API works and how will we implement a full scale marketplace through it.

Read up on Agoric documentation to familiarize yourself with how their smart contract works because we'll be drilling down deeply into their framework for this task.

I will catch up with you later tonight.

[haseebasim]

Update 29th December

• I have gone through the agoric documentation and have read up on the different APIs and functions being used in the dapp.
• I have developed some understanding about the working of contracts of the card-store-dapp.
• I have also developed an understanding of how the API of the dapp initiates the instance of the contract on the chain and how it communicates with the auction contract.
• Have also tried to figure out the answers to the above questions and would like to discuss these in detail.

[haseebasim]

Update 30th December

• Explored the documentation further to understand different functionalities related to contract.

• Explored ipfs and tried to understand how it works.

• Went through the card-store dapp contract and api to make things clear.

[haseebasim]

Update 31st December 2021

Tried modifying the card store dapp API to send the meta in the form of a name and a URI but was unsuccessful.

[haseebasim]

Update 4th Jan 2022

• Watched all the youtube videos except JavaScript Drag & Drop Sortable List Project and Build a Website Accessibility Tester With JavaScript & Pa11y
• Followed the tutorial React Testing Crash Course and learned about testing using cypress and React testing library.
• Understood test-contract.js to some extent (haven't fully understood it yet), it is the test code written for contracts of card-store-dapp.

[haseebasim]

Modification required for the current card-store-dapp

• Modify the card-store contracts and API to deliver more information related to the Baseball card NFTs, such as their price, discount, creator name, etc.
• Create or modify the existing auction contract for a user to sell the NFTs.
• Create logic that can be used to edit the NFTs, such as their price and discounted price.
• Create a contract for a user to buy an NFT.

[haseebasim]

Update 15th January 2022

• Went through the documentation thoroughly again.
• I have studied the documentation and believe that we can use the Atomic Swap contract that comes with Zoe for selling the cards app.
• Moreover, I have explored the code and I think I have also found a way to pass more information to the UI. The card store dapp uses the auction item contract to send card names to the UI we can modify that.

[haseebasim]

Update 16th January 2022

• Read the rest of the documentation, and understood Zoe, ERTP in-depth, also read up on Atomic swap and how it works.
• Explored to figure out if my understanding of the code was right or not.
• Explored UI code to understand how the UI is communicating with the Contract and API.
• Was able to send imageURI as metadata to the UI and understood how it's being done.

[danishyasin33]

Your tasks @haseebasim

• [ ] Figure out how to store state in the contract to track users putting items on sale. If any users put an item/nft on sale then this should be stored in a persistent storage like the contracts @store or something. Or maybe we can do this via the Zoe invitation board or something like that if Zoe keeps tracks of the offers and we can use that for tracking which item is on sale by whom.
• [ ] Figure out how to map the items on sale with the details of the item. For example Haseeb puts an item on sale, we get this information via the board or the contract storage. The next step is to get it's meta data. How will we get this?
• [ ] Also read up on how to cancel an item on sale.
• A good strategy would be to read up on how the primary marketplace works right now and we track which NFTs are no sale right now. Maybe create a new NFT for sale.

Your tasks @Hussain-7:

• [ ] How will users create transactions for the NFTs. Meaning, will we be able to use the swap contract? Will it be a direct swap? How will we match the seats. Have a thorough understanding of the transaction model from end to end.
• This will basically involve ERTP transaction model so you will have to gather a deep level understanding of the ERTP and figure out how to transact on non-fungible tokens. There is appropriate documentation regarding this on the Agoric documentation.

[haseebasim]

Update 17th January, 2022

• For storage read up on board and how we can use it to store different entities on the chain. I will further explore agoric/store to figure out how it can be useful to us.

• Explored offers in detail and learned how one can escrow their assets in the offer and how payouts work.

• Also learned about the exit strategy and user seat and how it can be used to exit the offers.

[Hussain-7]

Update 17th January 2022

• Read throught the JavaScript framework used in agoric which includes concept of:
  • Hardened JavaScript
  • Eventual Send the E()
  • Far() , Remotable and marshaling
  • Notifiers and Subscribtions
  • These concept can be used to send notification or values of updated offer status or to get the current offer status from the contract to the frontend. Aswell as to communicate with the wallet to get changes in offers received by a particular user wallet.
• Gone through the Ertp function related to creating and using non-fungible assets.
• Figured out how we can use the card/store in contract to maintain a persistent storage.
• Read a few contracts related to our use case.

[Hussain-7]

Update 18th January 2022

• Fully understood the contracts like:
  • Atomic Swap
  • Mint and Sell Nft contract
  • Basically we need to combine these in a single contract and we would get what we want in our use case.
• Read the whole agoric white paper and the deep dive into agoric js smart contract article. Which were very helpful as these type of details were not available in the agoric official documentation.
• Read everything related to cosmos.

  Approach to progress:

• Figuring out what the current contracts in the app are currently doing and what changes are required in them if we want to use them.
• Since the user wallet do not have any nfts ,this is for sure that nfts are not from user wallet.
• Hence our next approach is to create a contract that takes this baseball card data and use these to mint some Nfts and add them to user wallet.
• Once this is done we can show the nfts from the user wallet in the myCards section.
• Then we would require to maintain a context to store all wallets on new socket connect. The obj to be stored will contain walletPromise through which we can call wallet api calls on that specific wallet.
• We can use the wallet access token which is unique for every user wallet as the key value .That we can get to differentiate wallets obj what we store on connection of a socket. But still have to figure how to get that.
• If this is successfully done we can show all the available Nfts in the Nft secondary marketplace section, Just filtering out the user NFTs from the ui.
• I have also thought off the approach for maintaining exclusive invitations for each nft that is available in the market place but that is only possible once the above task are done.

[haseebasim]

Update 18th January 2022

• Read about Cosmos and how it is revolutionizing the web3.
• Read about the purses and wallets and figured out how can a purse be added to the wallet.
• Got on a call with Hussain to discuss the future approach in improving the dapp and the current implementation.
• Went through the Atomic Swap again to understand the matching offer functionality Hussain talked about and Read up on the Mint and Mint and Sell contracts.

Future Todos

• I have to read up on JavaScript Framework Section in the documentation.
• As the cards are not yet present in the wallet we have to figure out an approach to Mint them and store them in wallets. For now, we can modify the Mint and Sell contract to do that and create a single source of truth for cards, but in future we would have to store each card in their respective owner's wallet.
• After the above is done, we can easily get NFTs from the wallet and display them on the UI.
• We will also need to use IPFs to store the Metadata for the NFTs, so that we can easily fetch all the details regarding the NFT. This is what Sam suggested.

[Hussain-7]

Update 19th January 2022

RoadMap to completion:

1) Show current user's nfts on the My Cards page

• Currently users donot have any nfts in there wallets. So first we need to create a contract which will mints nfts to user wallet.
• Then we deploy it so that those nfts can be rendered on the my cards page.
• This contract can later be used when we create add nft functionality to the card store.

  2) Add sell functionalty to the nft cards in My Cards page

• We can create an api end point at the backend deployed on ag-solo to run create offer method on the instance of contract deployed on agsolo. This would create a new seat for a specific nft.
• We can also pass offer description in which we can pass any offer details nessary. Once offer is created we donot need to track which offers belong to which user wallet since the nfts or the asset will already be escrowed by zoe.
• So as soon as this offer get a matching offer and zoe has escored asset from both parties then offer will be exited
• Each user will get his share automatically whether the offer accept or rejected.
• And a the notifier on that particular seat will tell us that an offer is completed or exited. Which we can reflect on the frontend using the api created in the backend.

  3) Show all nfts put on sale in Secondary Marketplace page

• Next question is how to get the nfts a user has put on sale?
• How can we get all the nfts on sale?
• The user seat which the contract gets when the create offer function is called can be stored inside agoric store. Then state of this store can be pulled to the backend by creating a function which returns the map.
• This map which consists of all user seats that can be used to get nft's meta data which can be used at the frontend to render all the nfts available for sale.

  4) Add buy functionality to cards on Secondary Marketplace page

• Now that we have nfts detail also available along with the invitation to create a matching offer.
• We just need to call the create matching offer function from the contract and passing the right arguments for the proposal which can be easily created by just creating a reverse proposal of what the invitation's proposal would have.
• Once the offer is completed both the escrowed assets will be given to the respective parties.
• When the seat exit is called in the contract the seat must be removed from the mapping.
• The offer status can be updated as soon as the offer completes, since we would be using notifiers on the this particular seat.

  5) Show all nfts put on sale by agoric in Primary Marketplace page

• Will add details later

[haseebasim]

Update 19 January, 2022

• Read about the JavaScript framework of Agoric and learned about hardened JS and SES and their importance in the Agoric Ecosystem.
• Read up on the task and provided a detailed explanation of how we can achieve them.
• Created a contract that utilizes the Atomic Swap contract that can be used to swap two assets.
• Created a Test for the contract as well that ran successfully.

Future Todos

• Expand the current implementation of the contract to store the assets in the wallet.
• Try to store the invitations in the contract instance.
• Implement a Mint contract to mint NFTs

[danishyasin33]

Questions to be answered:

• why not test easily by buying an NFT from the current store and using it to test My Cards page?
• How do we cancel offer if we do not keep track of which offer belongs to which wallet?

[danishyasin33]

• while setting up the marketplace contract, study how we can limit the mint functionality to the creator of the contract. We have the special creator faucet that is only visible to the contract creator, it might be that we limit the mint function to the creator faucet.

[danishyasin33]

@haseebasim your task:

• Buy an NFT from the current primary market contract
• Show the NFT in the my cards page.
• Also improve the NFT to store the whole meta in a JSON string. This should contain all properties of the NFT. It will contain the image property which will contain an IPFS hash or a https url to an image.
• Front end will have to parse this json and present the NFT appropriately.
• Use the following meta data for testing: link

Acceptance Criteria:

• [ ] Buy an NFT from the current primary marketplace contract that has the NEW NFT with the appropriate metadata.
• [ ] The NFT should appear in 'My Cards' page and the meta data should be parsed appropriately to show the image and the name at the least.
• [ ] Update the contract test to ensure it passes with the new meta data if required.

Flow to parse ipfs

• Store metadata on pinata ipfs using openSea metadata standards.
• While getting NFT from the contract, check if NFT's string/token data is an IPFS hash link.
• If it is ipfs, then get its json using pinata gateway or some other gateway like Moralis' IPFS gateway.
• Example IPFS meta data: link
• The image inside the pinata might also be an IPFS hash, so you would have to perform these steps for the image ipfs hash as well.

[haseebasim]

Update 20th January, 2022

• Uploaded the images to pinata and got the hashed CID.
• Created JSON for each baseball card by following the standard defined by Open Sea. { name:"", image:"", description:"" }
• Entered image CID for each baseball card in their respective JSON.
• Uploaded the JSON to pinata and got the CIDs for each card.
• Supplied the hashed CIDs to the front-end
• Was unable to decrypt the PID and get the meta on the front-end due to some errors.
• Will try to get the meta from pinata today and buy NFT from primary sale and store them in wallet.

[Hussain-7]

Update 20th January 2022

• Created an api endpoint in the backend for handling minting of Nfts.
• Created a mint nft function in the contract.
• To use that first instantiated the contract in the backend and using the createFaucet was able to call the mint function.
• From the frontend was able to call the api end point using Rpc(remote procedure call).
• On which I got the handler for api end point using which I was able to send an offer to the backend.
• First used the nft mint function on the contract just to mint fungible token and I was successfully able to do that.
• Had some issue when I changed the logic to minting nft instead of fungible token. Will try to fix this issue today and move forward onto next task.

[Hussain-7]

Update 21st January 2022

• Was having issue with minting Nfts directly to the user wallet. So changed approach to what was mentioned here https://github.com/robor-systems/agoric-card-store/issues/2#issuecomment-1017189270
• Was able to use the mint and sell contract for Nfts using the data provided.
• Using the public Faucet from the frontend was able to get all the current Nfts for sale in the primary market place.
• Supposed that the minted Nfts belong to the Primary Marketplace.
• Updated the ui a bit to show buy button and modal in the market places and to show sell button and modal in the MyCards section. Models were already implemented just changed logic to render them.
• Already have access to buy nfts function in the frontend just need to change ui to do that. Currently there is no modal for bidding prices.
• Will try to finish this up tomorrow so that we are able to buy nft's from primary market place which appear in my cards later on.

[haseebasim]

Update 21st January 2022

• Solved the pinata ipfs issue and was able to get the NFTs and display them in the dapp.
• I created the contract for AtomicSwap and also updated the APIs to deploy the contracts and install them on the board.
• Modified the UI to buy NFT from the marketplace, but encountered a problem and was unable to get the public facet functions from the Contract.
• Will figure out a way to resolve this over the weekend.
• Will also create a modal for bidding and implement the current contract functionality. The functionality is already there just need to link it up.

[danishyasin33]

@haseebasim store the whole json string of the meta data in the contract instead of just the ipfs hash. We will retrieve this string in the UI and parse the image IPFS hash from it. This will also need an attribute by the name of id, which has to be unique and will be used for tracking offers as pointed out by @Hussain-7. These ids can be created via nanoid

[Hussain-7]

Update 24th January 2022

• Implemented some part of the flow where a user wants to sell some of the nfts he owns.
• Added the whole flow for atomic swap contract to be used in our dapp.
• First added a deploy script in the backend. Which puts the id of public faucet and creator faucet of the contract on the board from where we it is easily accessible by the frontend.
• After that to use the atomic swap contract we needed to create an offer to use the atomic swap contract. Which required us to get certain things at the frontend:
  • For that we needed the same minter, issuer and brand from the main card minting contract to create a payment.
  • The wallet promise which then allows us to get zoe at the frontend.
  • Which we can use to call contract instance and using that we get the Sellers invitation.
  • Using the Seller's Invitation, Proposal and the Payment we create a offer which return a user seat (Seller Seat).
• Uptill now the I'm successfully getting a seller seat at the frontend which can be used to make the buyers matching offer.
• Will complete it tomorrow.
• Pushed the latest code in secondary-market-place branch.

[haseebasim]

Update 24th January 2022

• Converted the NFTs meta to only contain JSON objects with ipfs hashed images.
• Updated the latest code to handle the new metadata.
• Updated UI errors in card display component.
• Fetched cards from the wallet to be displayed in the My card section.
• Figured out an approach to handling offers and storing them in the contract so that they can be later on used to identify which card is on sale and which is not.

[danishyasin33]

• For that we needed the same minter, issuer and brand from the main card minting contract to create a payment.

For what purpose do we require minter and issuer? We cannot create new asset types on the front end. Whenever a new asset needs to be minted, this should be handled through the contract methods.

[Hussain-7]

• For that we needed the same minter, issuer and brand from the main card minting contract to create a payment.

For what purpose do we require minter and issuer? We cannot create new asset types on the front end. Whenever a new asset needs to be minted, this should be handled through the contract methods.

• yes will shift them to the contract instead of using at the frontend.

[haseebasim]

Update 25th January 2022

---

• Read about the notifiers to find out how they can be utilized for the exchange of information between the contract and front-end.
• A notifier is basically used to get updates about the state of an offer or other objects.
• Implemented the notifiers in the contract.
• Was able to receive information about the offers in the front-end on the successful creation of offers.
• Later on, integrated the notifiers in the latest contract code updated by Hussain. Was facing some issues.

Todos:

• Get the latest code of the contract from Hussain and set up notifiers in it.
• Fix the issues related to the notifiers in the updated contract if there are any.
• Modify the contract to retain the offers and invitation details.

The Flow of the Secondary Market Place

• A user can sell their cards from the My Cards tab.
• Once the sell button is clicked, a modal opens that contains the card details and a form. The user needs to fill out the form and specify some price for the card (For now we are using a fixed price).
• Once the Place in Marketplace button is clicked. GetSwapObject function run that gets all the relevant information from the board using the ids that are acquired when contracts are installed and deployed over the chain.
• After getting all the relevant information to create an offer we use the public facet of the Swap Assets contract to call a function getSellerSeat present in the contract.
• This function creates an offer for the seller and returns the seller seat which is basically an invitation for the buyer.
• The contract implements the notifiers to send offer information to the front-end after storing it in the contract instance.
• When the getSellerSeat function is called and an offer is in the process of creation we store the relevant card Amount in the contract instance and when the offer has been successfully created the notifiers are used to send that card Amount to the front-end so that it can be cross-referenced and the particular card for which the offer is created, can be listed in the market place.
• This is the current implementation.
• The contract instance must also be updated to store seller seats along with the card Amounts.
• The contract further needs to be modified for buyers, when the card is displayed in the marketplace, buyers can buy that card and on clicking the buy button, a contract function will be called using the public facet of the contract, which will take in all the relevant information of the buyer to create a matching offer.
• On successful creation of the offer, the contract will swap the assets and will provide both the users with the assets they desired.
• Both the buyer and seller payouts will be collected and deposited into their respective purses.

[Hussain-7]

Update 25th January 2022

Current Progress:

• First shifted all the functions related to the minters and issuer to the contract to improve security.
• Had to use the same issuer, minter and brand throughout all the contracts , so changed the contract so that this is done.
• Implemented the logic for creating a buyer invitation. Which is also explained in flow below.
• Apart from this was working on how the seats for each card that is put on sale will be maintained and thought off a solution for that as well.
• Have a little issue in swap of allocations of buyer and seller will fix that tomorrow.
• @haseebasim has already mentioned in detail how we put the cards on sale from the ui and how the cards when put on sale are displayed in the secondary market place page (using notifiers).
• So will just explain the two main functions getSellerSeat() and getBuyerSeat() .

  Flow for a adding card for sale in secondary market place:

• The getSellerSeat() is on the contract and is called using the public faucet.
  • It require the card detail ,selling price and few more things.
  • First it create a proposal with the give and want object.
  • Then it creates payment object using the selling price and the card details.
  • Then we create instance of the contract which return us the sellersInvitation.
  • Now this sellersInvitation has a handler matchingSeatInvitation() which will be called later in the buyers flow.
  • Next an offer is created using the seller Invitation, proposal and payment object which returns the seller Seat.
  • By using offerResult() function on the seller seat we get an invitation that is stored and later used by the buyer of this card to make a matching offer.

    Flow for a Buying card from secondary market place:

• The getBuyerSeat() is on the frontend. This function does not require any minters so its safe to use here.
  • Now this requires the sellerSeat which we will be storing in a map in the main contract which is currently not done.
  • First in the same manner to create an offer we need a proposal , a payment object and a handler which we get after calling getofferResult() on the sellerSeat.
  • This handler will actually trigger the matchingSeatInvitation() function which I mentioned above.
  • Now once this function is called it will have a buyers seat aswell as the seller seat. Since the contract instance which was instantiated by the seller has the seller seat already in it and now the buyer is using the function of the contract instance with the seller seat already in it.
  • Now this matchingSeatInvitation() creates another invitation with the offer handler that matches the offers in zoe by comparing both the seller seat and buyers seat .And if the offers match.
  • Both the seller and buyer seat gets there respected payout's.
  • For swapping the seat allocation on offer match we are using a built in function for seat allocation swap.
  • we get returned buyers seat from the offer function called from the frontend which is than used to get offer status and notifers.

[danishyasin33]

Questions:

• Where do we store the card amount containing card info in the contract? We use agoric maps I assume but how do we map these card amounts to the sellerSeats?

[danishyasin33]

Summary of the Agoric NFT card store

The old NFT marketplace already had the functionality of the primary marketplace. It is kept as is for now and we have not made changes to that contract.

To add in the functionality of the secondary marketplace where users can place their items on sale and carry out transactions with each other, we have created a new smart contract called secondaryStore.

The new contract is based off of the atomicSwap contract. This is because we required the swap functionality already being employed in this contract. Now I am going to explain how we are achieving the main functionalities of the secondary marketplace:

Selling an NFT

• The contract has a variable availableOffers which is an Amount object that stores the array of all sell offers on the marketplace.
• When a user will click on sell on their NFT in our marketplace, our contract will generate an offer then store the metadata and the seller seat in this array.
• This persistent storage will then be read in the frontend to show the NFTs that are available for sale.

  Buying an NFT

• When a user buys an NFT, the corresponding matchingSeatInvitation() method will be called that will be retrieved using the seat details available in the react app through the method described in the selling an NFT section above.
• The matching offers will be created and the contract will use the methods provided by AtomicSwap contract to trade the assets and transfer value between the buyer and the seller.

@rowgraus

[haseebasim]

Update 26th January 2022

---

• Tried resolving the issue with the notifiers at the front-end. The notifier wasn't working correctly and was unable to fetch the updates dispatched from the backend.
• Created an abstraction over the contract swapAssets, by the name of swapWrapper to implement notifiers again and make them work correctly.
• Optimized the getSellerSeat function to receive all the required issuers, brands, installations, and minter when its instance is created on running the API deploy script.
• Again implemented the notifiers and created availableOffers amount to store the amounts of all the offers.
• Verified the working of the notifier on the client side. It was correctly receiving the updates as it was supposed to.

• Implemented a small function in the contract.js file to mint the provided NFTs.

  Todos

• Test the mint function in the contract.js.
• Create an offer template for the wallet and store the newly minted cards in the wallet.
• Setup a small screen that can be used to mint new NFTs by the user.
• Write a script to deploy images to pinata and get the hashed CIDs
• Setup contract to store seller seat along with the card amounts.

[Hussain-7]

Update 26th January 2022

Progress

• Was previously having in the with sending offer to contract from the buyer end.
• So as we discussed , used the wallet promise to send an offer to the wallet when the buyer click on buy on the card from secondary market place.
• Used the same seller Seat Invitation which was returned from getSellerSeat() which will be stored in the contract along with the offers which are being maintained in the new wrapper contract.
• Was having issue with the offer format looked up the addOffer () in amm and the addOffer() in the auction contract , using those was able to figure out the correct format.
• Have Reduced the code required at the frontend to just the simple stuff and shifted main logic in contracts.
• This offer is now successfully sending , have testing out its working from a single user perspective.

  Next Tasks

• Create a function to store the seller seat invitation in contract where the offer for same seat exist in the contract.
• Need to merge all the code with @haseeb part (notifiers) so that we can integrate functions at the ui as well.
• Will test out the flow from multi user perspective today.

[Hussain-7]

Update 27th January 2022

Progress:

• Added functionality to store seller seat Invitation along with the offers.
• Merged all the code with @haseeb part.
• Spent a lot of time in trying to run the Dapp with multi users. There was some progress:
  • The golang issue was basically due to the version.which was not letting me make cosmic-swingset in agoric -sdk.
  • Was able to run the local chain.
  • On that was able to to run two api ag-solos
  • Two separate wallets connected to separate client browsers
  • But had issue with deploying contract and api on either of the ag-solo.
• Had issue in the part when the offer was rejected by wallet then both the seats were exiting which resulted in error when we made an offer again. Came up with a solution for that.
• Previously the price at which items were brough from the primary market not being saved. Now that is also done
• To call the offer notifier for updating the available offers array in the contract also required us to know whether wallet accepted or rejected offer.
• So to manage that added wallet offer notifiers that respond to whenever an offer is accepted and only then we remove the offer from available offers array in the contract

  Todo's Left

• Minor ui fixes for modal.
• Have to create a function for removing nft from sale. Frontend part is done already just need to create a simple function and connect them.
• Apart from this only testing of app for tomorrow.

[Hussain-7]

Update 28th January 2022

Progress:

• Have added changed loader logic for each section .
• Added loaders on each functions performed when in modal.
• Price for items bought from primary should be stored as well as it changes when sold and bought from secondaryMarket.
  • Have added similar notifiiers logic like which was implemented for available offers to maintain offers.
  • In this approach maintaining a lookup array in the contract which stores meta data of all nfts owned a user.
  • By getting that at the frontend , Im able to get price for both sale and purchase.
• Remove from sale functionality added using the seat which is store in meta data of cards in the available offers.
• Multiple ui bugs fixed.
• Haved Pushed the latest code to the secondary-marketplace branch.
• No more todos now for this dapp.

[danishyasin33]

Gracefully handle error when contract is not deployed:

[danishyasin33]

Please add url parameters according to tabs to make it easier to open to a specific tab:

• Please update favicon to Agoric's logo

[danishyasin33]

Note:

• We are not currently supporting the set sale time out functionality since it is unclear how it will be handled.

[danishyasin33]

@haseebasim please fix the designing of the marketplace, the cards are not stackable and are not responsive. Please check for design inconsistencies throughout the dapp:

[danishyasin33]

@Hussain-7 please add comments in contracts and api code, explain the thought process behind each variable. Also write tests for all the contracts.

Comments should match the following patterns: // CMT (hussain@robor.systems): comment text

@haseebasim please take note as well and do the same for minting contract

[Hussain-7]

@haseebasim please complete the following task. Before moving to any next task. These were some of the issues @danishyasin33 pointed out during the code review.

todos:

• @danishyasin33 mentioned in this pr review : https://github.com/robor-systems/agoric-card-store/pull/6
• You have to fix all the issues mentioned in the above review.
• I'll explain only some of the complex issues from review and the rest you can easily resolve yourself.
  • Have to write comments in the secondarystore contract that why we needed to create a separate contract for the matching invitation function. Moreover why this task cannot be performed in the same secondaryStore wrapper function.
  • Clean up app.js by creating a separate Application context and then use that context inside app.js. Refer to the agoric-amm application context file. Mainly have to move all activateWebSocket code to a context and then use that context inside app.js. Reference : https://github.com/robor-systems/agoric-amm/blob/main/ui/src/context/Application.jsx.
  • With reference to this discussion : https://github.com/robor-systems/agoric-card-store/pull/6#discussion_r795459237.Basically you just have to shift this logic to the contract instead of being at the frontend. What this code snipppet does is apart from the available offers that you already know of I've used the updaters to store the sale and purchase history. Try to shiftthis logic to the contract. You may need to handle communicationbetween contracts.
  • Also in the api and the contracts explain the whole process behind the use for a particular variable(The amount arrays mainly) and explain the use case these variables are required for.
• Apart from these the rest of issues are quite simple but still if you find any problem ping me for more details.

  Some Incremental fixes:

• [ ] fix reference : https://github.com/robor-systems/agoric-card-store/issues/2#issuecomment-1025460771
• [ ] fix reference : https://github.com/robor-systems/agoric-card-store/issues/2#issuecomment-1025462295
• [ ] fix reference : https://github.com/robor-systems/agoric-card-store/issues/2#issuecomment-1025465212