useCreatePost metadata don't have option for attributes about lens-sdk

[moesalih]

@cesarenaldi these attributes are not only for collectible NFTs. These are very common and are being used for regular posts by many apps for many many different purposes, and they always get indexed and returned by the lens api, so the sdk should be on par.

Some examples of these attributes, just so you know the significance:

• almost every music post on lens by any app has an author attribute to show the artist name, which is used everywhere in the ui.
• lenstube requires the durationInSeconds attribute and image so those get added to every video post (lenster, orb, buttrfly, lenstube)
• handle attribute is also common and is added to every post, it's also required by lenstube.
• quotedPublicationId is how quoted posts are implemented in all lens apps. it was started by me on buttrfly, but became popular enough to be a standard attribute now on all apps.
• these are the standard ones, there are lots of non-standard attributes by different apps for non collectable purposes.

for buttrfly it's a critical requirement to be able to post these attributes.

I'm curious, as a workaround, can we just add these attributes to the data in the upload callback of the useCreatePost hook? so that those attributes are added to the metadata before it's uploaded?

[cesarenaldi]

Hey @moesalih thank you for the full rationale. If it wasn't clear in my previous message we are on the same page. attributes seems a nice thing to keep where apps can experiment... and we are keeping it... it's part of Publication Metadata v3.

This is the Lens SDK change we are planning for next week: https://github.com/lens-protocol/lens-sdk/pull/460/files#diff-7fbb18c6ba1639bc64227d8762258ed6dcba53582a8108952d4325499224a90dR83-R103

[cesarenaldi]

It should be easy to add. Yeah, can you please open another issue so it's easier for us to track?

I am going to ask you some questions about the use you make of name for non-collectable so it can inform the work we are doing with Lens v2 and Publication Metadata v3.

[moesalih]

@cesarenaldi #482

[cesarenaldi]

They are NFT marketplaces specific fields for when (and if) the publication will be collected... I know they have been used for other purposes but this was on us not making it extremely clear. Publication Metadata v3 solves the confusion by making a distinction between marketplace fields (NFT fields) and Lens fields.

The SDK React Hooks fixed this by making it obvious when they can be provided. As such they are under the collectable settings.

https://docs.lens.xyz/docs/create-first-post#collect-nft-metadata

[jsonpreet]

Agreed! But we are using attributes for other things for example

Upload Audio and set attributes as Author/Artist Name
or
Upload Video and set attributes for video duration, Author/Artist Name
or
Specific app set their own attributes for their use.

[cesarenaldi]

Ah I see. Sounds like we will need to provide you with an interim solution until Publication Metadata v3 will make these fields first class citizens.

I'll get back to you soon with something.

[cesarenaldi]

Are you also using image and imageMimeType yourself for publication that are not necessarily collectable?

[jsonpreet]

Yes sir, everyone using image and imageMimeType for media (Images, Videos)

[cesarenaldi]

Sure I totally understand these fields are in use and we are onboard with the idea of exposing them on the Lens SDK also for non-collectable publications (currently only for collectable via collect.metadata.attributes if the collect.type is a collectable policy).

I am keen to just highlight that from a protocol perspective the attributes is an unstructured bag of properties that does not guarantee interoperability across the ecosystem. It's usually a situation of having the first app (or more popular apps) arrive and dictate the new fields. Instead for this purpose we would like to have structured data and we introduced the LIP so the Lens builders community has a say as a whole.

I don't know if you had the opportunity to see the LIP-2 for Publication Metadata v3. Many of the fields you mentioned are already covered in a structured way there. With the rollout of Publication Metadata v3 we will need builders to do an effort and use the new fields.

As for attributes, it was meant to represent what you see on OpenSea as NFT traits. Its specification is the same as OpenSea Metadata Standard exactly to guarantee interoperability with NFT marketplaces ¹.

One thing I am noticing is that it could be interesting to leave open access to attributes (even after Publication Metadata v3 rollout) and treat it like an "incubator for new property needs". After some time properties could be formalized into the Publication Metadata standard via a community driven LIP.

Regarding the image and imageMediaType used for Media... this is a little problematic in the sense that these ARE the eventual NFT image (or as an "NFT cover image" in case of NFT leveraging animation_url).

Lens Publication media should use the media array. I am aware that some app used to consider image as a cover image for media publications. This could be a better use and if collectable, eventual collected NFT could have a great look on NFT Marketplaces.

