Ticketing system

[danishyasin33]

Description

Build a contract which allows future instantiators to define their own NFTs for event tickets and sell them. Fork the “Primary Sales” page from dapp-card-store to demonstrate selling the tickets through a front end. Create a “Check In” page which verifies a user’s ticket(s) and shows seat location(s).

Additional Details The contract instantiator must be able to create a unique issuer, brand, and mint for the NFTs on instantiation.

Ticket NFTs should include: Event name Event date and time Price Seat ID

Seat ID should be defined as Seat # Row (Letter or Number) Section # Feel free to use a large real-life venue as an example.

The instantiator of the contract should be able to define ticket prices based on section # on instantiation.

The goal of the Check In UI is to demonstrate how a third party might be able to verify a user’s tickets. Since tickets are transferable, the Check In UI should be able to receive a ticket from the user to hold (i.e., on admission to the event). Any clear demonstration of this capability would meet the criteria.

Context

Event tickets are a commonly requested use case for NFTs, and an example that is easy for a mainstream audience to understand. To help demonstrate possibilities to third party developer teams, we’d like to offer a contract example for defining new tickets and a front end to purchase and use them.

Acceptance Criteria

Approach validated by the Agoric team Criteria ‘Description’ met

[danishyasin33]

Designs for now: https://xd.adobe.com/view/38b16758-5342-457f-8e4a-0ff2bceb5961-6de2/

[aamnasarosh]

Designs for now: https://xd.adobe.com/view/38b16758-5342-457f-8e4a-0ff2bceb5961-6de2/

Dev link for these designs: https://xd.adobe.com/view/1c9a3256-1aeb-4f42-9562-b6a90da8c8d7-49c9/

[Hussain-7]

Update 14th March 2022

• Created a new agoric app for the ticket store.
• Setup done for contract and apis.
• First was working on UI.
• Created clean structure for the component hierarchy.

  UI progress:

  • [x] Nav bar and Header
  • [x] Market place : Ticket List component.
  • [ ] Market place : Single Ticket card component.
  • [ ] Market place : Buy ticket Modal
  • [x] Create Event page : Form.
  • [ ] Check In page. (UI designs not ready yet)

[aamnasarosh]

Ticket Store UI -V2: https://xd.adobe.com/view/b1539a93-7d2d-4d0a-9019-afb8f1d5c190-e400/

Dev link: https://xd.adobe.com/view/ae434155-b1f7-4426-b504-01a0117d8d7a-fb10/

[Hussain-7]

Update 15th March 2022

• Added dummy data in a way so that no change to frontend would be required when backend is implemented.

  UI progress:

  • [x] Nav bar and Header
  • [x] Market place : Ticket List component. (mobile Responsive)
  • [x] Market place : Single Ticket card component. (Responsive)
  • [ ] Market place : Buy ticket Modal.
  • [ ] Create Event page : Form. (Changes Required)
  • [ ] Check In page.
  • [ ] Info components : Purchase popup modal

[aamnasarosh]

Ticket Store UI -V2: https://xd.adobe.com/view/b1539a93-7d2d-4d0a-9019-afb8f1d5c190-e400/

Dev link: https://xd.adobe.com/view/ae434155-b1f7-4426-b504-01a0117d8d7a-fb10/

Added the "Check In" screens to the same link

[Hussain-7]

Update 17th March 2022

Amm-curve

• Had to switch back to the previous convention used. Which was all calculations without amounts and ratios.
• tested out again and push latest code to bonding-curve-ratios branch

Ticketing store Issue:

• Setup some application context to manage context throughout application and minimize prop drilling.
• Now Market place page is completely full responsive (mobile aswell).
• Search functionality added for market place events using name and tickets left filter
• price calculation and logic added to marketplace.
• Check in page left and a minor fix to create event form.
• latest code available in ui branch

[aamnasarosh]

Replace this drag & drop image field with image URL input. Updates on the same links.

[Hussain-7]

Update 25th March 2022

• [x] Completed checkin page cards.
• [x] Search bar logic added to checkin page as well.
• [x] Ui fixes on createEvent page.
• [x] Price calculation logic added in marketplace page.
• [x] Modal for createNewEvent.
• [x] Modal from buyTicket.
• [x] Modal for checkIn
• [ ] Modal for congratulations on each page
• Latest code pushed to ui branch.

  Todo up next:

• UI is completed almost just a simple modal is left.
• Will start working on the contract functions next.

[Hussain-7]

Update 28th March 2022

UI completed:

• Created Modals for success for each page
• Integratedpinanta for images. All images are rendered through pinata url.
• All ui hooks completed and Application context is being managed for every page.
• All the modals are now hooked to the frontend.

  Flow for marketplace :

