Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: MAX_URI_LENGTH to allow completely on-chain metadata. #356

Open
akutruff opened this issue Apr 5, 2022 · 0 comments
Open

[Feature]: MAX_URI_LENGTH to allow completely on-chain metadata. #356

akutruff opened this issue Apr 5, 2022 · 0 comments
Labels
enhancement New feature or request investigate

Comments

@akutruff
Copy link

akutruff commented Apr 5, 2022

Which package is this feature request for?

token-metadata

Feature

Right now the token metadata length is limited to 200 characters. There are many use cases where a the json metadata could be a data URI that's stored entirely on-chain with the image field of the meta also being set to a data uri that contains a fully encoded and simple SVG. The ETH world has already started allowing this and it greatly decreases the burden of creating dynamic on-chain NFTS.

A very simple use case - a game wants to be able to allow a user to mint an in-game item that has a unique name and a unique image for that NFT. Right now, the game must store the metadata on a separate server or on arweave a-priori.

Phantom already supports SVG's encocded as data uri's, but the metaplex uri length is too limiting to store the actual json

Standard Change?

No

Ideal solution or implementation

On-chain program allows a much more permissive url length. Naive and ideal solution - The url length constants in the program are simply removed.

Alternative solutions or implementations

If there are storage size concerns for wallet-fetching, then you could also add a metadata_account field that is used instead of a json url. That way, a wallet can fetch the program accounts, and then start loading metadata by url as they currently do. For on-chain metadata, the wallet will instead load those the metadata_accounts accounts. There's trade-offs either way.

Other context

A blog post describing historical approaches to storing on-chain metadata and SVG's in the ETH world.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request investigate
Projects
None yet
Development

No branches or pull requests

2 participants