[LIP-17] make lens collects great

[punkess]

• title: make lens collects great
• description: enable creators to create posts on lens that result in NFTs appealing to secondary market place customers.
• author: @lens/punkess (inspired by @lens/carstenpoetter @lens/chaoticmonk @lens/ryanfox )
• status: Draft
• type: Protocol
• created: 2024-03-08

[height]

Link Height tasks by mentioning a task ID in the pull request title or commit messages, or description and comments with the keyword link (e.g. "Link T-123").

💡Tip: You can also use "Close T-X" to automatically close a task when the pull request is merged.

[cesarenaldi]

Unless I am missing something this seems a case under-utilized Lens Publication Metadata Standard.

I believe all fields you mentioned are encompassed in the existing metadata spec: attributes, description, etc.

Original LIP: #5

[iPaulPro]

Unless I am missing something this seems a case under-utilized Lens Publication Metadata Standard.

I believe all fields you mentioned are encompassed in the existing metadata spec: attributes, description, etc.

Original LIP: #5

Agreed this is already supported and an issue of app support. However, I believe the main issue with the current implementation is that OpenSea views all Collect NFTs as spam. Perhaps this is because all the contracts are deployed by the same address?

Would it be possible to allow the user to name the actual token, and then transfer ownership to the author after deployment? Perhaps this would require a new publication type, like DEPLOY, and it could allow the user to pay the gas for eagerly deploying the collect NFT contract, while specifying the metadata, rather than lazy deploying on the first collect action.

Part of me thinks that with Open Actions and Frames, we should start thinking about Lens Collects as fundamentally different from general NFTs, and simply support embedded mint actions for proper NFTs.

[kyp1994]

less gas

[iPaulPro]

Here's an example of a Lens Collect with marketplace metadata:

https://opensea.io/assets/matic/0xaff6e502c0c6bdbe42ffc7ecd8c4ddb624342fc6/14

There are a two main issues with this listing, from my perspective:

1. Most importantly, the owner of the collection is listed as poaplover.eth, instead of the author of the publication (me). This is because poaplover.eth was the first to collect, and the contract is lazy-deployed upon first collect. If I was the owner, I would be able to change the display title of the collection, as well as set royalty rates. In fact, poaplover.eth would receive 10% royalty on any secondary Open Sea sale, which doesn't make much sense.
2. "This collection has no description yet." The description of the collection should probably be the publication content, perhaps including a Lens Share link.

I believe just these two changes would go a long way in improving the quality and capability of Collect NFTs.

[cesarenaldi]

@iPaulPro regarding point 1, what you are raising are very interesting implications of lazy deployed collect NFT contract. I guess the only way would be to deploy the collect NFT contract in behalf of the publication author?

Regarding point 2, to me, it seems an app choice to decide what goes into the description field. It really depends on the user's intents, app UX, and publication content that only the originating app can properly understand (or let the user have full control over these marketplace params).

The use of Lens Share link, which I think is a really good idea, is also interesting. It could apply to external_url field too. It's a little bit of an chicken-egg problem to figure out the publication ID to put in the metadata when the publication is not published yet, but it's a solved problem (see predictNextOnChainPublicationId helper for token gated conditions).

[iPaulPro]

Regarding point 2, to me, it seems an app choice to decide what goes into the description field. It really depends on the user's intents, app UX, and publication content that only the originating app can properly understand (or let the user have full control over these marketplace params).

I'm talking about the Collection description, not the NFT description.

[iPaulPro]

@cesarenaldi Or maybe the collection description is just Open Sea metadata? If so, it would be resolved by issue #1, since you'd be able to set it as the owner.

[defispartan]

I support making lens collects great!

Based on the discussions it seems like owner address (set at protocol level) and metadata (set by applications or potentially the owner) are two things that could potentially be changed. I would be curios to hear @donosonaumczuk @vicnaum thoughts about the owner part specifically, is it possible to modify the collect NFT owner to be the publication creator?

[jamesfinnerty]

It's important to also consider how Lens Collects are displayed in mobile wallets and other blockchain aggregator apps, not just on marketplaces. Most of the time I view my NFTs on apps like Zerion, Coinbase Wallet, Family, Rainbow, Interface, Firefly, etc. Each of these apps have different ways of displaying Lens Collects. Some show only a select few, sometimes the NFT appears but without any image, and most often they don't show up at all.

If something can be done at the contract level I think it would be important to consider how users are viewing NFTs on mobile wallets and apps - not just on marketplaces like OpenSea (tbh, I almost never go there to view my NFTs).

Lens content needs to be designed to travel outside of the Lens ecosystem and exist on a variety of platforms (and blockchains). What I would LOVE to see on Lens is the ability to build collections that are attributed properly to the CREATOR with metadata that accurately displays the title of works, descriptions, media file tags, etc. Then to see those collections appear on marketplaces, blockchain aggregators, inside wallets, in Farcaster frames, etc.

