Make storefront and all listing/offer type contracts expose in a standard way that they are a listing

[bjartek]

In order to make sense of the ever increasing premutations of listings/offers/swaps etc I propose that we introduce a new view called Listing and that said view is exposed from NFTStorefront collections, Offers and similar contracts.

This would make it trivial to know everything that a person has listed everywhere on flow since you can just use storage iteration, fetch everything that epoxe that. view and resolve it.

What would need to happen to make it so:

• we need to agree on the fields that it should contain, these should leave room for context or other vendor specific details, allthough said implementations could also be in aditional views for the same resolver i guess
• the listing collection would have to include Metadata.ViewResolver in its contracts

[joshuahannan]

So this would be a view that you'd want to include in the MetadataViews contract, or somewhere else? And it isn't something that an NFT or NFT collection exposes, right? Just that a marketplace collection exposes?

@satyamakgec @franklywatson for visibility

[alilloig]

As I understood it, it will be a view exposed by NFTStorefrontV2.Storefront or Offers.OpenOffers, the container resources for listings or offers

[bjartek]

I think this could live in another contract, so you have one for Storefront and OpenOffers it could be in that account. Because it is as you say it is not something you would expect a NFT to return.

Then the question is what fields shuold this contain?

• id: UInt64 (id of the sale item)
• listingType: String (the identifier of the listing contract)
• listingName: String (human readable name for this listing)
• ftType: String (the identifier of the type of the fungible token for this listing)
• ftAmount:UFix64 (the amount of ft that it is listed for/as)
• assetType:String(the identifier of the type of the asset that is listed)
• assetId: UInt64 (the id of the asset)
• seller: Address (the address of the seller)
• buyer: Address? (openOffers will have a buyer i presume if an offer is in a intermediare state)
• status: String (the status of this listing)
• expireOn: UFix64? (block height of when it expires if it does, or should this be timestamp?)
• context: {String:String} (a set of other fields that are vendor neutral, like .find can add the resolve find names here aso)

I have no problem changing ft or asset to something else.

[bjartek]

Not sure if it is worth it to add cuts/royalties here

[austinkline]

Glad this is being talked about! Thanks as always @bjartek for kicking this off 🙏

A few thoughts:

1. should id be uuid or listingID just to make it clear at a glance?
2. I'm assuming you went with assetType to be flexible against having storefront and offers possibilities? What about things that have multiple nfts or are things like Evaluate/Barter Yard swaps?
3. If you want to follow more general marketplace terms, you could swap seller and buyer for maker and taker where the maker is the initiator of a listing, and the taker is the one that fills it. For instance, a listing where an nft is put up for sale would have a maker set to the seller, and anyone who makes the purchase would be the taker. This also means you can express private listings (the taker is specified ahead of time)
4. One issue with royalties for offers is you don't necessarily know them until you fill it. Does it make more sense to split things into two different kinds of listing views? One that is NFT-centric, and one that is FT-centric? Where Storefronts are NFTs and Offers are FTs?

I'll have to think on some of this with respect to loans and rentals which are a whole other ballgame given they don't distribute all funds when they are filled so combining everything into one amount field could be misleading

[bjartek]

For me the main purpose of this view is 3 things:

0. getting all the listings I have in my account without having to know things beforehand
1. printing those listings to the user
2. know enough distringuishing information to either fulfill it myself or link to somewhere else

so for me I do not care about id/uuid/listingid as long as that is the id i can use to get this listing resource given that I know the path and the types.

Not really sure if swaps would fit here or if we could have a totally different view for swaps TBH.

[franklywatson]

Thanks @bjartek - great suggestion and look forward to having this added. On point (3) I agree with @austinkline since were already using buyer/seller terminology, and refer separately to the [listing/offer] facilitator account (which would typically be a marketplace).

On point (4) I also agree - it makes sense to me to have slightly different fields for a listing than for an offer

[Peixer]

@bjartek Sorry if it's a stupid question, what would be the difference of using storage iteration to fetch everything that exposes StorefrontPublic?

[bjartek]

@Peixer because then it will only for a single implementation at a single address. And people copy NFTStorefront, they modify it they do all sorts of things to it. And we cannot stop that.

Therefore a standard that exposes a independent view that can be used in all sale/offer/auction (get 1 nft for some ft) scenarios is what i propose.

[cybercent]

Hey @bjartek, I believe that the NFT and metadata-related smart contracts' current state is neither stable or final.

Adding a new view might not make much of an improvement as long as those are still being altered and there is another way to access the listings (using storage iteration).

As a side note, if this is only intended for NFTStorefront(V1, V2..), we are not concerned.
We do not intend to use any contracts created by Flow/Dapper until there is a clear separation between Flow and Dapper.

[joshuahannan]

okay, I understand this a little better now. I like Bjarte's proposal, agree with calling them maker and taker, and I don't think we need to include royalties or cuts in the view for this since I think that making it usable for storefront and offers is more important.

to @cybercent's point, besides what we have described in the v2 token standards improvements and the stable cadence changes, there won't be any large changes to any of our standard contracts. If we all come up with a standard view here, we'll do everything we can do keep supporting it with the community. The upgrades for stable cadence are mostly just changing syntax and interfaces to a contract's state, not the actually stored data managed by the contracts.

I understand the hesitation to approve a view like this if it isn't totally needed right now though, because there might be a better way to do it in the future that the community comes up with, so unless there is a critical need for this right now, it might make sense to hold off anyway since we can just use storage iteration for most cases.

[bjartek]

The problem with storage iteration here is that you have to know exactly what to look for. If somebody makes a new market contract, deploys their own version of storefront or anything suddenly everybody that want to show all your listing have to adapt.

This is the exact same reason the metadata standard was born for nfts. To be able to not have to know details but discover.

[bluesign]

I agree with @cybercent and @bjartek at the same time.

The problem with storage iteration here is that you have to know exactly what to look for. If somebody makes a new market contract, deploys their own version of storefront or anything suddenly everybody that want to show all your listing have to adapt.

Yeah big mess up there with NFTStorefront /NFTStorefrontV2 and now Offers. Where we could just make interface standard ( like NonFungibleToken ), anyway not much to say. I think related to "clear separation between Flow and Dapper." @cybercent mentioned.

But now it is what we have, and this view is necessary in my opinion in the current state as @bjartek suggested.

[joshuahannan]

yeah I think this view is totally necessary, but I'm just wondering if we want to approve something right away or give it some time.