Discussion

[jorgenbuilder]

orcsun — Yesterday at 6:04 AM For the burning, I might think a little different. Originally I was thinking the ticket NFT as the proof of event, it has collectable value for users. For example, I kept the airline ticket when I landed Canada first time because it's a memory for me. Same as others, many people like to collect all kinds of events tickets, even trading them on market, so I didn't think to burn it. For pre sale, it can be looked as a proof of whitelist. 🙂 For minting, you mean to pre mint all first to event hoster, right? My original idea is minting just after user pay for registering an event since we don't know how many users will attend the event. It's really good start, we will talk about the details later 👍

Jorgenbuilder — Yesterday at 8:49 AM Making tickets permanent puts some kind of damper on the idea of recycling memory. I wonder how data archiving should work. The NNS ledger apparently uses a linked list, where a certain threshold causes a new canister to spawn that links to the old one. I guess the NNS ledger canister that we interact with sits atop that pattern so that we have a one canister to interact with. orcsun — Yesterday at 8:58 AM there is another option which I am also thinking about for ICEvent recently. Dynamically generating a canister for each individual event, so the event host need to pay for the canister and maintain the lifecycle on their own. Providing universal UI to management for hosts.

Jorgenbuilder — Yesterday at 9:05 AM ah, the universal ui changes my answer a bit, hahah. you could use that to mitigate some of the downsides of fragmenting the backend landscape, but would take some doing. going to continue my original reply as well 😛 Over all I think that option is a bit heavier, and I think it would make sense if we intended to permit more functionality on the ticket canister(s)? Downside is more upfront cost, and it fragments upkeep/upgrades in terms of cost and dev work. The "linked ledger" pattern I think provides a common infrastructure that is a bit easier to maintain.

orcsun — Yesterday at 9:08 AM I agree

Jorgenbuilder — Yesterday at 9:08 AM I see that either way is probably good for different things, and my primary bias will be toward simplicity if we can find it

[bytesun]

Sample Case for the alpha canister in a real world event (Saga legends pre sale in January or February.):

On ICEvent (https://znisf-eqaaa-aaaaj-aabta-cai.raw.ic0.app/):

1. Host post a "Saga legends pre sale" event
2. Host mints the event ticket collection and associate with the event.
3. Users register the event with native ICET token payment
4. System transfer a ticket to the user

On Saga pre-sale System(https://legends.saga.cards/):

5. Users buy Saga legends on sale day with ticket as proof

[bytesun]

• [x] choose NFT standard? EXT? #nonfungible
• [x] create github code repository

Ticket NFT Canister specific APIs:

• [x] setAdmin - application canister (e.g saga, icevent...)
• [x] setMinter - add an event host as minter with quota(ticket count), and metadata
• [x] _mintNFT - internal method to mint one NFT with default metadata if no metadata provide
• [x] mintBatchNFTs - mint multiple NFTs by calling _mintNFT to the event host with ticket number
• [x] getNFTsByMinter - retrieve all NFTs of the event host
• [x] transfer - allow application as spender to transfer the event host's NFT to user
• [ ] transaction support
• [ ] automatic generate NFT pic as default
• [ ] ticket verification
• [ ] burn ticket

Application modules:

• [x] wrap custom picture to metadata
• [x] make payment for minting NFT (quota)
• [x] mint ticket NFTs - mint all NFTs at once for the host with/without custom pictures
• [ ] stoic wallet integration
• [ ] plug wallet integration

[bytesun]

delegate asset storage : https://github.com/vansday/motoko-cdn

record file reference in token metadata :

type Metadata = {
      event_id: Nat;
      event_name: Text;
      event_date: Nat;
      host: Text;
      asset: Text;
    };

[jorgenbuilder]

A Note on Canister Architecture

Having worked quite extensively with CAP recently, their "hub and spoke" multi canister architecture is fresh in mind. In this pattern, a central "hub" canister coordinates all of the others, and a unique "spoke" canister is spawned as needed. In our case, a spoke could be created for each ticket project / token. This would resolve any concerns about a single canister approach eventually running out of memory. I think it's a safe assumption to say that a single ticket project would not exceed canister memory limitations.

---

Edit: if we are spawning multiple NFT canisters, getting them listed in DAB might be awkward. We may wish to create our own directory to integrate with wallets and dapps.

[jorgenbuilder]

delegate asset storage : https://github.com/vansday/motoko-cdn

I'm not sure we need such a scaling solution for what will be fairly limited set of assets.

[jorgenbuilder]

Sample Case for the alpha canister in a real world event (Saga legends pre sale in January or February.)

I have a slight concern that requiring the alpha test to go through an IC event integration is beyond scope of an MVP (I'm trying to keep things as lean as possible, many things to do.) Perhaps if we create the bare bones implementation, you could shepherd the ICEvent integration without requiring too much to change on my end?

[jorgenbuilder]

The problem of fake tickets and trust should be approached at some point.