Metadata v3 spec #101
Replies: 20 comments 30 replies
-
|
gm! This is a great initiative and will certainly lead to the most composable metadata standard. Here's one high level suggestion: Two overarching fields, "protocol" and "body": protocol identifies the smart contracts that this NFT was minted by and is interacting with, by default this field is "Lens", and body has all the meta-data fields and contents. This allows interoperability between Lens Protocol NFTs and other NFTs minted by external smart contracts. These NFTs may have fields that are required by their domain application for custom logic, and are unnecessary to include in the general Lens protocol metadata standard. I will also follow up with a proposal for music/media NFT meta-data fields. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, this is too big of a breaking change to roll out with the new spec; it would also mean it would be out of spec with ERC721 and not show on the likes of opensea and others. I like what you are getting on, though. Are you thinking of being able to construct a blockchain transaction event? like "I just brought this NFT"..? |
Beta Was this translation helpful? Give feedback.
-
|
As a Reference:
interface PublicationMetadataMedia {
item: Url;
/**
* This is the mime type of media
*/
type?: MimeType | null;
/**
* The alt tags for accessibility
*/
altTag?: string | null;
/**
* The cover for any video or audio you attached
*/
cover?: string | null;
}
enum PublicationMetadataVersions {
one = '1.0.0',
// please use metadata v2 when doing anything! v1 is supported but discontinued.
two = '2.0.0'
}
enum PublicationMetadataDisplayType {
number = 'number',
string = 'string',
date = 'date',
}
interface PublicationMetadataAttribute {
displayType?: MetadataDisplayType | undefined | null;
traitType?: string | undefined | null;
value: string;
}
enum PublicationContentWarning {
NSFW = 'NSFW',
SENSITIVE = 'SENSITIVE',
SPOILER = 'SPOILER',
}
enum PublicationMainFocus {
VIDEO = 'VIDEO',
IMAGE = 'IMAGE',
ARTICLE = 'ARTICLE',
TEXT_ONLY = 'TEXT_ONLY',
AUDIO = 'AUDIO',
LINK = 'LINK',
EMBED = 'EMBED',
}
interface Metadata {
/**
* The metadata version.
*/
version: PublicationMetadataVersions;
/**
* The metadata lens_id can be anything but if your uploading to ipfs
* you will want it to be random.. using uuid could be an option!
*/
metadata_id: string;
/**
* A human-readable description of the item.
*/
description?: Markdown | undefined | null;
/**
* The content of a publication. If this is blank `media` must be defined or its out of spec.
*/
content?: Markdown | undefined | null;
/**
* IOS 639-1 language code aka en or it and ISO 3166-1 alpha-2 region code aka US or IT aka en-US or it-IT
* Full spec > https://tools.ietf.org/search/bcp47
*/
locale: Locale;
/**
* Ability to tag your publication
*/
tags?: string[] | undefined | null;
/**
* Ability to add a content warning
*/
contentWarning?: PublicationContentWarning | undefined | null;
/**
* Main content focus that for this publication
*/
mainContentFocus: PublicationMainFocus;
/**
* This is the URL that will appear below the asset's image on OpenSea and others etc
* and will allow users to leave OpenSea and view the item on the site.
*/
external_url?: Url | undefined | null;
/**
* Name of the item.
*/
name: string;
/**
* These are the attributes for the item, which will show up on the OpenSea and others NFT trading websites on the
item.
*/
attributes?: PublicationMetadataAttribute[] | undefined | null;
/**
* legacy to support OpenSea will store any NFT image here.
*/
image?: Url | undefined | null;
/**
* This is the mime type of image. This is used if you uploading more advanced cover images
* as sometimes IPFS does not emit the content header so this solves the pr
*/
imageMimeType?: MimeType | undefined | null;
/**
* This is lens supported attached media items to the publication
*/
media?: PublicationMetadataMedia[] | undefined | null;
/**
* In spec for OpenSea and other providers - also used when using EMBED main publication focus
* A URL to a multi-media attachment for the item. The file extensions GLTF, GLB, WEBM, MP4, M4V, OGV,
* and OGG are supported, along with the audio-only extensions MP3, WAV, and OGA.
* Animation_url also supports HTML pages, allowing you to build rich experiences and interactive NFTs using JavaScript canvas,
* WebGL, and more. Scripts and relative paths within the HTML page are now supported. However, access to browser extensions is not supported.
*/
animation_url?: Url | undefined | null;
/**
* This is the appId the content belongs to
*/
appId?: AppId | undefined | null;
} |
Beta Was this translation helpful? Give feedback.
-
|
I want to have the ability to link or embed full length articles with a summary in Thoughts on how to do this current v2.If we wanted to have html or json context payload, was the idea to sent If not how do you see us loading content in a way that can be server side rendered. I know Markdown is an acceptable for
ConclusionI think having a more defined way to have a summary in lens and a way to either link or embed full length articles would be great. |
Beta Was this translation helpful? Give feedback.
-
|
A way to achieve this in v2 is to:
Although medias could in theory be used for HTML content, I would personally refrain from using HTML as data exchange format. Many FE will be aware of the risk associated with rendering HTML within their applications and they are likely to sandbox it or omit it. The reason Maybe worth exploring if there are other data exchange formats with similar (a more) capabilities to Markdown and entertain the idea of using those. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Also embed are supported in v2, although the "full length" article won't be part of the metadata JSON but is an external resource. Have look at |
Beta Was this translation helpful? Give feedback.
-
|
thanks i'll look at this as i try things out. I appreciate it |
Beta Was this translation helpful? Give feedback.
-
|
already in v2 feature set |
Beta Was this translation helpful? Give feedback.
-
|
I propose to add also "license" details into the metadata. Lens Protocol enables ownership of your social graph and public content directly to your audience. Following this idea, would be suitable if the profile owners (or applications for them) could submit the license type of their content. Hence someone who posts could submit CCO or reserve copyright. Would be also good to have a standard list of commonly used rights for consistency. |
Beta Was this translation helpful? Give feedback.
-
|
strongly support adding a license field, would propose initial support be an enum of common licenses Initial list would include: CC 4.0 licenses (+ cc0), a16z's CBE licenses. Would love to hear if there are any other specific ones we should include in initial enum for v3. CC: https://creativecommons.org/about/cclicenses/ |
Beta Was this translation helpful? Give feedback.
-
|
yes license will be part of metadata v3 for sure |
Beta Was this translation helpful? Give feedback.
-
|
I propose we support full music metadata for audio metadata. Will help encourage adoption of music nfts in the Lens ecosystem. 💿📻
Some example fields:
|
Beta Was this translation helpful? Give feedback.
-
|
decent team can support on implementation, etc. if group elects to adopt |
Beta Was this translation helpful? Give feedback.
-
Another point I came to realize w. the Ooh La La team: |
Beta Was this translation helpful? Give feedback.
-
|
Interesting! Given that a single Lens Publication metadata can hold references to multiple audio files via the Thinking out loud, should type PublicationMetadataMedia = Audio | Video | Image | ...so that audio specific fields can be scoped under I can also see there might be some overlap with |
Beta Was this translation helpful? Give feedback.
-
|
That approach makes sense to me! @SweetmanTech, any thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
out of all these fields have you got 5-6 which are the most important? |
Beta Was this translation helpful? Give feedback.
-
|
gm! I just wanted to expand on the @haithamelmengad's high-level concern, and provide some feedback. While designing API or a standard schema, it's important to keep abstraction at the right level so the provider-specific info doesn't creep into the container itself. While it's cool to inject multiple domain-specific fields into the general field set, we should avoid including full schemas (e.g. Catalog Metadata) because it might be inconvenient/incompatible for other external providers (e.g. SoundXYZ?). The next question is, if we don't include full schema, at least we could include some common subset of fields, like proposed above #101 (comment) right? Well, in practice it's not always that simple to find common fields and don't miss any. The way how it could be done in general, the metadata must have a field that keeps domain-specific metadata, that can have arbitrary schema and a protocol identifier. In this metadata, various protocols (Catalog, Sound XYZ, Stems, etc) could attach their own platform-specific schemas. Even versioned (e.g.: Lens Metadata V3 contains a provider-specific Catalog_V2 schema metadata field). Various aggregators and indexers (e.g. Lenser) could then independently adopt and support particular provider's metadata and implement the mapping of relevant fields into their own internal representation. TL;DR: finding common fields and agreeing upon format is hard and tedious, let's abstract provider-specific details so Lens Metadata v3 is not bloated with fields that are equally suboptimal for all users on the market. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree with this a lot, even though I asked for 5-6 of the most important ones. The main issue you have with this is filtering. If it's such a dynamic nature, this brings complex searching. It also hurts the type system. With graphql you rely on strongly typed properties, and in this case, it has to be fully dynamic. We have to think about this a bit more. Right now, they can do that outside of our spec, but a common object name at least gives the ability for people who use it to agree on where to fetch it from. |
Beta Was this translation helpful? Give feedback.
-
|
Not thought-through so leaving here just as a FYI. Had a chat with qingisdead.lens about adding metadata to describe (optional) 'richer relationships' from a few weeks back: https://lenster.xyz/posts/0x0522-0x0149 I think I was thinking this could help jumpstart communities within Lens. (Similar theme then to supporting Groups DMs (for Followers), but not metadata related: https://lenster.xyz/posts/0x242d-0x0138.) At the top of that thread, you can also see qingisdead predicting a post 'type' metadata might appear for Lens: https://lenster.xyz/posts/0x0522-0x0148 |
Beta Was this translation helpful? Give feedback.
-
|
What would be in the type of post type? We have mainPublicationFocus already is that not enough? in terms of making the describe object can you share some examples in how you would think it should look? |
Beta Was this translation helpful? Give feedback.
-
|
For audio content this post got me thinking that having lyrics for audio metadata would be epic https://lenster.xyz/posts/0x013c1c-0xed but alos for video could be interesting to credit authors, producers, cast etc |
Beta Was this translation helpful? Give feedback.
-
|
I would say lyrics would just be a pointer to another file mainly because if it were dumped in the metadata itself, the storage cost for people would be huge + reading it. But do like the idea a lot. Credits, authors, producers, and casts are great ideas as well. |
Beta Was this translation helpful? Give feedback.
-
|
@joshstevens19 I think it would be good for authors to classify their posts and change their metadata after the fact. This is to make sure immutable posts can be redacted or marked falsified by the author who made the post. If an author marks a post this way. All the reposts and collections should reflect this meta data. I think this will help as a tool to rectify misinformation and allow authors to redact information without deleting posts. We should have a human system that forgives mistakes. the metadata field should include date stamps and series of statuses. It would help with information verification proofs that balaji talked about.
|
Beta Was this translation helpful? Give feedback.
-
Looks more like indexer-side change rather than on-chain. So maybe there is a room for standardised indexer/ anti-spam filter metadata? Currently the spammy comments already have this flag, but looks like there could be more marks than just spam. |
Beta Was this translation helpful? Give feedback.
-
|
I was think if the metadata represents something from the author of the post. Especially when it comes to veracity, it should be on chain. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
So you should post a centralised link, and we should expose a |
Beta Was this translation helpful? Give feedback.
-
|
A field for location in metadata would help use lens for different purposes.
|
Beta Was this translation helpful? Give feedback.
-
|
Amazing idea! We should 100% add location. Do you have any thoughts on the format of this? The geolocation API tries to set a standard but |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys this is all amazing work we will be picking this up early Jan to finalise it with everyone please share as many ideas as you have before that period! |
Beta Was this translation helpful? Give feedback.
-
|
A thought about PublicationMainFocus. It would be good to have types for streaming (like decentralized twitch) and audio (Twitter spaces / clubhouse) |
Beta Was this translation helpful? Give feedback.
-
|
Interesting, how do you see this working from a publication perspective? Is this like a channel for multiple streaming session or one of? |
Beta Was this translation helpful? Give feedback.
-
|
This to me is a level further down like "PLATFORM": "TWITCH" for example.. |
Beta Was this translation helpful? Give feedback.
-
|
gm! Proposing an idea of adding LIVESTREAM in the PublicationMainFocus @cesarenaldi @joshstevens19 @ShravanSunder I would imagine that each livestream would be its own publication. We are currently working on adding livestreaming to our platform (dragverse.io) and envision using Livepeer's streaming capabilities to work with Lens. |
Beta Was this translation helpful? Give feedback.
-
|
I’m actually writing up a draft proposal this week and it’s already in it will share with builders this week for thoughts |
Beta Was this translation helpful? Give feedback.
-
|
gm! Proposing an idea of adding Difficulties:
Solution: Adding a If so, we can remove the dependency of appId for bytes and can run with a single Hit us with feedback. |
Beta Was this translation helpful? Give feedback.
-
|
amazing idea, what is classed as "short"? and would we expect the API to validate it within a short period? say a bad actor posts a 2 hour video with "SHORT_VIDEO" |
Beta Was this translation helpful? Give feedback.
-
|
On average, a maximum of 2mins can be considered as SHORT, VOD services also provide mp4 streaming for videos (< 2mins) with faster load times instead of HLS streams. In the backend, we can validate this effectively. (ofc frontends also should validate this) |
Beta Was this translation helpful? Give feedback.
-
|
Hi Everyone, I propose adding Media Size (for images) under
Difficulties:
Solution: I got some feedback from users related to this issue. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
We are about to add a dynamic sizing ability to the publication images. This will allow you to set whatever size you wish for it to be resized. With this, do you still see the need to have the size properties on this? The main thing here is people can and will lie, and trying to do it automatically tends always to be the best bet. |
Beta Was this translation helpful? Give feedback.
-
It's better to add dynamic size of image in api. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @joshstevens19 is this appropriate thread to request customizable NFT image rendering of simple text post COLLECT?
|
Beta Was this translation helpful? Give feedback.
-
ProposalI'd like to propose establishing a standard for identifying the URL in a post with
The The problemWhen creating a publication with I'm working on Focalize, a browser extension for Lens that allows you to quickly share the URL of the tab you're currently on. It uses open graph meta tags to pre-populate the body. Here's an example of when it goes wrong, sharing from YouTube:
When viewing this post on Lenster it will appear that the focus is the shoprobuilder.com link and not the YouTube one. I can pre-populate the link at the top of the content but this is unnatural and still error prone when edits are made. Example use caseI have an idea for a Focalize feature where the extension automatically looks for posts shared about the webpage you're currently on. Imagine reading something on Medium and getting an unobtrusive notification telling you "This article is being discussed in 3 posts on Lens". Note this was previously an issue at #121 but I've closed that and moved it here. |
Beta Was this translation helpful? Give feedback.
-
|
A note on the |
Beta Was this translation helpful? Give feedback.
-
Yes exactly. Many Lens clients currently set the |
Beta Was this translation helpful? Give feedback.
-
|
Proposing also to add Location Anchors into the metadata. People don't necessarily have one location but they might have many locations they visit and would want to be more connected with the content or users from that area. Location Anchors would allow to capture locations but also add multiple. Example: London, NYC, SF, Hong Kong Would mean that whoever is building algorithms such as content recommendation or who-to-follow algorithms, you would be able to serve more related users or content to the users. |
Beta Was this translation helpful? Give feedback.
-
|
gm gm! I propose adding a new boolean parameter called |
Beta Was this translation helpful? Give feedback.
-
|
How about adding an identifier for a Collection of Collects. I know normally on ETH this is based on contracts. But it can also be metadata based. We did such a thing on DeSo together with @iPaulPro. Think about adding collectionId, collectionName, collectionEdition (001 etc) collectionDescription. It could be 100% attributes (field) or become part of Lens metadata spec. Any thought about that? Or is there something else already? We would support this on collectz.xyz |
Beta Was this translation helpful? Give feedback.
-
|
I would love to see support for collections. I believe the most important thing needed for proper collection support is using the Token ID in the metadata path to allow for ID-specific metadata. So if I mark a Collect with I'm not sure how feasible this is, given the current structure of the protocol, but without id-based attributes I'm not sure how a collection would work. |
Beta Was this translation helpful? Give feedback.
-
|
Moved to a proper LIP > lens-protocol/LIPs#5 |
Beta Was this translation helpful? Give feedback.
-
gm All! Based on ecosystem feedback we are going to be beginning the process for creating the next version of the metadata standard: Metadata V3! Just like V2, we hope to have the proposal drafted with developers from around the community, including all of you. We are hoping to target release for late nov/early december.
We have heard a lot of requests for support for feature flags, licenses, music support features and more!
Please drop any idea you have on metadata V3 and we can all discuss. With this we can then create a final draft of what is in it and what is not!
Beta Was this translation helpful? Give feedback.
All reactions