• Will maintain a notifier which will store the events array on the marketplace page.
• Only the during deployment of contract , the events on the marketplace page can change.
• Next, when a buyer comes an buy certain amount of tickets from this marketplace, after accepting the offer from his wallet the amount of tickets he bought will be minted to his wallet.
• Each ticket is a separate NFT irrespective of the event Name.

  Progress:

• Restructured and cleaned the contract and api directory.
• Updated the contract and api deploy script.
• Created a single contract for marketplace and checkIn tickets flows.
• Still need to test the notifier.
• Latest code is pushed to backend branch.

  Next Todo:

• Will hook the marketplaceTicketNotifier to the application context and the frontend for marketplace will show the tickets coming from the contract.
• Then will have to add function for buy ticket and checkIn tickets.

[Hussain-7]

Update 29th March 2022

• Connected the marketPlace cards context to the notifiers, so now the cards being displayed in marketplace are from the available offers in the contract.
• Added loader to marketplace page.
• Added pagination to marketplace and checkin page
• Ticket card Purse creation in user wallet automatically.
• Created a MarketPlace contract on which have all the notifiers logic.

  Next todos:

• makeOfferForTickets() would have functionality for creating seller seats for all the event tickets that are in marketplace.
• Then makePurchaseOffer() can be called by the buyer to make matching offer to cards put on sale in marketPlace.
• After that a function for checkin will be required which is very simple.
• Functionality for minting card is already ready just need to call it and connect to frontend.

[Hussain-7]

Update 5th April 2022

• Implemented the logic for putting all the tickets on sale.
• This is done only by the creator Facet.
• Tickets can only be put on sale by the contract deployer.
• The card minting logic is already done.
• The checkin section also shows all the cards owned by the user.
• Just have to create Buy ticket functionality. And hook it to frontend.
• Have some issues with contract Currently, need to discuss this later

[Hussain-7]

Approach in Ticketing Store:

• We will be extending the simpleExchange Contract where the seller will be the contract deployer.
• So he would have all the cards or tickets that are to be put on sale minted into his wallet.
• For the marketplace when the buyer buys some ticket the same simple exchange flow would .
• Only the creator of the contract should be able to use mint Tickets or Events.

  Update 8th April 2022

• Added the ticket minting functionality in the deploy script.
• So all the event tickets are now being minted to contract deployer's wallet.
• The tickets in the marketplace are being fetched from the notifier maintained in the contract.
• Checkin page tickets are now directly being fetched from the wallet.
• There is one thing I still need to discuss for the ticket minting flow:
  • Previously when we deployed scripts to deploy contract and api's after running agoric start.
  • It was not nessasary that the wallet have to be connected to the dapp.
  • But now due to the ticket minting flow before deploying the api the wallet must be already connected to the dapp.
• latest code pushed in backend branch.

  Next todo's:

• Have to integrate the make seller function in such a way that seller offer is generated for all the tickets when the deploy script runs.
• After that buyTicket function can be use to make buying invitation and the same simple exchange flow can be followed as before.

[Hussain-7]

Update 12th April 2022

• Changed the deploy script so that the ticket minting happens through deposit facet instead of sending and accepting offer in wallet.
• Once seller wallet has all the nft's . A zoe offer is being sent to the contract that will then trigger the exchangeOffer() function in contract.
• When this exchangeOffer handler runs all the sell seats will be automatically be managed in the BookOrders( notifier ) provided by simple exchange contract by default.
• But there is an issue in zoe offer generations which I mentioned in the channel.
• Also added a function in ui service for purchasing tickets which I will be able to check when the zoe offer issue solves.
• After the sell issue resolves just have manage some state in the frontend to convert all the separate tickets from the sell offers to array of events which will be displayed in the marketplace.

[Hussain-7]

Updated Flow and structure : https://gist.github.com/dckc/9c393be1bd5a147f72c6b42ca12a1aa2

[Hussain-7]

Update 13th April 2022

• Now in the deploy script the card are being minted using an offer which is sent to seller wallet for accepting minted tickets to their wallet.
• Previously card were minting through facet and wallet had to be connected before contract was deployed.
• Fixed that flow. Now no need to connect wallet before deploying contract and apis.
• After that a zoe invitation is also deposited into seller wallet which will help us figure out difference between seller and other users at the frontend.
• Next have to use the continuing Invitation Pattern with the invitation already available in wallet to put the tickets on sale.

[Hussain-7]

Update 15th April 2022

