🔭 Conform Guardian generated NFTs with HIP412 for better ecosystem-wide compatibility for NFTs and wallets

[mattsmithies]

Problem description

Currently, Guardian-generated NFTs use a proprietary metadata Guardian, this is fine, if we want to align ourselves with the members of the NFT and wallet ecosystem we should integrate HIP412.

Note: this specifically effects guardian NFTs, rather then FTs.

@mattsmithies can help advise Guardian team on getting assets HIP412 compliant.

Why this matters

In a sentence, the UX that downstream consumers that purchase carbon assets must be good.

When we expect carbon or similar environmental assets (biodiversity) to be generated and transferred to the wallets of network users on Hedera there will be an expectation of these assets being sold on external markets at a later time. This specific usecase is on assets that aren't retired at point of sale on given marketplace.

Currently, DOVU provides a marketplace that retires carbon for every sale but we will be moving to decoupling the carbon retirement process, as well as moving to a retirement architecture that includes lifelong analytics.

The issue is when NFT assets generated from the Guardian are transferred to a wallet the lack of HIP412 integration means that end users have bad experience when viewing.

Examples:

This screen displays the collection of NFTs, in this case tons of carbon transferred to a wallet where each tonne is one NFT.

This next screen displays a single NFT, from the collection that is a tonne of carbon.

This next link is of gomint's NFT explorer, which renders from the HIP412 schema.

Requirements

1. Define senisble defaults for all NFT Guardian assets that is the minimum implementation of HIP412 (@mattsmithies can advise on tooling or a method to support)
2. Move the generated of the current metadata to the "properties" field of the HIP412 Specification
3. Allow marketplaces to change the defaults for their specific needs on the creation of tokens and more importantly the mint of assets.

Definition of done 🔥

All guardian NFT assets should conform to HIP412, to enable wallets and external services to injest the information to render.

An example of a valid NFT is this Carbon Certificate DOVU issued to Swirlds for the Davos event, we can pull from a mirrornode to extract the data to infer and write automated tests against.

Acceptance criteria

• A standard registry can transfer NFT assets and view them in Hashpack (HIP412 compliant wallet) with a placeholder image
• A standard registry can set the following fields for the mint of a guardian NFT asset
  • Name
  • Creator (standard registry)
  • Description
  • CID (from the upload of an image from nft.storage, web3.storage or others)
  • Type (image/png or video/mp4)
• A user that gets NFT carbon assets transferred to an account, will either see sensible defaults or the
• As a developer using the guardian I can run an automated test that can check that a minted NFT conforms to HIP412.

Appendix

For DOVU we built/utilised the Trust Enterprises NFT ecosystem using the Inky Art Club admin panel as a frontend minter for the Swirlds Certificate for Davos.

[mattsmithies]

To add to the discussion with myself and @paulmadsenhbar, this is my recommendation for adding the timestamp that was previously the metadata of the NFT within the context of the 412HIP schema, hosted as immutable JSON.

{
    "name": "Redhill Farm Mint (timestamp)",
    "creator": "DOVU / Standard Registry",
    "description": "This is an example NFT metadata",
    "image": "ipfs://xxx",
    "creatorDID": "did:hedera:mainnet:7Prd74ry1Uct87nZqL3ny7aR7Cg46JamVbJgk8azVgUm;hedera:mainnet:fid=0.0.123",
    "type": "image/png",
    "properties": {
        "timestamp": "1673611484.886700772"
    }
}

[voycey]

I think this looks great - as long as the timestamp remains intact so we can maintain traceability!

[Neurone]

A quick integration can be to use the timestamp as a postfix of the CID/IPFS URI/HTTP URL, like this:

ipfs://bafkreig3umd2kxuwnr55czm5bgjlndgk2bp5ehxjjcrnbfavwn4fuekfru#1696418367.204714003

bafkreig3umd2kxuwnr55czm5bgjlndgk2bp5ehxjjcrnbfavwn4fuekfru#1696418367.204714003

That postfix would be ignored by regular clients, while the Guardian clients can still decide to follow the traditional chain or to get also the additional parameters from the additional HIP412 JSON file.

