-
Notifications
You must be signed in to change notification settings - Fork 159
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
Add flip for fungible tokens metadata #1087
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
I could really use some help with the Motivation and User Benefit writing! |
I'm still missing any related issues, and will much appreciate a look at Objective, Motivation & User Benefit, haven't feel specially litterateur with those |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good start so far! I just have a few comments
|
||
## Objective | ||
|
||
This proposal, in a similar fashion as the NFT Metadata, will make possible to create generic solutions that will interoperate through views rather than through hard-coded types. This will allow better interoperability between fungible tokens and external applications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably include an embedded link to the NFT metadata flip and standard here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make sure to address this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bazillion thanks for remembering this, there was a bunch of great suggestions made by @turbolent, including this point, that I thought I had merged but actually lost track of them at some commit.
|
||
## User Benefit | ||
|
||
The creation of a Metadata standard for fungible tokens will bring two major user benefits, discoverability and interoperability. It will make way easier to any FT to be presented on any app that would want to feature several FT and also will ease how those FT can be used by an user programmatically. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The creation of a Metadata standard for fungible tokens will bring two major user benefits, discoverability and interoperability. It will make way easier to any FT to be presented on any app that would want to feature several FT and also will ease how those FT can be used by an user programmatically. | |
The creation of a Metadata standard for fungible tokens will bring two major user benefits, discoverability and interoperability. It will make it way easier for any FT to be presented on any app that would want to feature several FT and also will ease how those FT can be used by a user programmatically. |
} | ||
``` | ||
|
||
In order to be able to use the `FTDisplay` we will need to re-use or re-implement (depending on if this ends up being part of the original `MetadataViews.cdc` contract or having its own contract) the following views: `ExternalURL`, `File`, `HTTPFile`, `IPFSFile`, `Media` and `Medias`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can import those views from the original contract. no need to re-implement them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah totally agree
|
||
## Questions and Discussion Topics | ||
|
||
Main friction point will be if we want this standard to be in a new different contract of if we want it to be part of the existent `MetadataViews.cdc` contract. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the new views should be a new contract, but like I said above, reuse some of the primitive views.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we discuss this on the forum or should we start the discussion assuming that what makes more sense is to put the new views in a different contract rather than updating the NFT one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should definitely put the FT specific views in a new contract
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so maybe we should remove that from the FLIP to avoid any confusion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, they should definitely stay in this FLIP because this is the FLIP that proposes them. I just mean that when we're writing the code, they should be in their own contract in the flow-ft repo instead of in the MetadataViews
contract in the flow-nft repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I expressed myself quite poorly there. I was saying if we should remove this sentence Main friction point will be if we want this standard to be in a new different contract of if we want it to be part of the existent MetadataViews.cdc contract.
from the FLIP since it seems that we all agree on creating a new contract for the new views.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh yeah. sorry about the misunderstanding. We can remove that line
|
||
Are we missing any core views that should be mandatory from the beginning? | ||
|
||
Could there be some view, like serial, that differentiates tokens from the same `Vault` depending for instance of when they where minted? (think of different years coins with the same value) Would that make them NFT rather than FT? Would ever any developer want to do that? How could we keep track of a single balance which contains slightly different tokens? Would that introduce an unnecessary complication when transferring tokens? (of course it would). This could make sense along with the [streamlined tokens proposal new `FungibleToken.Balance` interface that exposes a `getBalance()` function rather than a field just in case the FT owner wants to compute the balance](https://forum.onflow.org/t/streamlined-token-standards-proposal/3075) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to worry about this now. I think if people want that kind of view, they can submit a proposal after these initial views have been accepted and deployed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense, getting rid of it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea to add metadata support to fungible tokens, and leveraging the experience gained from adding metadata to NFTs. 👍
|
||
### Best Practices | ||
|
||
Fungible Token issuers should implement the `FTView` to achieve the as much ecosystem compatibility as possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above and clarify if the two sub-views should be also provided.
a9508ce
to
16178a5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple more comments. Once those are addressed, I think this can be merged and you can start working on the new contracts in the flow-ft repo!
f64940a
to
55e7af7
Compare
@pgebheim should I merge the FLIP here or we should only take it to the FLIPs repo??? |
Let's merge here and I'll port to the FLIPs repo |
Closes: onflow/flow-ft#81
Description
Flip for creating a Metadata standard for fungible tokens.
For contributor use:
master
branchFiles changed
in the Github PR explorer