• Read through all the code snippets provided for continuing invitation pattern.
• Made some changes to deploy script as offer must be sent to zoe instead of wallet.

  Current Progress:

• In the deploy script an offer is sent to zoe to mint nfts to current user's wallet.
• This returns a seat which is used to get the Ticket payment or payout.
• This payout is then split to separate tickets to make individual ticket payments.
• Now just offers need to be sent to zoe for putting on sale. Have to still figure out some things with continuing invitation.

[Hussain-7]

Update 18th April 2022

• Previously the was minting was being done in deploy script. But had to be shifted to the dapp side.
• Since eventually the minting is also required when we create new events. So minting and selling must be handled from the dapp.
• So setup up an isSeller context to detect whether user is seller or not.
• By checking through the invitations in zoe purse and if it contains a creator invitation then we set seller as true.
• Added a minted state in contract that allow us to ensure that the provided tickets in deploy script are minted only once.
• Updated mint tickets function in services. Now the add offer function uses invitation query. So the dapp doesn't need to handle invitation anymore.

[Hussain-7]

Update 19th April 2022

Current Progress:

• So the issue previously was that we were not able to get creator Invitation in the dapp. To send an offer to the wallet invitation is required.
• Hence the creator invitation was deposited in the wallet at deployment of api. But still it was still inaccessible through the dapp.
• For using a deposited invitation, an invitation query is required in the offer template passed in addoffer(). The query consist of contract instance and the invitation description.
• Was successfully able to use the query to use deposited invitation and make an offer to mint nfts to the wallet.
• Now that nfts are minted from dapp the create event page logic can be also implemented easily. But will implement it after selling logic is done.

  Next Up:

• Need to update the flow diagram as well so that it can be shared in the agoric channel.
• Now the offer result of the previous offer must return an invitation maker.
• To make the continuing offer the offer Id of the previous offer aswell the description of the invitation that the invitation maker creates.
• These list of offer would be used to make selling offers.
• Still need to figure some things in selling offer will discuss in the channel as well.

[Hussain-7]

Update 28th April 2022

