Creating a custom Flow Contract that appears on Rarible.com

[figs999]

What are the required steps for making a custom contract appear on Rarible.com?
I have a contract deployed that should show up here on testnet, but it does not.
The contract has the same interface usage as "RaribleNFT.cdc", but with some modifications to the implementation.

Do I need to deploy my own marketplace contract in order to have the NFTs appear on Rarible.com?

It seems like there should be an interface that the contract needs to extend from that includes a way to get metadata for a specific NFT, as well as ownership information, from the base contract. Without this, the system probably cannot grab arbitrary NFTs as they are going to be stored on any number of accounts.

Additionally, there would need to be a way for the collection to have it's collection-level metadata set. Which I do not see currently a way to do. My collection does appear, but only shows address information here.

From what I've been able to figure through digging through the SDK source, I may have to make a PR that adds my collection to the SDK configs if I want it included? Is this the case?

Thanks!

[eduardstal]

We have asked the Flow team to reach out to you via this GitHub discussion.

[atapin]

Dear @figs999,

Thanks for your interest. Unfortunately, this is current limitation of Flow blockchain. One can not easily deploy a collection that would be instantly indexed by some marketplace. We are working on two things. The first thing is a simple workaround, similar to what guys from Blocto do – submission form for collections' authors. The second one is joint work with Dapper Labs on NFT and marketplace standard.

Would you be able to serve a set of simple endpoints according to OpenAPI spec, provided by us?

[figs999]

Web endpoints would likely not be a problem.

I would propose something like a method GetMetaByID(id:UInt64) that is a pub fun on the main contract. Have that as a contract interface that would allow your backend to query into anything that implements it.

[atapin]

good point. What would be the expected return type?

[figs999]

Exactly same as the GetMetadata function on the NFT itself.
This is what I have:
pub fun GetMetaDataFor(id: UInt64): {String:String}

For my NFTs on Flow if the data doesn't need to be immutable, I like to store all the metadata on the parent contract or in the parent contract's account storage, and then just provide each of the actual NFTs a way to get their metadata from it.

In the past I've made it so each NFT has a capability that let them access their metadata by their own ID. But considering this is going to be something that is needed by any website that wants to look up the NFTs by ID, it makes more sense just to have it as a contract level pub fun.

The benefits of having the metadata stored at contract level are two-fold, one is that the burden of the storage cost remains on the developers, making their NFTs a little more lightweight for collectors, and the other benefit is that if the metadata is stored centrally multiple NFTs can point at the same shared data for certain shared traits reducing burden on the chain's data storage overall.

Another bonus (or detriment depending on opinion) is that if the metadata is stored at the contract level, if it needs to be altered, the developer can do so more easily.

[figs999]

Take this as just my opinion for the solving this specific problem, and not as an opinion from the standards committee. Our discussions and proposals haven't even really hit on this problem.

[figs999]

@atapin What are the chances we can get a solution for this implemented in the next couple of weeks? We are going to be doing a drop soon and had been assuming we would have Rarible.com listing as an option.

[figs999]

@atapin Do you have more info on the endpoint? Or if the Contract level interface for metadata I proposed will work? I will need to have a solution available within a week or two for us to hit our launch target.

[eduardstal]

Is it okay to close this discussion @figs999? So we only keep this issue open: #173