0.0.4475681 is an example of 4 NFTs with two normal metadata fields (CID and IPFS URI) and two customized ones (attached timestamp after #).

I tested some of our existing tools (HashPack, Mintbar, etc.), and they recognize those 4 NFTs without problems.

Please note the metadata field max size is 100 bytes, so this additional 21 characters (# + timestamp) are not a problem for CID or IPFS, because they have a fixed size. Even with the new IPFS CID format, which is 13 chars longer than the previous version, that is not a problem because we reached 87 total chars size for the metadata.

Those 21 additional characters are something to be aware of if you want to use a URL instead because it does not have a fixed size and can overflow the 100-bytes max size.

Let me know if you experience or can think of any problems by the broader Hedera community side.

Suppose that works on the broader Hedera community side, we can start thinking about the implications of supporting this new metadata format, what's the best way to parse it, and to support the previous timestamp-only format.

[mattsmithies]

@Neurone, great call on using the hash to separate the IPFS CID and timestamp—it's a straightforward yet effective approach.

I see no obstacles in adopting IPFS as the default memo for external services. Preliminary tests on NFT marketplaces should confirm this, as they typically fetch from an IPFS gateway.

For our next steps, let's align with HIP412@2.0.0 + ESG as our standard. Key points to include:

• Document the method for splitting IPFS CID and timestamp.
• Discuss adding a 'guardian_timestamp' property.
• Include a 'esg_explorer_url' for deeper ESG asset insights.
• Specify required and optional HIP412@2.0.0 properties, considering 'creatorDID' for suppliers/verifiers.
• Debate whether to restrict to IPFS or include IPNS, considering mutability risks. (probably IPFS only)
• Discuss initial attributes, led primarily by Tolam (@CyndyMo).

As @rocketmay pointed out, while other chain standards exist, starting with HIP412 and evolving it may be our best strategy given the nascent state of ESG tokenization.

Does this cover everything needed to move forward? cc. @dubgeis @anvabr @prernaadev01

[prernaadev01]

@mattsmithies Thank you for the detailed information. We will discuss it internally once and get beck to you asap.

[Neurone]

Hi everyone, May correctly raised some concerns about not being 100% compliant with the IPFS syntax: while using the hash works fine for the HTTP gateways, it can result in problems with CLIs or other clients trying to interpret that CID.

So, after some brainstorming, I think we can still use the same technique but leveraging folders and files this time.

We can use the timestamp as the name of the JSON file and store it as it's inside a folder, hence getting a final URL like this:

ipfs://bafybeifrq5pf4cxqmmqmtx64nl5lex6ix4vyerypzbsncmb43a72d6ubjy/1696418367.204714003

Essentially we use / instead of #, but this time we stick with something IPFS can understand by default.

This correctly separates the CID and the path and - on the contrary to using the hash - this works for example also with the IPFS CLI:

❯ ipfs get "bafybeifrq5pf4cxqmmqmtx64nl5lex6ix4vyerypzbsncmb43a72d6ubjy/1696418367.204714003"
Saving file(s) to 1696418367.204714003
 185 B / 185 B [==========================================================================================

I would stick with the ipfs:// prefix anyway, just to be more specific and to improve readability by external users.

Gaurdian-enabled applications can be instructed to read only the last 20 chars of the metadata field, and then proceed normally.

[CyndyMo]

From this morning's Vocab call, an initial list of attributes:

1. Asset type (CRU, REC, etc)
2. Method (Avoidance, Reduction, etc)
3. Sector (Renewable Energy, AFOLU, etc)
4. Project Type
5. Methodology
6. Geography (country to start)
7. Vintage
8. Co-benefits

[mattsmithies]

@CyndyMo thank for the list, do you think it might be a good idea to add Methodology Developer/Author/Registry so then we could say that it is from an AMS UN/Verra/GS or something else. This would provide us the capability to understand which NFTs/underlying assets have methodologies based from a particular overarching registry.

Let's collaborate together on a document that illustrates all the different options that can go into the different attributes.

From here, between, @Neurone's IPFS format for ESG and the list of attributes (with available properties), I believe we would have enough to start spec'in out a the HIP for enhancement.

I will define some additional fields with the properties like the guardian_timestamp, perhaps a root level identifier that it is a ESG asset, so that (NFT) marketplaces have the capability to differentiate, and maybe a reference to ledgerworks or marketplace of origination for more information.

[mattsmithies]

Hello, all, this is the first pass of this HIP, I think it is best to share it and comments accordingly, before we formalise it as a proper HIP for Hedera. https://docs.google.com/document/d/1Cg0vk4bPL4nUjAkO6rAKIe4kd92GxuICTqc3EgLWafU/