-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
XLS-46: DynamicNFT #5048
XLS-46: DynamicNFT #5048
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #5048 +/- ##
=======================================
Coverage 77.9% 77.9%
=======================================
Files 783 785 +2
Lines 66707 66757 +50
Branches 8118 8119 +1
=======================================
+ Hits 51954 52002 +48
- Misses 14753 14755 +2
|
In other PR, I suggested adding a check so that NFTokenModify would fail if there is any outstanding offers. This is to prevent the issuer from changing the URI and then accept an existing offer. |
As mentioned in this comment, wouldn't that make sense since the issuer can change the URI after the user has bought it? |
Correct, if you own a dynamic NFT then you agree that it can be changed by the issuer. I wouldn't personally put a check on offers, because this might cut into some use cases people come up with. |
BTW, the "Context of change" section linked to the XLS20 proposal, I think you meant to link to this one XRPLF/XRPL-Standards#130 |
good catch, fixed! |
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.
Nice job on this pull request! The unit test coverage is pretty good. I appreciate that you took the time to do that.
I left quite a number of comments, but don't be dismayed by that ...
- Most of the comments are personal preferences of mine (although I justify them).
- I can be a very picky reviewer.
That said, I think that my comment regarding the nft::updateToken()
implementation is pretty important. If you choose not to implement that change I'll want to understand why.
For your convenience I made commits that implement all of the changes I've suggested. If you want, you're welcome to cherry pick them, or you can just use them as examples of the changes I am suggesting. The commits are the top-most three on branch https://github.com/scottschurr/rippled/commits/tequ-featureDynamicNFT/
- Suggested approach to NFTokenMintMask: 8aec32c
- Suggested change for
testNFTokenModify()
: 813c302 - Suggested changes to NFTokenModify.cpp and NFTokenUtils.*: 1393268
I hope you find those useful.
Thanks for the submission!
src/libxrpl/protocol/TxFormats.cpp
Outdated
{ | ||
{sfNFTokenID, soeREQUIRED}, | ||
{sfOwner, soeOPTIONAL}, | ||
{sfURI, soeOPTIONAL}, |
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 spec (XRPLF/XRPL-Standards#130 August 18, 2023 version) specifies that the sfURI
field is required. Here it is listed as soeOPTIONAL
. I think that soeOPTIONAL
is a good choice, because that matches the behavior of NFTokenMint
. Perhaps the spec needs to be updated?
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.
Since you pointed it out, as of Jun 29 the sfURI
field has been updated to an optional field.
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.
Is there any use case for removing the URI from an existing NFT? Is there any difference from burning the NFT compared to an NFT without a URI?
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.
Such a use case may not be common, but it is not impossible to say that there is no use case.
Since the NFTokenMint transaction can be executed with the URI field unspecified, it is reasonable that the NFTokenModify transaction can change the URI field to unspecified.
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. Thanks!
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 there be a flag for removing the URI from the NFT, like with NFTokenMinter
, instead of just using its absence?
Co-authored-by: Mayukha Vadari <[email protected]>
Build error -
|
ready to merge👍 |
@bthomee this is ready to merge whenever you get a chance |
This Amendment adds functionality to update the URI of NFToken objects as described in the XLS-46d: Dynamic Non Fungible Tokens (dNFTs) spec.
@tequdev it looks like this code doesn't check for invalid flags - can that be added in a separate PR? |
Replace from #4838
Co-Author: @xVet
High Level Overview of Change
Spec: XLS-46d: Dynamic Non Fungible Tokens (dNFTs)
This Amendment adds functionality to update the URI of NFToken objects by adding:
NFTokenModify:
Transactor to initiate the altering of the URIlsfMutable
: Flag to be set in a NFTokenMint transaction to allow NFTokenModify to execute successfully on given NFT.Context of Change
XRPLF/XRPL-Standards#130
Type of Change
API Impact
libxrpl
change (any change that may affectlibxrpl
or dependents oflibxrpl
)