• Previously had the invitation query thing up and running which allowed the creator or seller to make ticket minting offers.
• Invitation maker is now working as well so the sell offer are now generated from the frontend and the offers need to be accepted in the wallet.
• Can create as many offers as needed from the dapp.
• Will need to use copy bag for this case to send asminimum offers` as possible to the seller wallet
• So understood how to use copy bag from all the possible resources.

  Next Up:

• Just have to figure out how many offers to send.
• Then also have to figure out how the cards on sale must be displayed in markeplace section
• Then same flow for buying can be used as in card store.
• After that just have to hook ticket minting functionality to create event page. The functionality is already there.

[Hussain-7]

Update 29th April 2022

• So what ever logic was displayed here is now being done.
• The offer sending logic is not very clear from the diagram so that was still to be sorted out.
• What needs to be still figured which also I have worked on today is that how to combine offers for multiple cards.
• From what we discussed and what I remember of the meetings with agoric team was that to send a single offer for each section in an Event.
• By adding all the cards in a section of an event in a copy bag (or an array with simple Set value if copy bag doesn't workout) and send in wallet offer.
• Hence if 4 event are made initially and each event have 4 sections (Vip, generalAdmission , Business .... ) then 4x4 =16 offers
• This would be just required at the initial stage but if later seller wants to create offers he can do that from create section.
• And would need to accept as many offers in wallet as many sections exist in the event.

  Next Up:

• Currently I am at the stage where offers are being sent for all sections for all events put on sale.
• Need to handle the ui part to handle fetch section's on sale and parse them as events and not sections.
• and then the buy part which is much easier

[danishyasin33]

I believe this approach is fine if we are just creating offers for all sections in a event. Still a huge improvement from sending offers for each individual ticket.

[Hussain-7]

Update 6th May 2022

• Context: Why is the offer in pending state?

• So the offer is in the pending state since when the seller initiate dapp for the first time. All the minted nfts in his wallet are put onto sale section wise. Since the offer has both want and give in the proposal hence the offer will only move to accepted or declined state once the offer completes. Hence to solve this issue we can remove want from the proposal and handle that manually in offer compare seat function.

• Context: Should it not be that the seller has the event tickets in their wallets and we just show them in the marketplace. Then when a user tries to purchase it, they send an offer for that particular ticket?

• No this is not the case. When a buyer comes to the marketplace , he clicks on buy for specific event tickets and a counter offer is created. That offer is compared with all sell offers in the contract. And if it matches or is less that equal to sell offer then the swap takes place. So when we purchase a ticket the selling offer is not generated at that time. Selling offer is already there the buyer can only send offer for tickets whose selling offer is available in the contract.

Progress today:

• Read through the possible functions used in amm for swapping allocations of two seats for nat based assets.
• I don't think the approach used in for nat can be used for set assets. It quite different from what we want here.
• Apart from that tried out a few more possible ways to handle the issue of exiting seats. I think I need one more day and I might come up with a solution to this issue.
• Sketched the whole flow, will convert it to mermaid diagram and post tomorrow.

[Hussain-7]

Update 9th May 2022

• Completed checkIn ticket logic. It burns tickets and hence the checkIn ticket removed from user wallet.
• Completed create event logic. This will create a new Event and add that event to Sale.
• Added loader where ever required in the modals
• For the Marketplace issue tried out multiple things:
  • One implemented the swap function in a way that exits only the buyer's seat and not the seller Seat. But since there is no way to swap seat allocations except for using zcf.reallocate() which also checks for offer safety internally.
  • Hence if I dec 3/5 tickets from the seller seat allocation and increment 3/5 tickets in buyers seat. But when reallocate is used it will match 3/5 tickets with the give part in seller's seat's proposal which is 5 tickets. Hence offer safety not satisfied.
  • Similar case for the price part.
  • Moreover there is no other way to shift the or reallocate two seat's stagedAllocations to currentAllocation without using reallocate. So as it has internal offer safety checks. Hence offers won't match unless the counteroffer has exact offer with want and give swapped.
  • Tried some more things that also didn't workout.
• Due to offer safety checks in every zoe helper function , I think it is not possible to solve this issue without separate offer for each ticket in some way.

[Hussain-7]

Update 12th May 2022

• With the new flow completed the marketplace logic. Tested out for several cases.
• Checkin flow is also completed.
• Create event logic is still to be completed. Already sorted out how to do it but haven't completed yet.

New Updated Flow:

• First the seller runs deploy scripts. Which also start the contract and passes an array of events into the start instance function which can be stored in a variable in the contract.
• The events array in the contract is maintained as a reference in contract related to the events put on sale by the seller.
• When the buyer comes to the market place page , all the events listed there are actually rendered by getting the events array from the contract through the notifiers.
• So buyers can only make offer for tickets which are allowed on sale.
• The offer handler for buy tickets runs when the buyer accepts buy offer from his wallet.
• This offer handler first checks if the proposal matches the requirement. Then it ensures offer safety by ensuring the tickets passed in the want are also available in events array maintained in the contract.
• After few of these offer saftey checks the swapAllocation function runs which mints the tickets to user seat and the price to be paid from buyer is proceeded to seller seat.
• Using zcf.reallocate() which commits the staged allocations for each of its seat arguments, making their staged allocations their current allocations.
• After this just the buyer seat is exited which makes the offer state in wallet to go to accepted state and on the other hand the seller seat is maintained throughout the life of contract.
• For the seller the all the offers are generated through invitation makers (that is continuing offer thing).
• For non seller simply public facet function will be used which would just allow them to get invitation for sending buy offer and checkIn offer.

What's Left:

• Create events page logic.
• Some restriction to be placed for non sellers.

[Hussain-7]

Update 13th May 2022

• Create event page logic completed.
• How it works is that ,when a event is created a request to wallet is sent using the invitation maker who's access only seller has.
• The offer handler for create events simply add the new event to the array maintained in the contract to manage all the events.
• As the array updates the notifier updates the events on the marketplace page.
• Seller context logic needed to be revamped a bit due to change in whole flow.
• So distinguishing seller from normal user what I did is checked for an invitation in zoe purse which is the seller Access invitation only if it found then the user is assumed to be seller else not.
• This invitation is deposited at time of api deployment hence only seller will have this invitation.
• Apart from this fixed some issues that were in frontend that came due to change in contract flow.
• So I believe everything is completed from for the ticketing Store.

[danishyasin33]

This sounds good. Some points:

• So we are creating NFTs on the go when the user tries to buy it from the event.
• We are using the access invitation, is this a secure method? I understand that this is created on deploy stage but is this secure? This seems fine and no further processing required but we should have a lively discussion about whether this is the best practice.

[Hussain-7]

@danishyasin33

• Yes we are creating Nfts on the go when a user sends buying offer. First in the offer handler offer safety is checked and buying price is transferred to seller seat and then only ticket is minted to seat.
• We are not using the access invitation but instead we are just using the access invitation at the start when seller initializes dapp. He receives an empty offer to accept. This actually gives the seller access to invitation maker. Then using continuing offers seller can make unlimited offers for create event. The invitation is created on the go when sending a continuing invitation