A really simple first step that Lens front-ends can implement is to simply include a link to the contract address for collectible posts. I can’t tell you how many times I have gone down the rabbit hole trying to find an NFT I minted on Lens on polygonscan.com - not to mention having to keep track of early posts using excel spreadsheets when I wanted to airdrop my collectors. 😖

[donosonaumczuk]

Based on the discussions it seems like owner address (set at protocol level) and metadata (set by applications or potentially the owner) are two things that could potentially be changed. I would be curios to hear @donosonaumczuk @vicnaum thoughts about the owner part specifically, is it possible to modify the collect NFT owner to be the publication creator?

This can be done for Collect NFT collections that haven't been created yet. So, basically, we upgrade the protocol to use a different Collect NFT that allows to set an owner (let's say, the owner of the profile author), and since then all publications that are collected for the first time (i.e. haven't been collected yet) will have the new Collect NFT collection type.

We cannot apply this change retroactively to old Collect NFT collections that have been already created.

I am not sure if all marketplaces allows the owner (Ownable pattern) to edit things, or if they only allow the deployer of the collection (in this case, that would be the Lens' CollectPublicationAction contract).

[vicnaum]

Lens content needs to be designed to travel outside of the Lens ecosystem and exist on a variety of platforms (and blockchains). What I would LOVE to see on Lens is the ability to build collections that are attributed properly to the CREATOR with metadata that accurately displays the title of works, descriptions, media file tags, etc. Then to see those collections appear on marketplaces, blockchain aggregators, inside wallets, in Farcaster frames, etc.

I think Lens Collects intrinsically just collects the copy of the Lens post - it's not supposed to be used as NFT drops, etc. To address this specific case (i.e. creating proper NFT drops with all the media tags, etc, etc) we've created Open Actions, so somebody who wants to properly drop an NFT mint - should use some NFT Mint OpenAction (like we were developing the SeaDrop OpenAction but we didn't release it yet).
Many apps and devs are actively contributing to the Lens ecosystem as Open Actions are permissionless now.

[iPaulPro]

Lens content needs to be designed to travel outside of the Lens ecosystem and exist on a variety of platforms (and blockchains). What I would LOVE to see on Lens is the ability to build collections that are attributed properly to the CREATOR with metadata that accurately displays the title of works, descriptions, media file tags, etc. Then to see those collections appear on marketplaces, blockchain aggregators, inside wallets, in Farcaster frames, etc.

I think Lens Collects intrinsically just collects the copy of the Lens post - it's not supposed to be used as NFT drops, etc. To address this specific case (i.e. creating proper NFT drops with all the media tags, etc, etc) we've created Open Actions, so somebody who wants to properly drop an NFT mint - should use some NFT Mint OpenAction (like we were developing the SeaDrop OpenAction but we didn't release it yet). Many apps and devs are actively contributing to the Lens ecosystem as Open Actions are permissionless now.

Lens has always supported full marketplace metadata for compatibility with the wider ecosystem, which is the right move, IMO. I think "simply copy the Lens post" is a very shallow view of what Lens Colllectibles can (and are trying to) be, and actually makes them mostly uninteresting. There's a lot of friction with getting apps to adopt new Open Actions and users to set allowances for every token every time a new Action launches. It seems like there may be small changes possible to make Lens CollectNFT far more powerful and that sounds like a far better solution than "build you own".

[jamesfinnerty]

Lens content needs to be designed to travel outside of the Lens ecosystem and exist on a variety of platforms (and blockchains). What I would LOVE to see on Lens is the ability to build collections that are attributed properly to the CREATOR with metadata that accurately displays the title of works, descriptions, media file tags, etc. Then to see those collections appear on marketplaces, blockchain aggregators, inside wallets, in Farcaster frames, etc.

I think Lens Collects intrinsically just collects the copy of the Lens post - it's not supposed to be used as NFT drops, etc. To address this specific case (i.e. creating proper NFT drops with all the media tags, etc, etc) we've created Open Actions, so somebody who wants to properly drop an NFT mint - should use some NFT Mint OpenAction (like we were developing the SeaDrop OpenAction but we didn't release it yet).

Many apps and devs are actively contributing to the Lens ecosystem as Open Actions are permissionless now.

I can't speak for all creators, but personally when I post music on Lens I consider it an NFT drop in the sense that it is a blockchain transaction for a token that someone is paying to collect.

Open Actions that support minting posts from external contracts simply don't exist rn (aside from the Zora integration on Hey). Even prior to receiving my Lens handle, I was excited at the prospect of having collectors mint from my feed using a Manifold contract. But that's not possible without an open action built to do this (and it might never happen because it relies on having access to the Manifold API and contract data).

Waiting for an NFT Mint OpenAction to be created doesn't solve the current situation with Lens collects - in particular how metadata and media files are aggregated and handled by third-party platforms, and displayed on dApps and mobile front-ends outside of the Lens ecosystem.

Even after these open actions become more widely available, Lens users may still choose to mint using the Lens collect module / contract. So it's important to solve this early at the protocol level, because at this stage there are no benchmarks or standards for the way Lens Collects (mints) appear in a collectors wallet or marketplace account.