# interNFT working group call #12

## Agenda
* Introduction: 5'
* Background: 10'
* DID refresher: 10'
* interNFT core: 10'
* RFC walkthrough: 5'
* Comments from the WG: 5'-∞

## Introductions
|name|project|interest|
|-|-|-|
|Parth|Memora|Bring InterNFT to Defi
|Michael|Stargaze|ICS721 working group
|Vishwas|Hypersign|How InterNFT can be used for DIDs
|Ganesh|My Own Internet|Usecases with InterNFT
|Jake|Axelar Network|Reseach on Interoperable standards
|qedk|Polygon, Gitcoin|Research and Learning
|Shachindra|Lazurus Network|Integrate CosmosSDK and Research on InterNFT

## Background
* [Working group details](https://github.com/interNFT/documentation/blob/master/markdowns/groupDetails.md)
* Duration: 4th September 2020 to 18th March 2021
* [Minutes of meeting](https://github.com/interNFT/documentation/blob/master/markdowns/meetings.md)
* Roadmap
* interNFT implementations: AssetMantle
* Cosmos NFT module
* Other NFT Standard implementations in Cosmos: [ICS721](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-043-nft-module.md), incubator/modules/nft, CW721
* Other NFT Standard implementations: ERC721,ERC1155, ERC994, ERC1410, ERC809, ERC998

## DID Refresher
* components:
* DID+DID url
* DID Document
* DID resolver
* DID URL dereferencers
* DID method
* DID subject
* DID controller
* Verifiable data regitry

## interNFT core
### Identified Usecases
* Collectible Tokens
* Financing Tokens
* Impact Tokens
* Access Tokens
* Art Tokens
* Physical Property Tokens
* Data Tokens
* Credential Tokens
* Capability Tokens
* Commodity Tokens

### Requirements
1. **Mintable** to issue new tokens of the same class to a token set.
2. **Burnable** to remove tokens from the token set.
3. **Ownable** to control the token metadata using a private key.
4. **Transferable** to change ownership.
5. **Non-transferable** to not permit changes in ownership.
6. **Lockable** to conditionally stop changes in the token metadata.
7. **Immutable** to never permit changes in the token metadata.
8. **Mutable** to unconditionally permit changes in the token metadata.
9. **Fractional** to mint fungible tokens which represent fractional ownership of non-fungible parts.
10. **Composible** to be owned by another non-fungible token and added to that token’s set or to produce other novel combinatorial forms.
11. **Conditional** to only permit changes or transfers when specific conditions have been met.

| | **Requirements** | | | | | | | | | | |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| **Use-Case** | **1** | **2** | **3** | **4** | **5** | **6** | **7** | **8** | **9** | **10** | **11** |
| Collectible Tokens | X | | X | X | | X | X | X | X | | |
| Financing Tokens | X | X | X | X | X | X | X | X | X | X | X |
| Impact Tokens | X | X | X | X | X | X | X | | X | X | X |
| Access Tokens | X | X | X | X | X | X | X | X | X | X | X |
| Art Tokens | X | | X | X | | | X | X | X | X | X |
| Physical Property Tokens | X | X | X | X | X | X | X | X | X | X | X |
| Data Tokens | X | X | X | X | X | X | X | X | X | X | X |
| Credential Tokens | X | X | | X | X | | X | | | X | X |
| Capability Tokens | | | | | | | | | | | |
| Commodity Tokens | X | X | X | X | X | X | X | X | X | X | X |
| | | | | | | | | | | | |

## RFC Specification [ref.](https://github.com/interNFT/nft-rfc)
* NFT-RFC-001 Specification Standard for Interchain NFTs and Metadata
* NFT-RFC-002 Use Cases and Requirements Working Document
* NFT-RFC-003 NFT Interface
* NFT-RFC-004 interNFT Standard
* NFT-RFC-005 NFT Rights
* NFT-RFC-006 NFT Identifiers (IIDs)
* NFT-RFC-007 NFT Layers
* NFT-RFC-008 NFT Assertions
* NFT-RFC-009 Interchain Identifiers

## Comments from the WG:
* Is Shaun still working on IIDs?

On 18th March, after having the last call, this particular working group was commissioned by InterChain Foundation. ICF took a call that the initial requirement was to implement an NFT standard that would define the majority of the use-case that we can find in Cosmos. Then the use case changed and it was to implement the base minimum implementation that can go to the cosmos hub via the NFT module. The working group was henceforth split into two. One to define the base NFT module and the other one to work on the DIDs. The work is continued in the following repository - https://github.com/EarthProgram/did-cosmos

* How is InterNFT different or better than ICS721, CW721, and ERC721?

CW721 and ERC721 are NFT standards that have been implemented with smart contracts in mind and not interchain module-based implementation for NFTs or NFTs that can interact with applications on the other chains. CW721 and ERC721 are more focused on the use-cases that can interact with other smart contracts and not the chain. With respect to CW721, the requirement was to build a module that would be the minimum and simplest implementation of what NFT should look like in the cosmos ecosystem. The module should be untainted by specific use-cases.

* Does InterNFT allow NFTs to move across chains?

The exact reason to adopt DIDs was that the metadata associated with the NFTs could be variable and that the size of this metadata could be quite big. In some cases, the size could be bigger than what a block could accommodate in a NFT mint transaction or an IBC transfer transaction. The volume of metadata could not be accommodated in the following in some cases.
The metadata is implemented as a DID document while the ownership of the metadata is represented as a DID itself(DID identifier string). The metadata sits on the native chain itself. Since the ownership token is as simple as CosmosSDK coin for reference, the current implementation of IBC can be used to transfer the NFT ownership tokens without any changes in the IBC implementation.

* Does it allows transfer between chains with on-chain metadata only?

Any chains that support CosmosSDK coins and have IBC enabled can transfer the NFT ownership. The slight difference is that the demon will carry the DID notification. So some of the chains might not be able to differentiate normal coins with NFT's DID.
In the future when an IBC resolver is implemented which can query metadata, we can operationalize more functionality and features around the host chain of the transferred NFTs.

* Will this implementation work with two chains with on-chain metadata? Will AssetMantle be able to transfer to some other chain with on-chain metadata?

The onchain metadata will never be transferred. Only the ownership token will be transferred.
Even in a scenario where even if both the chains implemented the document module which goes through DID documents, the on-chain metadata will not be transferred. The idea is that the specific logic to operationalize the metadata will sit on the issuer chain and assuming only the issuer chain knows how to operationalize the metadata, the metadata is never transferred.
An IBC DID resolver could be used by other chains to identify the DID and be able to use the DID URI to reference some of the metadata over IBC.

* Assuming InterNFT was operationally on one chain, can it communicate with a chain that has partially implemented ICS721?

Irrespective of any chain that communicates with ICS721, the interNFT specs are that we would be utilizing the bank module itself to issue the ownership tokens with demons as DID and amount as the smallest deck if it is non splittable NFT and a decimal if it is splittable NFT. Any chain with a bank module should be able to receive this NFT. With ICS721 the NFTs would indirectly be interoperable with InterNFTs. ICS721 spec says that an IBC transfer of an NFT would transfer the metadata as well to the other chain. The transferring of the metadata to the other chain may not be the best idea as it could be an attack vector where chains can spin up and transfer over a large amount of metadata and increase the state size, reducing query and transaction speed.

* Is there a reason/use case where someone will use InterNFT over ICS721?

There are 6-7 ERC(ERC1155, ERC-223,ERC-827, ERC777 etc) standards but we all stick to 721 because it is the most used standard.
From a technical perspective, transferring the metadata over to another blockchain could be an attack vector.

* There could be confusion over ICS721 implementation NFT and InterNFT implementation of NFT. Someone can act maliciously to exploit it or accidentally have two representations of the same NFT.

At a core level, ICS721 wallet will look very different from InterNFT wallet. ICS721 NFT will require a more specialized wallet. So there is enough differentiation in the UX/UI for people to differentiate.
One of the main aims of this working group is to implement a standard to incorporate the majority of the usecase that projects are building NFTs around into one standard that we all can use. It can go onto the standardization track to contribute back to ICS721 or CosmosSDK.
There are some use-cases that cannot be solved with the current implementation of ICS721. Some use-cases like Ixo's impact bound use-case, comdex's shipfi, carbon credit use-cases, AssetMantle use-cases etc cannot be solved with currently existing implementations of NFT. Henceforth new standards will emerge to solve them in any case.

* There should be some kind of a way for ICS721 and InterNFT to communicate

This use case will be added under the requirements and try to solve this particular aspect.

* Multiple standard of NFTs are not necessarily considered an attack vector

More than the attack vector it could cause confusion. A bunch of use-cases will be implemented by future projects and if there is no standard to solve it, new standards will emerge regardless.
The biggest problem is about which use-case to include and if it is implementable with InterNFT standard.
At the end of the day, the use-case of implementation is to solve a particular problem. If not, new projects will be implementing variations of standards.

We did account for all the use-cases that could come up in the NFT RFC008.

* In order for InterNFT to work across chains, does IBC resolver needs to be implemented?

The IBC resolver needs to be implemented is to be implemented when metadata transfer ship is required. Use cases like mortgaging NFTs and putting it on Dex will be possible without relayer. You can do an ownership transfer.
Trading metadata and operationalizing its properties will not be allowed without relayer.

* How is metadata separated from NFT

Similar to how DIDs separate the metadata from the identifier.
Let's say x is the DID subject. The DID document is just metadata about the x. NFT is an object that is not the DID or metadata but rather DID is pointing towards the NFT and metadata is defining the NFT.