Marketplace-able NFT interface

[kitty-kad]

This proposal is for a new marketplace-able interface for NFTs
It is largely to make it easier for projects to develop marketplace experiences around NFTs

Current Problems

1. Letting users find, buy and and select NFTs they own to sell from a specific collection is non-trivial. This is due to lack of methods for finding NFTs relating to a collection which are owned by someone, the NFTs they have one sale and NFTs everyone has on sale
2. Marmalade tightly couples interfaces and implementation details which would either prevent innovation or cause divergence of marketplace interfaces.
   Kadena already has NFTs using marketplaces which differ in implementation (i.e. Gallinas, Kadena Bulls, Lazy Apes, Kadena Komodos are non Marmalade and Babenas are on Marmalade) and it is unlikely we'll see more divergence in the future.

Non-Goals

1. Replace the Marmalade standard for implementing NFTs. This can work along-side Marmalade implementations.
2. Specify implementation details - this is a pure interface leaving it to users for implementation details

Design Considerations

1. Marmalade reduces the risk of marketplace monopolies and of them dictating how NFTs should sell. This is done by having a "generic" marketplace and letting the NFT creator have control of how sales should happen. In practice there has already been divergence with multiple ledgers being implemented.
   This proposal keeps the interactions on the NFT on purpose. This lets the NFTs selling/buying be marketplace agnostic and let the NFT specify how it wants transactions to occur and

Interface

This is the recommended interface for NFT projects to implement.

This is a bit rough, but conceptually it consists of the following methods
; Places an item for sale
put-id-for-sale 
; Lets someone buy an item
buy-id-on-sale
; List of all items on sale
get-all-on-sale
; List of all items on sale for a particular user
get-all-on-sale-for-owner
; List of all items owned by a particular user
get-all-owned-by-user

Benefits

1. It makes it easier to build marketplace Dapps for NFTs
2. It does not contradict Marmalade and can compliment it
3. It allows for innovations and changes to be done for how marketplaces should be implemented

Downsides

1. It is yet another interface
2. It is not opinionated on implementation, which may go against the intentions of the marmalade standard (though this is also mentioned in Benefits, depends on how you view it)

Disclaimers

For brevity and speed of discussion - event emissions have been ignored , but can / should be discussed if the proposal proceeds

[sirlensalot]

Since policies (token-policy-v1) make collections very easy, I suggest an interface functioning at the level of policies to identify collections and offer related functionality.

Note that in marmalade, tokens are not just 1-offs. So hardcoding things around "token owners" is problematic: a single token can have a maximum supply of say 5.0 with 0 precision meaning there are five fungible units of fractional ownership, thus having up to 5 owners. An ERC-721-style NFT is therefore supply 1.0, precision 0. You can see however that "enumerate all owners" rapidly becomes out of control if you have tokens with say 100 fractions.

But policies exist to simplify the situation by supporting specific use cases. Remember that marmalade.ledger.create-token specifies a policy irrevocably for a token. Thus N tokens sharing the same policy implicitly form a collection. (Note that create-token is not currently specified in any interface, which needs to be corrected).

Thus, the simplest collection implementation records all tokens added (captured via enforce-init). It could then support operations to list token IDs, etc. (Note this does not need select as the ids can be kept in a list in a single DB record.)

However, it's easy to have policies that manage multiple collections. Now operations simply take a collection-id to distinguish.

Finally, a collection can be only for 1-1s by enforcing supply of 1.0 and precision of 0, and therefore be enumerable: every token in a given collection has a distinct owner.

[kitty-kad]

Thanks fo the response!

suggest an interface functioning at the level of policies

Having this interface be implemented on policies make sense for marmalade based NFTs. However since there could be multiple collections - would it simplify things by having it implemented at the same level as poly-fungible-v2? (though the collection-id approach you mentioned later would address this)

You can see however that "enumerate all owners" rapidly becomes out of control

In this case - the proposed interface isn't to enumerate all owners, the only owner specific functions are get-all-on-sale-for-owner and get-all-owned-by-user. I'm not sure how I understand why this would be an issue even with fractional ownership.

