mystenlabs/apps

Home for applications created by MystenLabs

apps's Issues

Design and implement KioskInbox object to support NFT airdrops and potentialy transfers

Problem:

1. There are a lot of collections doing airdrops to their users. However, with the current implementation airdrops is a very poorly designed mechanic which might be done in 2 ways:

• Mint an NFT object lock it into kiosk and transfer this kiosk to a user. This one is obliviously kiosk anti-pattern because it creates ton of single NFT kiosks which will remain in the shared objects space until nobody knows when. Yet this is better than option number 2
• Mint an NFT object and transfer it to a user. Once it's done some marketplaces will start using their non-kiosk based contracts for trading and it will create a very bad trading UX. Also creators will lose a part of potential royalty income

Our team is thinking that adding a KioskInbox object might solve the issue. It could be designed in a way that everybody can drop an NFT object into the inbox but then user can claim it (if he wants) inside his kiosk. The mechanic is pretty natural because almost every NFT marketplace has Inbox section on the account page.

2. We assume with the KioskInbox object we can solve the second issue. Transfer of objects between kiosks. This issue is a big deal and a huge pain point for lots of collection creators and their users. Recently we launched Unchained Esports collection and users were furious of the fact they can't transfer NFTs freely and in an easy way. That's why our team came up with a hack and transfer of NFTs via escrow kiosk by purchasing NFTs for 0 coins.

We are thinking that adding KioskInbox and a corresponding TranferPolicy may solve this issue as well.

Why we are writing it here:

Our team would love to work with the Mysten team and add these improvements together. It's also very important to have them added as a part of Mysten apps cause it's the only one good way to spread it across the SUI ecosystem and turn into de facto standard

Using weather oracle as dependency facing conflicting versions of MoveStdlib

When I tried to add weather oracle as dependency, it requires the rev field to be exact 'a0e136a04'. However, even after I alter the rev, the compilation still failed in the latest sui client.

And does that mean that if my new project depends on any service, my sui-framework version has to be the same as the sui-framework version of that service? If so, this is crazy, since if multiple services are required as dependencies in my project, I cannot force them to be the same version.