[LIP-7]: Allow metadata to be changed in a publication

[pradel]

Allow publication metadata to be changed while keeping a revision history of the changes by using ERC-7160 and ERC-4906.

I am opening this LIP as it's something that I would like to see the protocol support as many users have requested it. Open for discussion, would love to know your thoughts.

[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.

[EthWarrior]

This would definitely open to new interesting use-cases for developers building with Lens Protocol, including dynamic content.

[joshstevens19]

Interesting. Would it be enough to support it via Momoka or something like that to avoid another transaction to refresh it? Or would you like to see it baked into the protocol natively?

[pradel]

I guess Momoka could work, I am wondering if one would lose the ability to easily build custom indexers if it's on Momoka and not on-chain

[pradel]

Just discovered Arweave bundl mutable references, it seems like smth that could be supported by the indexer for data stored on arweave https://docs.irys.xyz/developer-docs/mutable-references in an easy way. It would still be the responsibility of the app to call the refresh metadata mutation to indicate that a new version fo the content is available.

Right now we can reference arweave links like this: ar://<id> I don't know if there is a consensus for mutable references but smth like ar://mutable/<id> could work as a generic spec.

[defispartan]

I think it would best for individual content URIs and applications to manage versioning instead of adding it to the core protocol. Having the contentURI be immutable at the protocol level is a nice assumption for apps because it allows them to make their own decisions about the immutability and refresh conditions for a particular URI.

Plus, Arweave Mutable references that you mention and also IPNS records can achieve a similar purpose of having a verifiable history.

[pradel]

@defispartan After spending more time looking into the problem, IPFS mutable references / IPNS records are only a partial solution. I agree that immutable contentURI at the protocol level is good and ultimately the decision should be done by the user when publishing (immutable vs mutable).

For the time being the only solution to properly handle accounts manager to edit the metadata of a post is to have your own server logic calling the Lens API to allow or not the content to be changed and store the content on a centralised URL (which is not a good solution imho).

There is an ongoing discussion in the Lens discord if you want to participate https://discord.com/channels/918178320682733648/1220670299863912448

[pradel]

@EthWarrior @joshstevens19 and @defispartan (tagging you as you showed interest in the LIP) updated the LIP with more details and a new idea to pin the content of the metadata to a desired revision in the smart contract, would love to hear your thoughts on this new approach.