operations simply take a collection-id to distinguish

Would the main change as a result of this be to add collection-id as an input to the methods in the interface specified above?

[optimadefidegen]

Great to see some activity here!

Providing clarity on these issues is essential to move towards developer adoption.

"Marmalade tightly couples interfaces and implementation details which would either prevent innovation or cause divergence of marketplace interfaces." This is a real problem @sirlensalot ! Divergence of marketplace interfaces will naturally occur if the standard is incomplete or lacking clarity. Do we have any idea how to prevent this divergence , when builders will naturally build?

I wholeheartedly support community engagement and continuing to build Marmalade in public while addressing its shortcomings. There is a reason this was posted December 2nd and there are less than a handful of live projects utilizing the standard. There has been too much propaganda and lauding Marmalade it in public posts. There has been not enough work improving clarity and addressing the problems limiting development velocity and user adoption.

It is very encouraging to see competent developers like Kitty assisting the Kadena team in these tough markets!

[Gh0stts0hg]

Hey beautiful discussion, to your answer

Thus, the simplest collection implementation records all tokens added (captured via enforce-init). It could then support operations to list token IDs, etc. (Note this does not need select as the ids can be kept in a list in a single DB record.)

However, it's easy to have policies that manage multiple collections. Now operations simply take a collection-id to distinguish.

But pushing organization to policy means it's harder for newbies to implement correctly, i think adding collection organization to ledger will make it easier for people to create NFTs off the boat.

It can be very simple : Optionally add registering under a collection, and have a single table that returns token list. NFTs not registered under collection will be global, you can use collection id in the token key similar to what babena did to index tokens. (& ofcourse this would enforce supply and precision on unique tokens created under collection)

(defschema collection
collection-id:string
tokens:list
max-unique-supply:
....others
)

Grouping by collection is fundamental NFT logic and don't see why ledger can't inherently support it, and policies can still support custom groupings/collections

1. it will make creating new project simpler and easier
2. it will give nfts marketplaces/dapps easy way to map tokens to collections, and collections to their respective policies still

(Sorry to hijack discussion alittle, but this could also make market-placeable/other interface easier to implement over collections)

[Gh0stts0hg]

Also policy could benefit from having enforce-withdraw incase it wants to track open sales per user

[Gh0stts0hg]

To track open sales for buyers/nfts :

Currently, the SALE escrow handles "timeout" through capabilities, by checking if we're within timeout, but does not pass to policy.

Having it at policy level lets policy track open sales per nft or user more easily as well, could we possibly have policy enforce-offer take timeout (Passed from offer on ledger)

[kitty-kad]

@Gh0stts0hg thanks for jumping into the discussion, good to see other people get involved :)

don't see why ledger can't inherently support it

One thing with having it at a ledger level, is then it could cause performance issues.
In general there was concerns raised on my other KIP about running select queries #24
For a collection, this shouldn't be too much of an issue, but for a ledger potentially storing millions of NFTs, it could be tricky.

could we possibly have policy enforce-offer take timeout

I think this could be good, but potentially a different KIP?

[sirlensalot]

Would the main change as a result of this be to add collection-id as an input to the methods in the interface specified above?

@kitty-kad yes maybe? The operations above don't have any arguments specified currently so it's hard to answer that question.

As for implementation, you can imagine a deftable collections{collection} that is keyed on collection-id, and each row has a list of the tokens managed in that collection, e.g. (defschema collection tokens:[string]).

However since there could be multiple collections - would it simplify things by having it implemented at the same level as poly-fungible-v2 (@kitty-kad )
But pushing organization to policy means it's harder for newbies to implement correctly (@Gh0stts0hg)

I don't agree that policies are newbie-hostile, if anything they reduce the amount of copy-paste required to launch a token. That's kind of the point: copy-pasting an entire ledger just to customize a few lines is madness. Just because Ethereum does it this way doesn't mean it's right or simple or good.

With the currently-deployed marmalade.ledger on chain 8 you can implement a POC of @kitty-kad's design as a policy in mainnet or testnet with zero risk to other tokens on the ledger.