As for an immediate workaround:

[...] as a workaround, can we just add these attributes to the data in the upload callback of the useCreatePost hook

This can work. Just bear in mind we will take care of this change in the Lens SDK as a matter of urgency, so it's up to you if you can wait few days or not.

In general hacking the upload function is something I would not recommend to keep around for too long. It will hinder your opportunity for a smoother migration to Lens v2 (which will include Publication Metadata v3 standard). The fact that Lens SDK consumers are shielded from the underlying Publication Metadata standard gives us the best opportunity for a smooth migration to Publication Metadata v3.

So if you are to patch it at the upload function level, the only thing I am strongly recommending, is that you adopt the Lens SDK fix once it comes out.

Footnotes

1. Please fill free to contribute to the mentioned Publication Metadata LIP if some of your app needs are not covered by the next v3 metadata standard. ↩

[cesarenaldi]

Here a proposal showing the impact on the shape of the arguments provided to useCreatePost (or useCreateComment, useCreateEncryptedPost, useEncryptedComment) callback: #460

[moesalih]

Thanks @cesarenaldi. Yeah I'm aware of LIP2 and agree that a lot of these standard attributes should be in the official metadata spec. But until v2 goes live we still need the sdk to support what's currently commonly being done.

---

I am keen to just highlight that from a protocol perspective the attributes is an unstructured bag of properties that does not guarantee interoperability across the ecosystem. It's usually a situation of having the first app (or more popular apps) arrive and dictate the new fields.

One thing I am noticing is that it could be interesting to leave open access to attributes (even after Publication Metadata v3 rollout) and treat it like an "incubator for new property needs". After some time properties could be formalized into the Publication Metadata standard via a community driven LIP.

Having this unstructured bag of attributes for any post regardless of collect status is incredibly important to the long term health of the Lens ecosystem. I cannot stress this enough. It's impossible for the Lens team or current app devs to foresee how metadata will be used in the future. And apps having the flexibility to add any attribute to experiment is essential.

I believe experimenting with these attributes in public and giving other apps the freedom to adopt what they feel is useful is a much better way to 'coordinate' than discussing LIPs in a github thread. Just like quotedPublicationId, if I couldn't just add that attribute for my own use, and then other apps adopting that based on community feedback into what is a standard now, then we still wouldn't have quoted posts on Lens, which would be a net negative.

In a truly open and permissionless protocol, we shouldnt have to talk to the Lens team or between each other for that experimentation. Organic evolution is better than central design, and the protocol can't evolve as fast as the apps can. Attributes that prove to be useful across many apps can then be discussed and adopted in the official spec, just like what happens now. So this is essential to keep moving forward. I will discuss this with Josh.

---

Really appreciate your quick response and attention to this. And we won't use the upload callback workaround for now, we can wait a few days for your update to the sdk to allow attributes. Thank you!!

[moesalih]

Thank you @cesarenaldi. The change looks good.

[cesarenaldi]

@jsonpreet and @moesalih you can find this now available under the latest next tag (along side all other fixes/improvements done in the last weeks).

pnpm install @lens-protocol/react-web@next

npm install @lens-protocol/react-web@next

yarn add @lens-protocol/react-web@next

Basically when creating post or comment you can add attributes and a new consolidated image property in the corresponding hook callback. See example below.

const { execute, isPending, error } = useCreatePost({ ... })

execute({
  content: '...',
  
  attributes: [
    {
      displayType: MetadataAttributeDisplayType.Date,
      value: new Date(),
      traitType: 'DOB'
    },
    {
      displayType: MetadataAttributeDisplayType.Number,
      value: 42,
      traitType: 'answer'
    },
    {
      displayType: MetadataAttributeDisplayType.String,
      value: 'bob',
      traitType: 'who'
    },
  ],
  image: {
    url: 'https://example.com/my-image.png',
    mimeType: ImageType.PNG
  }
})

Compared to the raw metadata spec the SDK (like for the existing collect.metadata property) is more developer friendly and takes care of serialization and correct placement in the final metadata structure.

Closing this issue. Feel free to re-open if you have any issue.

[moesalih]

hi @cesarenaldi , we just realized that we're also missing the name property in the metadata to allow us to set the title of the post or the name of the audio track. Can this be added quickly to the sdk please? Should i open another issue just for that specifically?