Fix nep245 #511
Fix nep245 #511
Conversation
| @@ -326,14 +309,11 @@ The following behavior is required, but contract authors may name this function | |||
| // `approvals` is an array of expected `approval_list` per `token_ids`. | |||
| // If a `token_id` does not have a corresponding `approvals_list` then the entry in the | |||
| // array must be marked null. | |||
| // `approvals_list` is an array of triplets of [`owner_id`,`approval_id`,`amount`]. | |||
| // `owner_id` is the valid Near account that owns the tokens. | |||
| // `approvals_list` is an array of triplets of [`approved_account_id`,`approval_id`]. | |||
There was a problem hiding this comment.
| // `approvals_list` is an array of triplets of [`approved_account_id`,`approval_id`]. | |
| // `approvals_list` is an array of tuples of [`approved_account_id`,`approval_id`]. |
| // For base info, either base_id or base would be included, depends on implementation. | ||
| // Suggest to return base to save client from extral query on base info. | ||
| type MTTokenMetadataAll = { | ||
| base_id: string | null, // id in type MTBaseTokenMetadata |
There was a problem hiding this comment.
This seems confusing, should this be instead restricted to one or the other (base_id vs including the metadata itself)?
| type Token = { | ||
| token_id: string, | ||
| owner_id: string | null | ||
| owner_id: string | null, // not null if the token is a NFT | ||
| metadata: MTTokenMetadataAll | null // not null if Metadata extension is enabled |
There was a problem hiding this comment.
How/when does this field get assigned to a token?
There was a problem hiding this comment.
Curious if we need to deal with Metadata at all at this stage, wouldn't it be nicer to go with iterative approach and get the barebone tokens right up to the contract implementation and then deal with extensions?
| amount: string, | ||
| approval: [owner_id: string, approval_id: number]|null, | ||
| amount: string, | ||
| approval_id: number|null, |
There was a problem hiding this comment.
Same goes for approvals, do we really want this to be a part of the interface.
Why don't we just do the barebones MT standard without the extensions and then figure out how those will play together with what we have?
| - NEAR's [Fungible Token Metadata Standard](../FungibleToken/Metadata.md) | ||
| - NEAR's [Non-Fungible Token Metadata Standard](../NonFungibleToken/Metadata.md) |
frol
added
WG-contract-standards
|
Hi @marco-sundsk @ruseinov, thank you for pushing this NEP forward! I see that this is still an on-going effort, so as a NEP moderator, I marked this PR as draft and marked that it needs reference implementation (as per our discussion in Telegram, we don't need a full SDK-grade library implementation, we just need a standalone contract that implements all these methods and some client that demonstrates that the API surface is not lacking and ergonimic) Please ping the @near/nep-moderators once you are ready for us to review it. |
|
Hi @marco-sundsk @ruseinov, i'd like to understand the current status of this NEP. |
The status is that we have a small MVP in another repo that's supposed to drive this effort. I'm currently busy with other things, but planning to eventually come back to it. |
Now, we have a revision of this standard. This time, we focus on the combination of FT and NFT in those core functions cause we noticed some misunderstandings on FT and NFT workflow on near network in those interfaces. Beside that, we also make a supplement to the nep-0245.md to include all the extensions while leaving the one in specs untouched as a comparision base point, so that you could have a clear view about what have been changed in this revision.
The plan is to have an agreement on nep-0245.md first, then the corresponding fix would be applied to those in specs. And the standard code implementation would be the last.
The detailed explaination of this revision could be found in the discussion.