I don't necessarily feel like they're being reactive, but trying to find the right product/market fit for NFTs. I think Ripple realizes that they can't stand idle while other platforms are experimenting with new blockchain uses cases and products. This is one of the primary reasons RippleX was created besides being a gateway/resource for the XRPL community developers. Ripple's core raison d'etre is still intact around all things payments/value etc., however, RippleX allows them to take risks with new concepts and ideas. To me, I feel Ripple has been very deliberate and strategic in how they approach some of these new use cases so as not to get caught up in all of the preliminary hype that typically surrounds them at the onset. There's a pretty good discussion related to NFTs via the XRPLF's Standards Github portal on Non-Fungible Token Support.
Forte's Engineering Leadership posted a wish list of features/functionality they are partnering with RippleX to developed for NFT support on the XRPL. Here's the Forte Engineering Leadership post:
"Thanks XRPL team for putting together this comprehensive spec. From our perspective at Forte, the design is thoughtful and would cover many important use cases we have come across with our game developers. We are excited to see it go live!
Below I have included a descriptive wishlist from our perspective, that would help make for serving game developers and their deep use in the NFT space. It has a fair amount of crossover with the above insights and comments from the rest of the community, particularly around the transfer fees design and metadata commentary. I have included the bulk of our feedback to do justice to the team's thinking, so apologies for the long windedness. Thanks ahead for enduring
This seems like an efficient, stateless NFT design.
Structuring NFT management/organization at the user/account/owner level will reduce tracking complexity, which is great.
We really like the idea of offers on-ledger, and the idea of a specified take rate on-ledger for the original issuer of an NFT. These are differentiated features and we think they will add value in the ecosystem. More below.
This design would cover some of our known use cases, but has some limitations around asset use cases which are useful in games.
In particular, we think this design is workable for totally unique, singleton assets. Classic “NFTs”. Adding a stateful field for provenance history verification may be worthy of consideration. See more detailed notes on this below.
The design could be used for Semi-fungible tokens per the Further Development section, but some potential snags could exist without some kind of distinct object types and/or modifying the NFT Offer system to allow for both unique/non-fungible tokens and semi-fungible tokens
Wish list: (1) Provence Tracking:
This proposal works well for totally unique items. At the same time, it doesn’t provide everything one might hope for with respect to totally unique assets. In particular, provenance/ownership history would have to be tracked and verified entirely off-ledger.
Of course, provenance and chain of custody can be tracked and verified off-ledger by walking all transactions where a given NFT was transferred. However, doing so would be expensive both to prove and to verify. It may be worthwhile to add a stateful field, updated each time an NFT Object is transferred to a new owner, which could be used as a witness to at least quickly verify off-ledger claims of provenance and custody history.
For example, perhaps a custody chain hash field is introduced, such that on creation: ProvenanceHash = hash(issuer), and on transfer: ProvenanceHash = hash(ProvenanceHash, newOwner)
With this system, a claim about the chain of ownership could be made off-ledger, and anyone could quickly verify it’s veracity by looking at this proposed field for the NFT object on-ledger and computing the hash sequence of each owner in the purported ownership history chain.
Our wishlist proposal here only works for truly unique/non-fungible assets. See our thoughts below regarding semi-fungible assets.
Wish list: (2) Issuer-based queries for NFTPages:
The NFTPage system will be extremely helpful in reducing the complexity for application developers when trying to find all the NFTs a single user owns. However, in the context of videogames, it is not uncommon for a single game to issue 100-1000’s of items to a single player. When you expand this concept for a user who plays multiple games, this may result in a lot of pages. If so, filtering the NFTPages to select the NFTs which are usable in your application may be expensive.
We don’t have a specific solution proposal for this. However, at scale a game application is often the Issuer of the NFTs for the game, perhaps grouping NFTPages by Issuer could make sense, or if implementing an Issuer-based index or query system for NFTPages would be worthwhile. The goal being that a single application can quickly determine which of the NFTs a user owns can be used in their application without having to walk all the pages, but may be too specialized for many other use cases.
Comment: (3) Semi-fungible tokens
Because non-fungible and semi-fungible tokens have very different semantics, we wonder if it is worth supporting a distinct SFTObject (now or later).
Wish list: (4) Transfer Rates:
We really like the idea of having an on-ledger field in NFT objects for TransferRate. Even though royalty shares can’t be enforced for off-ledger payments, a designated on-ledger TransferRate could be an important social coordination signal. Enforcing the TransferRate for on-ledger payments may also help normalize the idea that payments should happen on-ledger, and provide a good justification for encouraging the ecosystem supporting NFTs on XRP Ledger structure payments this way. For example, this may encourage more marketplaces that support XRPL NFTs to use on-ledger transactions (and XRP) for all payments.
We wonder if it might be worthwhile to modify the Issuer and TransferRate fields such that they form lists.
Obviously application developers and other platforms can manage these royalty distributions on their own, off-ledger. But support for multi-party issuance and according transaction revenue splits may be a worthwhile enhancement of the proposal. (mentioned in other user comments as well)
Wishlist: (5) Multisig NFT transfers:
The current design indicates that an NFTOffer can be fulfilled by agreement between the owner and the receiver of the offer.
Would it be possible to add support for a multisig offer where the “Issuer” additionally has to approve the trade as well? Perhaps this could be accomplished with an additional field in the NFT object, specified by the issuer at issuance. Alternatively, could an issuer require that an NFT they issue can only be held in a multisig account to which the Issuer is a party, with a required key?
For compliance with BSA/Money Transmittal/AML regulations, it may be useful for some issuers to require their explicit approval of transfers of NFTs. Forte implements a system like this for certain asset exchanges involving tokens defined on EVM-compatible blockchains. Obviously, this idea detracts from self-sovereign property rights, including the right to transfer assets at will, but it may be necessary for some issuers to ensure they can enforce compliant exchanges of valuable assets if they issue those assets. Supporting multisig authorization for any NFT transfer may encourage a broader market with more assets created by more issuers."