NFT module on the Hub #9065
Replies: 21 comments 111 replies
-
|
Thanks for writing this up! Your simple proposal is basically what I've had in mind for a while and is what is currently on our roadmap for the next SDK release (0.44). We should align on how the permissions logic works to make sure it meets the needs you're describing. |
Beta Was this translation helpful? Give feedback.
-
|
The api looks good, I like the approach that it works out of the box for everyone with the current bank API. This would turn bank into a transfer module more so than a bank. To me bank is associated with fungible assets. Such a rename could go well with IBC. I am worried we are trying to generalize bank to fit many needs. Is there a concern of overlapping separate concerns. Fungible and non-fungible minting and burning are different use cases. Quesetion: Do you see bank holding the state of which accounts hold the nfts as well? |
Beta Was this translation helpful? Give feedback.
-
|
@aaronc I really like the Denom Manager Interface, every module that issues tokens can implement one and manage keeper logic to be triggered and permissions to be checked on mint, burn and transfer. This will also enable use-cases like the staking module being able to mint validator share tokens or the dex module to mint LP tokens. @marbar3778 in that scenario the bank module will act more like a tokens module maintaining a common state for all token types and implementing transactions for mint, burn and transfers. We can build on the bank module if the aim to implement a minimum delta on the current SDK and gain quick consensus towards deployment on the hub. |
Beta Was this translation helpful? Give feedback.
-
|
I share the same concerns as @marbar3778 (#9065 (reply in thread)) |
Beta Was this translation helpful? Give feedback.
-
I am closest to Regen's use case, managing tokens minted on our chain with bank would be ideal. I can't speak for other use cases but I get the sense from what @deepanshutr is saying that this is likely true more broadly.
Yes, they would just be balances. In the case of an NFT which cannot be fractionalized, that balance would be 1. NFTs with a supply of 1 but which can be fractionalized could have some decimal balance (so far there's already some alignment around #7113). |
Beta Was this translation helpful? Give feedback.
-
|
@aaronc coming from the ETH space, I initially had some biases from the ERC721 world which does typically offer a generic NFT module that has minting/burning/transferring. But I think the interchain world is a different scenario because we need to think inherently about a generic nft module here as being one that would interact cross chain. For this scenario, I do think it makes sense to keep minting and burning of the NFT on the zone specific level rather than on the SDK. An example scenario I have in mind is this: Persistence.One wants to mint an NFT and sell it on an IRIS NFT marketplace. If the baseNFT module targeted for the hub would support minting and burning, it would either mean that p1 would have to mint on the hub, mint a synthetic doppelgangers for the NFT on IRIS somehow (dependent on NFT IBC spec, maybe an additional message type in addition to ibc-nft-transfer?) and the NFT registry/custody module on both hub and iris would have to keep track of these states. Then, we also have to think about how burning this NFT would work through the Hub. This is why I am more in favour of the simple NFT module on the Hub which is really just like a registry of NFTs, and then we work on the NFT IBC spec for transfers. Minting and burning on the zone level would scope that part of the functionality out of the work packet for now. As long as the token data field in the simple NFT struct supports proto.Any, we could allow for any amount of customisation (metadata et) on zone-level. Additionally, this would be pretty similar to how Gravity Bridge conceives of NFT transfers. Eventually, we could refactor bank to support more features but imo this would be the quickest plan to action. Maybe my story is missing something. Let me know if that makes sense for you! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you Deepanshu!
|
Beta Was this translation helpful? Give feedback.
-
|
Will add iris NFT module implementation to my list of cosmos NFT impls, thanks, Jeffrey. |
Beta Was this translation helpful? Give feedback.
-
|
I started working on an NFT module (based on IRIS's stargate module) as part of Sommelier that we needed to handle custom NFLP tokens from uniswap relayed through the Gravity bridge. The main issue with it was that it didn't support custom NFTs because it doesn't support proto.Any. If I were to redesign the module I'd maybe just have a basic NFT module that only supports minting burning and transferring NFTs. Collections, DIDs and marketplaces can be built on external modules that import this NFT module. Ref NFT with proto.Any: PeggyJV/sommelier#37 |
Beta Was this translation helpful? Give feedback.
-
|
It would be almost impossible to support all the transactions exposed by custom NFTs, ex. cryptokitties breed txn, through one module on the Hub. Even the simplest transactions like minting and burning would require the implementation of flexible logic around NFT templates, mutable/immutable metadata fields, access control and maintainer hierarchy etc. I think the simplest approach here would be to design a module that is able to assign each externally generated NFT a unique id through some deterministic logic and then allow for maintenance and transfers of this token ownership representation between wallets. We may introduce more complex custom transactions through reference implementation of modules similar to the current mint module, but these modules may never live on the hub. Thanks for the ref impl @fedekunze, would have been very helpful to be able to access and maintain this code through a repo, maybe https://github.com/cosmos/modules/tree/master/incubator/nft . |
Beta Was this translation helpful? Give feedback.
-
|
also you might find the interNFT impl interesting for the Sommelier use case https://github.com/persistenceOne/persistenceSDK/tree/master/modules/assets |
Beta Was this translation helpful? Give feedback.
-
|
@ig-shaun just added a new discussion topic with the framing that came out of our work in the Interchain NFT and Metadata working group over the last half year. #9110 We've separated it out so the community can discuss, as separate options, what we do in the immediate term and what we do long term. Our basic premise is that the immediate term option can, and should, be aligned with a longer roadmap that ultimately results in a distinct advantage for building NFTs in Cosmos. In short, we like starting with the BaseNFT module, in particular with the Stargate port developed by IrisNet. Out of the box, that's a compelling first option, from which we can add new features. We've outlined how we see that roadmap evolving, including how to provide composability and DID functionality early--because there are fairly straightforward options for doing this with minimal changes to the IrisNet implementation. FWIW, we are actively working with other chains to apply this same IID approach as an iterative development for NFTs. Here's the abbreviated roadmap for any blockchain:
This allows existing token infrastructure to leverage DID approaches without adjusting other token functionality: current getters and setters work as normal. The DID Document simply standardizes a particular view of that functionality.
This enables literally any kind of derivative to be defined and implemented, rather than attempting to pre-define a subset of derivatives that are hard-coded into the module, such as "splittable"
Just like DIDs, IIDs are blockchain agnostic, providing a mechanism for existing systems to represent their control mechanisms in a standardized way. Any NFT system that adopts IIDs and uses IID Documents to present the interface for tokens, will be compatible with both emerging DID systems (authentication, authorization, and wallets) as well IID systems on on other chains. Anything else either recreates that mechanism as a new standard, or is using bespoke, custom approaches that will not be compatible across chain and possibly not with similar NFT approaches even on the same chain. We make that case in more detail in the discussion at #9110. Our short take on the proposal here is that we find the IrisNet iteration on Base NFT to be a particularly compelling immediate term solution with sufficient long-term alignment with the IID vision. |
Beta Was this translation helpful? Give feedback.
-
|
My preference is have a very simple NFT custody module on the HUB that could integrate with some kind of trading functionality and a NFT IBC spec. All you could do with NFTs in the Hub is hold and transfers them. There might be some opaque structured data that hub would route but not operate over. The Hub would just a custodian and trading house for NFTs. Functionality for NFTs and minting/burning would happen on Zones. |
Beta Was this translation helpful? Give feedback.
-
|
totally in favor of this approach |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I'm Tendermint's new Director of NFTs, so Tendermint's approach to this is largely going to be my responsibility. There's a lot here, and a lot of it is great, so I don't want to dismiss any of it but there's too much to just respond to all of it. But here's my current thinking so you can start yelling at me :)
My lens for this is Pylons, which is an NFT lifecycle zone I've been working on for a few years, and supporting a community of zones adjacent to Pylons, to do marketplaces, lending, whatever. So it's about IBC between these zones, and what kind of envelopes are needed to make that IBC really work. Finally my core question about modules on the Hub is why should it be on the Hub? What does the Hub care? This isn't a dismissal, it's a real question that we need total clarity about when we're adding modules, IMO. |
Beta Was this translation helpful? Give feedback.
-
|
To add to @shahankhatch's point the hub, by the virtue of its first mover's advantage, is and will continue to remain the securest most decentralised chain in all of the cosmos ecosystem which all other chains would connect to, to exchange and escrow tokens( FTs and NFTs). To enable this the hub must define a common NFT interface with just the affordance( hope I am using the term right) of transfers. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, this is sort of where I stand, where I want to make sure we can do transfers and encumbrances (meaning royalty payments on sale) but I don't think we should take on any lifecycle work. |
Beta Was this translation helpful? Give feedback.
-
|
@MikeSofaer I think I am still a bit unclear as to what you mean by encumbrances, but would this plan of action cover what you need? #9065 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
The most concrete way to describe what I'm getting at would be for the |
Beta Was this translation helpful? Give feedback.
-
|
right, i see what you mean. thanks for the clarification! |
Beta Was this translation helpful? Give feedback.
-
|
Here is my concrete plan of action that I shared with @charleenfei and @hulatown privately:
Imo only 1. should live on the SDK, while the other modules (2. and 3) should live on other app-specific blockchains. NFT interoperability should be spec'ed considering only 1. |
Beta Was this translation helpful? Give feedback.
-
|
I'm happy to defer to the "Cosmos way", but I share @fedekunze's perspective that if all BaseNFT is doing is owner & id, it doesn't seem particularly useful. Seems like any new module could manage two properties stored on chain without much trouble. To confirm my understanding, the expected approach is that token developers are able and willing to customize the BaseNFT module to add capability. Therefore, customizing to meet particular token needs should be done by forking and modifying the BaseNFT module. This will mean that every customization is bespoke and integration with other modules is done on a custom basis. This is what I mean by the "Cosmos way". If I'm not following, please correct my understanding. The approach I was advocating would allow for token development without source code modification of existing modules--new code is only needed in new modules that add functionality on top of the baseNFT module. Dynamic registration and linking of pre- and post- actions would allow module interoperability and plug & play for modules like a marketplace or auction or whatever, so that chain developers add the modules (ideally without customization of either the BaseNFT module or a marketplace module). We might call these "extended handlers". The current proposal (with just owner & id and no pre- or post- actions) means that adding a marketplace module with royalty payments would require changing code in BaseNFT to make sure that all NFT related actions trigger royalty payments, rather than simply registering the marketplace module as an extended handler which handles royalties (or having a separate royalty and marketplace modules). That's not a wrong option, just a different model for extensibility. |
Beta Was this translation helpful? Give feedback.
-
|
I don't have a strong opinion about the particular solution you're proposing, @jandrieu but I think we're in agreement about the value of a module being in creating interoperability, so it should have at least some non-trivial behavior that we want to share between chains. |
Beta Was this translation helpful? Give feedback.
-
No, chains can create their own NFT representation, that's why we would be using As for hooks, that is also something that can be added but I'm not sure about the utility of them if we are exposing the |
Beta Was this translation helpful? Give feedback.
-
|
We're on the same page on your first point. Chains must be able to create their own NFT representation, but if the BaseNFT module doesn't support encumbrances, e.g., through pre- and post- actions, then it seems to me that either:
Maybe it's that last option that everyone is looking for to handle encumbrances, but at this time, I haven't seen a proposals for that feature in BaseNFT. For example, if I need to create a token that can only be transferred once/day, I don't believe I could do that on an application chain using stock BaseNFT (with just owner & id) unless I can guarantee that no other module directly calls SetNFT. On a simple chain, that seems tractable. But, given the complexity of the hub itself--and the lifecycle of other modules--maintaining that guarantee even as future modules are developed feels like an exercise in runaway complexity, on top of the innate complexity of all the different kinds of NFTs people are hoping to build. My believe is that chains that support the easiest option for the widest variety of capability will attract token creators. Chains that don't, won't. Hooks would enable arbitrary restrictions to be enforced even when some module is unaware of it. They simply call SetNFT, knowing that it may fail because of failed preconditions. But in handling the call, the BaseNFT module enables the appropriate encumbrance and the calling module doesn't need to know anything about it (other than handling the failure message). Token class creators could add an arbitrary number of encumbrances and they simply get applied whether triggered, e.g., by a marketplace module or an auction model or a royalty module, allowing independent development of any number of reusable modules. In many ways, this is an example of the hour glass API. All a chain developer needs to ensure on a hook-enabled BaseNFT is that token functions call SetNFT directly, which reduces the complexity to a relatively easy audit compared to making sure that all intended encumbrances are applied by all the modules that might call BaseNFT. I'm puzzled by this comment, though:
I don't know what you mean by "setting them to store". And, how would there be a BaseNFT that doesn't allow minting NFTs? Isn't that the whole point? And if the SetNFT is exposed, then isn't that precisely when you need SetNFT to support encumbrances? However, I think the larger problem is timing. There's understandable pressure to get something simple into the next release and figuring out the design and then implementing hooks isn't likely going to happen fast enough. A "simplest" ADR seems to be the right call, if only because of that timing constraint. The more sophisticated features and options seem to be more appropriate for the Tokens 2.0 proposal, which still needs to be designed, debated, and implemented. Likely that would need to be (or use) a fork of BaseNFT, because without hooks I don't believe we couldn't use BaseNFT directly and support all of the use cases uncovered in our work in the Interchain NFT & Metadata calls. I believe that is the only additional feature that would be required, however. They enable Tokens 2 to layer on the rest of the features we need. Do we have anyone else developing a module planning to use BaseNFT and can comment on what they need from BaseNFT? Any modules actually in development like a marketplace, auction, or royalties? That's why I've been advocating for hooks: they are the easiest way I can see to actually have a BaseNFT module that Tokens 2.0 can build on without forking or rewriting from scratch. That said, we're going to propose an ADR for this super-simple module with minimal changes to the current BaseNFT (without hooks). That should help the community evaluate the tradeoffs for a fast-to-market option. |
Beta Was this translation helpful? Give feedback.
-
With I imagine that you are referring to the creation of NFTs, which involves minting + setting to store. In that case, you can check for encumbrances before and after minting/burning using hooks, but, as I previously mentioned, that's out of scope for the x/nft module which will only take care of storing NFTs + queries by ID. Devs can implement encumbrances on another module (that would maybe live on the Hub) that imports the SDK |
Beta Was this translation helpful? Give feedback.
-
|
This discussion seems to be centered around the hub. Should this be the first module that lives in gaia? If not, this module may be a good candidate for having its own go.mod (cc @aaronc) I would like to hear from maintainers of the sdk about this. |
Beta Was this translation helpful? Give feedback.
-
|
Totally agree that if it is in the SDK that it gets its own |
Beta Was this translation helpful? Give feedback.
-
|
I'm in favor of moving it to Gaia too |
Beta Was this translation helpful? Give feedback.
-
|
Seems all hubs need it. |
Beta Was this translation helpful? Give feedback.
-
|
I'm for it, and I've added it to the roadmap (which is tentative for now). |
Beta Was this translation helpful? Give feedback.
-
|
A quick update on this topic for everyone who has participated so far, there will be an ADR open next week for review. Appreciation for all the thought and consideration so far 🙏 , and looking forward to formalising and finalising this topic. |
Beta Was this translation helpful? Give feedback.
-
|
📝 #9329 |
Beta Was this translation helpful? Give feedback.
-
NFT to use x/bank for IBC and asset registry / balance bookFollowing the discussion and review of ADR-43 I want to discuss an alternative approach extending @aaronc comment above . Design goals:
ProposalWe don't define x/nft module. Instead we define a minimal interface and behavior using x/bank and DID. In this proposal we will utilize x/bank to become de facto a balance sheet of Cosmos assets and have a minimum interfaces for NFT Msg Server. That interface can be extended by various implementations. Each NFT will be stored as a new token (denom) in x/bank with total supply = 1 and unique ID. ID should be defined using DID standard (which is very easy to begin with - an app will need to decide about the method name). service Msg {
rpc MintMonster(MsgMintMonster) returns (MsgEmptyResponse);
rpc Burn(MsgBurn) returns (MsgEmptyResponse);
// cease
rpc Clawback(MsgClawback) return (MsgEmptyResponse);
}
message MsgMintMonster {
string did = 1;
string owner = 2;
// fields for bank.Metadata, we can pack them in bank.Metadata here.
string name = 4;
string symbol = 5;
// URI, Description and Dispalay is optional because the NFT is represented as DID.
string uri = 6;
string description = 7;
string display = 8;
// other NFT specific attributes
string age = 9;
int power = 10;
// probably we don't need Any - we can have concrete attributes for each NFT category which are
// linked to the rpc method.
// google.protobuf.Any data = 3;
// NOTE: minter is not needed - current transaction signer is the minter.
// string minter = 4;
}
message MsgClawback {
string from = 1;
string to = 2;
string did = 3;
}
message EmptyResponse {}The NFT Msg service will depend on x/bank keeper or Msg service. Hence it should be able to create new tokens (denoms) as well as burning. The pseudo code for the Mint method is following: func (m Msg) MintMonster(ctx context.Context, msg *types.MsgMintMonster) {
m.keeper.AssertDoesNotExist(msg.DID)
// mint coins for the current module
coin = skd.Coins{{Denom: msg.DID, Amount: sdk.One}}
// we are extending the bank Mint to add the minter information with related event.
m.bank.Mint(ModuleName, GetSigner(ctx), coin)
m.bank.SetDenomMetadata(bank.Metadata{Base: msg.DID, msg.Name, msg.Symbol, msg.URI, msg.Description, msg.Display})
// send coin to the owner
m.bank.SendCoinsFromModuleToAccount(ModuleName, ModuleName, msg.Owner, coin)
m.keeper.SaveMonster(msg.did, Monster{msg.Age, msg.Power})
}
// Cease token from one account and move it to another.
func (m Msg) Clawback(ctx context.Context, msg *types.MsgMintMonster) {
// service can set admin addresses to manage who can cease NFTs
assertIsAdmin(ctx);
assertDenomRegistered(msg.DID);
coins = skd.Coins{{Denom: msg.DID, Amount: sdk.One}}
m.bank.SendCoins(ctx, msg.From, msg.To, coins);
}NFTs can be derived using a custom logic, which will create a new token (denom) in x/bank and either burn the "parent" NFT or keep both as active. Furthermore we will require that the Derived tokens will link themselves using DID document. The interoperability is assured by:
Identifying NFTs using DIDNFTs SHOULD be identified using DID. Implementing DID standard is an iterative process, easy to begin with, which brings lot of benefits. Not using DID may lead to re-engineering or adding adaptors and lessons learned effect. Here I would like to copy the excellent comment by Shaun:
Adding DID fragments allows for multiple fungible tokens to be associated with a base NFT. For instance Tying a supply of (one or more) fungible token sets with a DID Denom in Bank to the same non-fungible token Denom in baseNFT would enable fractional shares of an NFT to be issued in a way that the non-fungible asset is directly linked to its fungible derivatives. This seems to be a core requirement for many NFT use-cases. Services for functions such as The bank module now allows long strings for Denom, so this should not limit using a DID for denom. However, there could be an implementation restriction with this approach as standard Regex does not allow colons as used in DID uri's From what I understand, this can be over-ridden. But is the Regex over-write on one chain likely to break on another chain when a DID Denom gets IBC transferred (may relate to #7027)? The benefits of x/bank
By using x/bank to be a common module for keeping the balance we unify the way how tools interact with SDK to transfer assets. This approach makes x/bank a balance sheet for all SDK assets, essentially to:
Finally, it will make different NFT implementation interoperable by using the common x/bank interface. Neutral consequences
Cons of using x/bank
We could gain extra functionality by creating a NFT specific common layer similar to x/bank. However that will duplicate lot of work and complicate interoperability. TODO
|
Beta Was this translation helpful? Give feedback.
-
As the Interchain NFT and Metadata Working Group, we have pioneered the proposal to use DIDs for digital assets, so the idea is cutting-edge and is starting to catch on – especially in other blockchain communities. With regard to broader adoption of DIDs (outside of our innovation to use these for NFTs) the W3c DID Method registry shows a growing list of DID methods with a good number being blockchain-based, which is only a fraction of real DID use-cases that have bothered to publish to this central registry (now with JSON-LD, central registries are technically obsolete) and we know of many more projects implementing DIDs for blockchain-based applications across most of the major networks, including Cosmos app chains (Commercio, ixo, IOV, Cosmos Cash, Nym, Mobix.ai, Medibloc, ...) who we anticipate will expand into using this identifier standard for digital assets, as the benefits are compelling. Businesses and institutions building on DIDs include some of the major tech companies and government agencies (Microsoft, Workday, US Department for Homeland Security, Canadian Government, IATA, to name only a few). In our own work, as ixo, we are seeing an explosion of use-cases and opportunities to apply the IID standard to digital assets - especially in places where these are most needed to escape exclusion from traditional enterprise and state systems, in Africa, Asia and Latam. These are high-volume and high-impact markets. |
Beta Was this translation helpful? Give feedback.
-
I am less than 100% confident. For example, if the token represents a non-fungible gold Kilobar with a specific serial number, this would have rights associated with the physical property, such as the right to exchange the token for the physical bar, or to receive the gold price cash equivalent value. By the action of the minter of the kilobar NFT, holders of the fractional coins would now have some claim (but what rights?) to receive a share of the financial gains made on sale of the physical product the NFT represents. Which gets us into the problem that many NFT use-cases explicitly do not require fractionalisation or divisibility. Non-divisibility, non-transferability, etc. are required features. A powerful and distinctive feature of NFTs is that these may be used as carriers of explicit rights and representations which may be non-fungible or even non-transferable. What happens when the holder of the rights to a whole physical property cannot present 100% of the fractional representation of the property (let's say some fractions were used to pay gas)? Does the property retain its accorded rights? Now if all is still whole and I do own 100% of the [1MWh Unique Serial Number] Renewable Energy Certificate coin, then want to exercise my right to mint 1,000 fungible 1KWh tokens, I need a mechanism to lock the [1MWh Unique Serial Number] coin so no further 1KWh derivative tokens can be minted. I really believe we need to understand that not all tokens are coins. The Token Taxonomy Framework has done a great job of gaining multi-stakeholder consensus on business requirements-led definitions of all types of tokens, defined by their unique property sets and behaviour sets. At minimum, a non-fungible token must be allowed to properly represent a digital property/asset/title, or a digital representation of a physical-world tangible or intangible property/asset/title, with its associated rights and linked resources, in a way that does not limit this to the features of a coin, or encumber it with the unwanted properties and behaviours of a coin – unless the specific property/asset/title is best being minted as a fungible coin and not as a non-fungible token. |
Beta Was this translation helpful? Give feedback.
-
|
I totally agree with argument presented by @ig-shaun . Not recommending DID is like missing an opportunity. It's super easy to prepare the foundations for DID. A chain doesn't need to do all at once. It's enough to to embrace the DID identifier and method to begin with. For me the main advantages are:
@charleenfei was pointing emphasizing on DID in the ADR would create a fear because projects would think it will add lot of complexity and development time. |
Beta Was this translation helpful? Give feedback.
-
|
We did discuss today that possibly the next version of the bank API could include some renamings to make it more generic. For instance, we could rename I do think others are seeing the value in reusing the existing infrastructure bank already provides and as we have shown there is actually no refactoring required to get started. But I do want to understand better your concerns @ig-shaun and see if we can accomodate them in an evolving design that manages all these rules around transferability, etc. or whether this does merit a clearly separate management of fungible vs non-fungible tokens. |
Beta Was this translation helpful? Give feedback.
-
|
As this seems to be moving quite quickly now, I'm not sure if all my comments will be relevant to the thinking as of today. But let me offer some responses that will hopefully be helpful.
Using services already offered by bank does make sense if we can modify this to allow for:
Given this plurality of token types which are needed for different use-cases, it does totally make sense to reframe the interface to the supply and ledger services of the current bank module into a We would not expect a generic SDK module to necessarily offer all the services required to deliver these behaviours, but it is worthwhile considering what is needed and what is possible, to make the module as versatile as possible. One of the most fundamental requirements is that the module SHOULD enable tokens to be locked, to enable derivative tokens to be minted with guarantees that the original asset has not been altered. For instance, when derivative fungible "Gold Gram" tokens are minted to represent shares of a Unique Whole Non-Fungible token which represents the rights to a specific whole gold kilobar with a unique serial number and provenance claims, the kilobar token should not be re-sold leaving the gram token-holders empty-handed. Which then brings us to the question of authorisations to invoke the standard module functions. Whilst out of scope for the current phase of development, it would be awesome to have delegable authorisations and more sophisticated auth schemes which enable configurable business logic (e.g. implementing caveats on object capabilities, using authorisation capabilities), but this is probably a topic for the future. These logic functions do not need to be provided by the bank/tokens module, but could be expressed in the IID document for a token instance or class. Each class of token has a set of token properties which we have proposed could be expressed through IID-method DID documents. Defining classes of tokens and collections (e.g. sets of tokens which are of the same class) could be implemented in a |
Beta Was this translation helpful? Give feedback.
-
|
I just created a proof-of-concept more of the irismod nft module which uses This is just to demonstrate that this approach does not require a bank refactor other than adding If we want a master "read-only" |
Beta Was this translation helpful? Give feedback.
-
|
@zmanian wrote:
As diplomatically as possible, this is rubbish. DIDs are not yet even a formal published standard (they are in the Candidate Recommendation stage at the W3C). To assert they are failed is at best erroneous. If you don't believe in DIDs as a forward-looking opportunity, that's a fine judgment. It's not mine, but it's valid. Asserting DIDs are a failure before they've even finished becoming a standard is just FUD. The proposal to use DIDs for NFTs came out of work paid for by ICF and led by @ig-shaun and myself. We spent ~6 months hosting weekly calls, gathering requirements, and proposing a solution that applied the best DID thinking to the best NFT thinking in the Cosmos context. The result was an understanding of a large number of use cases that could not be met with arbitrarily simplistic notions of what an NFT or FT is. The momentum in the community is clearly going towards a base/NFT module that is not forward-looking and that by design has extremely constrained functionality. That's fine, I, at least did not take on the task of convincing the Cosmos community of the quality of our proposals. Rather, we did the work, shared the work, and its up to the community to decide how, if at all, we advance that work. However, mischaracterizing our proposal as
|
Beta Was this translation helpful? Give feedback.
-
|
@jandrieu For clarity, I think it would be better to continue parts of your post not related to NFT in a separate thread in this discussion. |
Beta Was this translation helpful? Give feedback.
-
I think that's the idea. I'm not sure if we should aim for general DID router (first option in question above), or rather ecosystem specific one (second option). The Hub shouldn't be responsible for registering all tokens. Although it should be able to handle and route all asset transfers for inter chain purposes. |
Beta Was this translation helpful? Give feedback.
-
|
I would actually encourage this discussion to move as well to another thread, @ig-shaun should be posting an IID draft for review that should give a bit more technical spec/design as well to the concepts outlined in this thread. Perhaps this would be a good place to continue the discussion. @robert-zaremba this is the one I have already flagged your attention for last week :) |
Beta Was this translation helpful? Give feedback.
-
|
@robert-zaremba We have #9589 as an ADR on the proposed Cosmos IID method for DID. I don't know of any proposals or agreed use-cases for a DID to actually be registered on the Hub with resolution to a DID Document (although this might be conceivable for chain-name records). Just for illustration: if a DID was registered on the Hub, this would have the syntax With the IID spec DID method, we really don't need to have more methods for different asset classes, as this is versatile in encompassing all asset types which can be resolved to an on-chain record. We have a recent discussion in ADR-043 about module vs namespace. As all assets must originate from some module, it is likely expressing a module name as the asset namespace, within an application chain namespace, using the Cosmos IID method, is the way to go. Would be keen to get consensus on this in the ADR chat. Moving the related discussion over to #9589 from here... |
Beta Was this translation helpful? Give feedback.
-
Happy to do that. Which parts do you mean? My reply was specifically addressing @aaronc's question |
Beta Was this translation helpful? Give feedback.
-
|
at the module architecture structuring call on Friday of last week, we discussed finalising the ADR spec (as @chengwenxi) has done this morning to an implementation which exposes an ERC721 compliant API to end users and using the bank module (no refactor of the current bank module necessary) as the underlying metadata and token storage mechanism. DIDs as a token URI would be incorporated in a later implementation, as to not conceptually introduce what should be two large concepts and interrelated but not necessarily interdependent concepts (NFTs and DIDs) in one ADR. @zmanian @fedekunze you had a preference against using the bank module, but would those concerns block this version of the NFT ADR? 0092c53 @ig-shaun @jandrieu you have expressed in favour of pulling DIDs into this ADR, but would this concern be a blocker consideration for a go ahead of the basic NFT module (with a forward looking perspective that the token URI string can be a DID if the sdk application developers choose) in your opinion? looking forward to getting consensus here and landing an NFT module on the Hub and into the SDK which is usable out of the box and serves the widest swathe of potential users! |
Beta Was this translation helpful? Give feedback.
-
|
Forgot about that. Another global 🤦 . We will probably need to make that a parameter on the bank keeper. Either way, I don't think overriding it to allow The current denom namespacing works with |
Beta Was this translation helpful? Give feedback.
-
|
Yep. Mapping from / to : will work if all denoms always map from / to : before presenting the did and after parsing the method-specific-id. For example, and Would have very different semantics, the latter pointing to a linked resource with path "abc/subname" hosted directly at the ixo:token module and the former points to an linked resource with path "image" associated with the asset "abc" in the ixo:token module. If those slashes survive to the DID-URL, we will have ambiguous semantics. In those example urls Here, the denom is "abc" (the image is the path of the linkedResource). Here the denom could be I'm not sure this is resolvable because the path part in DID-URLs is of a different order than the method-specific-id. You could probably make this work with certain constraints, such as all colons in the method-specific-id are always turned into slashes before evaluating the denom and the reverse. However, if you're going to always convert / to : (and back) to make sure DIDs are always correct, then we probably would be better off just using colons so no transformation (and related) errors never happen. Note that if we have a requirement to support slashes in denoms, then I think we're stuck with either a conversion layer or percent encoding when those denoms get put into a DID. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if there's a technical reason not to allow
|
Beta Was this translation helpful? Give feedback.
-
|
I would expect that denoms are on-chain assets and, as such, would be representable by IIDs and IID Documents, so a given denom would likely have a did like Which, when resolved, would return the cryptographic material for interacting with that denom such as how to mint (service endpoint) and who controls the denom (verification method). And on an application chain that wants to use the bank module for tokens, that would be replaced with "bank" or whatever identifier is used to refer to that module uniquely on that application chain. Of course, you can still escape or convert so that /denom/subdenom becomes DID compliant: or [assuming there are "subdenoms", otherwise, I don't know why a denom would have a I'm not sure the syntax of Is Could you give an example DID that has |
Beta Was this translation helpful? Give feedback.
-
|
I think we should be more prudent about mapping. Designing for DID has lot of advantages and it's not complex. We just need to agree on ID scheme. |
Beta Was this translation helpful? Give feedback.
-
|
Minting needs to be possible on the keeper of whatever module is storing the NFTs. It should not be executed by the handling of any Msg. It should be able to be imported into custom modules that handle the logic of minting on custom chains, or on the Hub, it should only be imported by the NFT-IBC module. Users should not be minting on the hub, just the IBC module. I don't understand why any of this benefits from being imported into the bank module. When you run a command like Permissions around controlling the keeper of the NFT module should be custom built by each blockchain for their own purposes. This includes updating the URI, minting, burning, transferring etc. The whole point of not blocking this work on DID and IID was that it's too complicated to try building that now. The purpose of this discussion is to ship a simple NFT module ASAP and that means the simplest version that satisfies IBC and users can take as starting points for their own purposes. |
Beta Was this translation helpful? Give feedback.
-
|
An NFT ID wouldn't begin with a |
Beta Was this translation helpful? Give feedback.
-
|
Also, my sense is that the current proposal is a simple and quick way to deliver functionality in a way that allows DID/IID and more permission rules to incrementally be added. |
Beta Was this translation helpful? Give feedback.
-
Using x/bank for mintingFollowing above discussion about updating x/bank for doing more convenient minting. #9065 (comment), #9065 (reply in thread), It's very easy and IMHO we could enable that API at the keeper level and later design for service level if needed. It's been shown that it's easy: #9537 Aaron, shall we PR that into bank? Does anyone is against it? |
Beta Was this translation helpful? Give feedback.
-
|
For clarity - this is only for internal purposes. For the proposed NFT use-case, minting will be only offered by an NFT module, and under the hood it will use x/bank minting capabilities. |
Beta Was this translation helpful? Give feedback.
-
Use or not use x/bankIt seams we don't have clear buy out to use x/bank for NFT book keeping. @okwme is proposing to move back to the standalone nft module. #9329 (comment) In a post above, I've outlined the motivation and advantages of using x/bank for being a balance book. I want to repeat that we don't need any change in x/bank to use it with other modules as a balance book, which has been shown in this NFT implementation: #9603. That being said it's good motivation to make the bank keeper more friendly. Using x/bank doesn't mean that we can't have customization. Even opposite! An NFT module should be able to build on the x/bank and provide more functionality. The key here is to reuse the x/bank rather then copying and reinventing a wheel. Moreover we all talk about hooks, and that would be again another perfect use-case to use hooks. I haven't seen any valid technical case where x/bank would be a blocker or an obstacle. So let's rise them here - this will be useful for all future asset related modules. @ig-shaun , @haifengxi, @iramiller - you were reviewing the ADR proposal and were implementing nft module. Would you like to share your feedback on x/bank approach? |
Beta Was this translation helpful? Give feedback.
-
|
I think the reason to have a module in core is that interoperability is core to what Cosmos is about, and that means NFTs as well as denoms. I think it could be in IBC core instead, but I think we should be thinking primarily about cross-chain movement, I don't think minting is a particularly hard problem anyway. |
Beta Was this translation helpful? Give feedback.
-
The client side impact is probably the easiest to resolve. It's trivial to a) add a nft module that wraps bank but exposes CLI interfaces, gRPC queries and even transactions that expose information in the way expected by NFT users and b) to add any metadata needed in bank to support this. Some of this is just proper naming conventions. I think it's mainly a proper separation of concerns between the underlying data model and the user-facing APIs and UIs. Basically, I don't think a data store should be refactored as a means to resolve UX concerns if the data store has good reasons to be designed as is. Stuff like type/id vs denom, total supply, etc. can and should be resolved at the API/UI layer in my opinion.... But like I said I'm not going to force that on people since I also see that it's a really unpalatable solution for some of the NFT community... |
Beta Was this translation helpful? Give feedback.
-
|
On the other hand - I don't see how 2 different NFT modules will be composable if they don't use a common asset registry? The messages will look the same and will have the same attributes. But the types will be different. So IBC will have another challenge - how to unify messages from different chains and different types? Example: I want to receive an asset / nft A from chain C1 module M1 and asset B on same chain but module M2 (both are NFT modules). |
Beta Was this translation helpful? Give feedback.
-
|
I think that's always going to be the challenge, we want an IBC approach that any NFT chain (e.g. Solana, Tezos) can implement and have it work. |
Beta Was this translation helpful? Give feedback.
-
|
Well, we should make it should be easy for Cosmos chains at least. |
Beta Was this translation helpful? Give feedback.
-
|
As a completely separate thread I want to point out that this extensive discussion, the deep thought, and overall effort that many people are putting into this design process is an exceptional example of the high standards of quality that the Cosmos SDK community strives for. I personally want to thank everyone involved for their efforts. Regardless of which way this initiative goes I am confident that the approach taken will be well reasoned and of high quality. |
Beta Was this translation helpful? Give feedback.
-
|
has there been any movement on this since July? |
Beta Was this translation helpful? Give feedback.
-
|
@gotjoshua yep! Most of the work is being tracked on Zenhub in this issue as an epic: #9826 |
Beta Was this translation helpful? Give feedback.
-
|
Is there a final update or decisions being made in the background by the Cosmos team here? I'd love to be able to release an NFT market for my Tendermint SDK / Starport chain, and get a little instruction / tutorial video on NFTs for Cosmos chains. Once we get an interchain NFT marketplace, it could be a huge competitor to OpenSea. |
Beta Was this translation helpful? Give feedback.
-
|
This thread is about deploying an NFT module on the Cosmos Hub. The module itself is complete (we're just doing final QA), so the Tendermint team is free to add it to Starport. Or you can add it to your application manually. |
Beta Was this translation helpful? Give feedback.
-
|
The module is implemented in Moreover there is ongoing discussion for the ICS standard: cosmos/ibc#615 |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
NFT module on the Hub
Motivation
The Hub in its current state serves as a transport and safe storage layer for tokens generated by the IBC enabled chains connecting to it. Given the current explosion of interest and use cases in the NFT space, the Hub should also enable a unified mechanism for storing and sending the ownership representative of NFTs generated through the IBC enabled interchain ecosystem. This discussion presents the current implementations as options to be implemented on the Hub to enable NFT transfers through it.
Current Implementaions
modules/incubator/nft
The module available at the repo https://github.com/cosmos/modules/tree/master/incubator/nft is probably the oldest implementation of an NFT module in the cosmos repository, with reasonable amounts of contributions from the community. It defines NFTs as self-contained objects identified by an id string; ownership is represented through the owner accAddress field and has a URI string for metadata. The NFTs are classified through a denom string identifier and grouped in a collection(array of NFT ids). The ownership of NFTs is also represented through an Owner object that acts like an account/wallet mapping NFT collections to an address.
Pros
Cons
CW721
The smart contract available at https://github.com/CosmWasm/cosmwasm-plus/tree/master/packages/cw721 is probably the easiest migration path for migrating ERC721 NFT use-cases to cosmos hub. CW721 is an implementation of the ERC721 NFT interface in Rust for cosmwasm. The repository also implements rust contracts for other NFT interfaces.
Pros
Cons
DID NFTs
The RFCs available at https://github.com/interNFT/nft-rfc defines a way of creating NFTs as a family of DIDs called IIDs. IIDs are DIDs with an additional field called linked resources which point to service endpoints to get NFT metadata.
Pros
Cons
interNFT
The modules are available at https://github.com/persistenceOne/persistenceSDK defines an NFT standard called interNFT with identity-based NFT wallets and an NFT DEX.
Pros
Cons
Simple proposal(not finalized, needs discussion)
All the approaches defined above require some significant Hub changes with a difficult and stretched out upgrade path. This method aims to enable NFT transfers over the Hub with the smallest delta:
Basic Requirements
Wallet
Transactions
Beta Was this translation helpful? Give feedback.
All reactions