Also policy could benefit from having enforce-withdraw incase it wants to track open sales per user

could we possibly have policy enforce-offer take timeout (Passed from offer on ledger)

Both great suggestions for a token-policy-v2 :)

yet another interface

This doesn't bother me, especially at the token policy level.

[pax-k]

This proposal is exactly what we've been talking today: lack of an interface that should provide these ^ useful methods, enabling marketplaces and wallets to read data in a predictable way. Take XWallet's UI/UX, or any other compatible wallet, for example: adding a new coin means typing the coin contract reference, then .get-balance() is called. It should be the same for NFTs: enter the contract reference, then .get-owned-tokens should return a list of all owned NFTs.

If the computational effort is too big (>150k gas), depending on table sizes, then it could be offloaded off-chain, by storing some of the data in traditional databases, but providing this information upon request in the form of Decentralized Identifiers / Verifiable Credentials.

I've been researching how to write and submit a new DID Method spec to W3C to integrate Kadena with DID/VC - I'll also open an issue for this so anyone could contribute

[kitty-kad]

@sirlensalot agree with most of what you said

One question

each row has a list of the tokens managed in that collection, e.g. (defschema collection tokens:[string])

Since each row is a collection, I'm wondering if the gas costs to write could be too high?
I'm assuming that adding a new NFT to the collection would require pulling the list of all the ids in the collection and appending one more entry to it.

Not sure how gas expensive this would be.

[kitty-kad]

@nzpopa thanks for sharing your thoughts and good to get more data-points on whether this is an issue or not :)

If the computational effort is too big

I don't think there would be much difference if DIDs are used over regular nft IDs. The data returned by the APIs are mainly IDs of nfts, so whether these are DIDs or normal IDs doesn't matter.

[sirlensalot]

Since each row is a collection, I'm wondering if the gas costs to write could be too high?

It's a valid concern. The cost will escalate with every token added, so this is only a solution for small collections.

This is why any kind of get-all-XXX is problematic though, and leads back to the idea that queries are best supported via an event db like chainweb-data.

Note that this is also what Ethereum dapps that need to scale have to do as well, using The Graph or etherscan. Blockchains and smart contracts are great for transactions/OLTP, but are simply not suitable for data warehousing/OLAP.

[sirlensalot]

adding a new coin means typing the coin contract reference, then .get-balance() is called. It should be the same for NFTs: enter the contract reference, then .get-owned-tokens should return a list of all owned NFTs.

get-balance retrieves a single decimal value, which scales well. get-owned-tokens will necessarily increase in cost as the number of tokens grows, so it does not scale past small collections, as discussed in the other comment.

[Gh0stts0hg]

Could we lower computation by indexing differently, data is cheaper than computation here i would assume given we're on kadena

Since each row is a collection, I'm wondering if the gas costs to write could be too high?

if we adjust @sirlensalot implm here from:

As for implementation, you can imagine a deftable collections{collection} that is keyed on collection-id, and each row has a list of the tokens managed in that collection, e.g. (defschema collection tokens:[string])

and instead index the tokens in a collections; you can store total tokens # (defschema collection total-unique-tokens:integer)

& Have a new table coll-token-index table has token-id for that index :
key = collectionid.index (defschema collection-token-index token-id:string)

Instead of "get all" you can "get by index"

Requires managing this new state, but that is a very short computation compared to a select on a large ledger. and really we store only id & index extra but this is still a duplicated ledger and you need to maintain it's state..

---

Same concept can apply to "NFT By account" For example, if you stored at policy/collection level an account table (defschema account total-tokens-owned:integer)

then stored account.index -> token id in a separate table (defschema account-tokenid-by-index total-id:string)

you could then get total number of NFTs an account owns in collection, and NFT by owner by index.

---

acc1 has 3 NFTs, so

account-ledger :
acc1-> {owned-tokens : 3, guard : keygojingle}

token-id-by-index :
acc1:0 {token-id : "t1" }
acc1:2 {token-id : "t2" }
acc1:3 {token-id : "t4" }