Regarding Irys mutable references, it could be a good solution but it as a few drawbacks. First, it does not support Lens profile managers, as the content can only be updated by the same wallet. Second, if the user's wallet is compromised, the content could be changed at a later time by the attacker. The only possible "fix" would be for the user to hide the posts on his profile which is far from ideal as one could lose all the posts he has created since starting to use Lens.

That's some useful info, thanks @defispartan!

Have been thinking more about the immutable collect part you mentioned, and I currently see 2 solutions to this:

Option 1: what @cesare proposed, "Early collectors could have NFTs pointing to the metadata URI at the time of collect. So if the author updates the content URI for a publication, only subsequent collects will use the new URI.". I think this would be the easiest option to add to the protocol.

Option 2: The contract stores the revision changes on a string array instead of just storing the latest version string. When an update is made to the publication, the new metadata uri is pushed to that string array. By default calling tokenURI would always return the latest metadata uri. The collector can decide at any time to "pin" the metadata uri for the token he minted to any revision made by calling the pinTokenURI function. This would protect the collector from the metadata changing in the future and allow him to "freeze" the metadata to a specific revision. Updated the the LIP-7 proposal at github.com/lens-protocol/LIPs/pull/24 with more info and some pseudo solidity code. Would love to hear your thoughts on this!