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

[agafox]

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

[manolisliolios]

Hey @agafox,

Thanks for opening the issue and kickstarting this interesting discussion!

I'll separate the two topics but it's also possible we might end up realising that they shouldn't be treated differently.

1. Airdrops This is a scenario that we've also been thinking on how to address. We also have a WIP code sample here.

The idea here is that a creator, who has access to T by value, before any kiosk locks, can choose to transfer it to an address (airdrop). That'll force the recipient to either unbox it in their kiosk, or send it back to the creator. That could also be extended with built-in SDK support and possibly wallet support (so the unbox action can happen directly on the wallet for any Mail. Of course any dApp could also offer this as part of their functionality e.g in the account page you mention above). Wallet support will depend on ecosystem adoption.

Does this idea align with what you've been thinking, and if so, do you have any concerns or thoughts on making this better?

One drawback we have is the need for an extra Display, which, on the one hand gives full flexibility to the creator on how the gift-box looks on the recipient side, on the other hand forces the creator to do more work (creating a Mail<T> display).

One different approach on the wrapper would be to attach the item as a DOF to the wrapper, so we can have a single Display for Mail across the system, but this adds additional gas costs to the creator (as the creator creates both the wrapper and a dynamic field). This cost difference could be significant in large airdrop scenarios.

2. Transfers between kiosks This topic is a bit harder to address, because there doesn't seem to be an obvious way to allow this while also protecting the creator's rules. The core idea behind kiosk lock rule is to enforce some logic that protects the creator, either a royalty fee, a floor price (etc). If we try to skip these, then what differentiates a plain transfer from a sale, and what prevents anyone from building a fairly simple SC to process no royalty sales (masked as transfers)?

Can you help me identify some use cases / scenarios where it would make sense and allow us to brainstorm ideas on tackling them?

Looking forward to hearing your thoughts on both cases and thanks again for starting this discussion!

[agafox]

Hi @manolisliolios. Thank you for your reply!

Let me also reply to you in 2 separate topics:

1. As far as I understand the Mysten team vision in some close future there will be a single kiosk per wallet. With that said it will be very comfy to have a single Inbox per kiosk. This will make easier lifes of all the indexers on SUI. Plus it's kinda sound natural that you have a kiosk and this kiosk has an Inbox. So as you understand my personal vision is a bit different from using a Mail per every object you want to transfer.

2. Recently we have lots of negative feedback from collection creators launching on SUI. Especially from ones who are migrating from other chains. Usually they also bring their loyal audience which is used to certain freedom and mechanics. The most sensitive topic so far is transferring tokens between wallets. I can bet that every creator wants to give it as an option to their users and with lock rule enabled it's not possible by design. Just today the was a collection called Karrier Pigeons who decided to launch in kiosks but without lock rule. Yet they don't realize what chaos they will create on a secondary trading markets given how differently the biggest marketplaces are trading NFTs.

[agafox]

Now when I'm thinking more there might be a TranferPolicy which allows autorized by creayor contracts only take NFTs out of kiosks and send them to others KioskInbox. It's bad because it introduces a centralized pattern in decentralized ecosystem. But this will work for sure.

[obsidianbtc]

Users expect the capability to transfer their NFTs. Ideally, wallets should verify the minimum royalty required and notify the user to make the necessary payment. However, at present, attempting to transfer Mysten Kiosk NFTs results in an error from every wallet in the ecosystem.