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

XLS-46: DynamicNFT #5048

Merged
merged 47 commits into from
Jan 9, 2025
Merged

XLS-46: DynamicNFT #5048

merged 47 commits into from
Jan 9, 2025

Conversation

tequdev
Copy link
Contributor

@tequdev tequdev commented Jun 18, 2024

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 URI
lsfMutable: 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

  • [x ] New feature (non-breaking change which adds functionality)
  • [x ] Tests (you added tests for code that already exists, or your new feature included in this PR)

API Impact

  • Public API: New feature (new methods and/or new fields)
  • Public API: Breaking change (in general, breaking changes should only impact the next api_version)
  • libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
  • Peer protocol change (must be backward compatible or bump the peer protocol version)

Copy link

codecov bot commented Jun 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.9%. Comparing base (040cd23) to head (ccbed88).
Report is 1 commits behind head on develop.

Additional details and impacted files

Impacted file tree graph

@@           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     
Files with missing lines Coverage Δ
include/xrpl/protocol/Feature.h 100.0% <ø> (ø)
include/xrpl/protocol/detail/transactions.macro 100.0% <100.0%> (ø)
include/xrpl/protocol/nft.h 100.0% <ø> (ø)
src/xrpld/app/tx/detail/NFTokenMint.cpp 98.0% <100.0%> (+<0.1%) ⬆️
src/xrpld/app/tx/detail/NFTokenModify.cpp 100.0% <100.0%> (ø)
src/xrpld/app/tx/detail/NFTokenModify.h 100.0% <100.0%> (ø)
src/xrpld/app/tx/detail/NFTokenUtils.cpp 92.0% <100.0%> (+0.2%) ⬆️
src/xrpld/app/tx/detail/NFTokenUtils.h 100.0% <ø> (ø)
src/xrpld/app/tx/detail/applySteps.cpp 78.0% <ø> (ø)

... and 2 files with indirect coverage changes

Impacted file tree graph

@shawnxie999
Copy link
Collaborator

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.

@tequdev
Copy link
Contributor Author

tequdev commented Jun 20, 2024

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?
Users need to be aware of the risk to mutable NFTs, just as they need to be aware of the possibility of being burned by the issuer after purchasing a Burnable NFT.

#4838 (comment)

@xVet
Copy link

xVet commented Jun 20, 2024

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.

@shawnxie999
Copy link
Collaborator

BTW, the "Context of change" section linked to the XLS20 proposal, I think you meant to link to this one XRPLF/XRPL-Standards#130

@tequdev
Copy link
Contributor Author

tequdev commented Jun 22, 2024

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!

Copy link
Collaborator

@scottschurr scottschurr left a 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 ...

  1. Most of the comments are personal preferences of mine (although I justify them).
  2. 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!

include/xrpl/protocol/TxFlags.h Outdated Show resolved Hide resolved
{
{sfNFTokenID, soeREQUIRED},
{sfOwner, soeOPTIONAL},
{sfURI, soeOPTIONAL},
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

@shawnxie999 shawnxie999 Jul 3, 2024

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Thanks!

Copy link
Collaborator

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?

src/test/app/NFToken_test.cpp Outdated Show resolved Hide resolved
src/test/app/NFToken_test.cpp Show resolved Hide resolved
src/test/app/NFToken_test.cpp Outdated Show resolved Hide resolved
src/xrpld/app/tx/detail/NFTokenModify.cpp Outdated Show resolved Hide resolved
src/xrpld/app/tx/detail/NFTokenModify.cpp Outdated Show resolved Hide resolved
src/xrpld/app/tx/detail/NFTokenModify.cpp Outdated Show resolved Hide resolved
src/xrpld/app/tx/detail/NFTokenModify.cpp Outdated Show resolved Hide resolved
src/xrpld/app/tx/detail/NFTokenUtils.cpp Outdated Show resolved Hide resolved
@mvadari
Copy link
Collaborator

mvadari commented Dec 20, 2024

Build error -

src/xrpld/app/tx/detail/NFTokenModify.cpp:72:35: error: use of undeclared identifier 'sle'
   72 |         if (auto const minter = (*sle)[~sfNFTokenMinter]; minter != account)

@mvadari mvadari added the Ready to merge *PR author* thinks it's ready to merge. Has passed code review. Perf sign-off may still be required. label Jan 8, 2025
@mvadari
Copy link
Collaborator

mvadari commented Jan 8, 2025

Good to go from the automation tests. @tequdev please update the branch and ensure that this is ready to merge from your side.
cc @bthomee for visibility

@tequdev
Copy link
Contributor Author

tequdev commented Jan 9, 2025

ready to merge👍

@mvadari
Copy link
Collaborator

mvadari commented Jan 9, 2025

@bthomee this is ready to merge whenever you get a chance

@bthomee bthomee merged commit 58af62f into XRPLF:develop Jan 9, 2025
21 checks passed
ximinez pushed a commit to ximinez/rippled that referenced this pull request Jan 13, 2025
This Amendment adds functionality to update the URI of NFToken objects as described in the XLS-46d: Dynamic Non Fungible Tokens (dNFTs) spec.
@mvadari
Copy link
Collaborator

mvadari commented Jan 14, 2025

@tequdev it looks like this code doesn't check for invalid flags - can that be added in a separate PR?

@tequdev
Copy link
Contributor Author

tequdev commented Jan 15, 2025

@tequdev it looks like this code doesn't check for invalid flags - can that be added in a separate PR?

Nice catch!

You can check the changes in this PR.
#5246

@ximinez ximinez mentioned this pull request Jan 16, 2025
5 tasks
@ximinez ximinez mentioned this pull request Jan 30, 2025
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ready to merge *PR author* thinks it's ready to merge. Has passed code review. Perf sign-off may still be required.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants