ICRC-16 - CandyShared - Standardizing Unstructured Data Interoperability

Developers
,
21

My mistake, I am only deploying a regular NFT. For some reason I thought ORIGYN/you were behind the pan-industrial account.

Thanks so much for the detailed response Austin, but ORIGYN NFT is to complex for my purposes. For now, I’m getting away with overriding the mint when I need to change metadata.

22

No problem. You may want to take a look at ICRC/ICRCs/ICRC-60 at icrc59and60 · skilesare/ICRC · GitHub which is the current proposal for Mutable NFTs. We are a long way from getting it dialed in, but hopefully it will give you some things to think about such that you don’t paint yourself into a corner.

I believe I’ve used the “overload mint” as well in some of my tests. We had some discussion in the WG if that was an ok thing to do and if there should be a new mint record in the transaction log or not.

For the Pan Industrial implementation, there are two ways to update:

set_nfts completely overwrites your data with what you provide: icrc7.mo/src/lib.mo at b3982e95a310484c62402d1069696ad46752e4f9 · PanIndustrial-Org/icrc7.mo · GitHub. If you have never minted the nft provided it will get minted with the metadata you provide.

update_nfts icrc7.mo/src/lib.mo at b3982e95a310484c62402d1069696ad46752e4f9 · PanIndustrial-Org/icrc7.mo · GitHub uses the Candy UpdateProperties method, so you can provide transforms, but this only works if your top level metadata is a #Class. When you return the metadata via icrc7_token_metadata this Class will be downgraded to a Map and conform to the standard.

There are some simple examples in icrc7.mo/test/lib.test.mo at b3982e95a310484c62402d1069696ad46752e4f9 · PanIndustrial-Org/icrc7.mo · GitHub

Note: there is a current outstanding bug in ICRC-37 that needs to get resolved: "icrc7_tokens_of" shows token belonging to twos principals after "icrc37_transfer_from" · Issue #3 · PanIndustrial-Org/icrc_nft.mo · GitHub

If that is a blocker for you, let me know and I’ll try to get it fixed as soon as possible.

1 Like
23

Yes. This is what I was attempting and struggling with. Nonetheless, I’m content moving forward with override minting. Did not know about icrc60 but icrc7 took 18 months to finalize so I’m not going to hold my breath.

That issue is going to be a problem for me, but not urgently. I have plenty more to do before taking this into production. I’ll be stress testing and maybe find more issues. I’d offer to fix the but I only work in rust and this is my first motoko exposure. I just switched from the rust icrc7 implementation because this is more established.

24

I want to extend the ICRC-3 hash schedule/table.

What do you guys think about this?

// func hashValue
// ... Nat, Int, Text, Blob, Array, Map
case (#Bool b) sha256.writeBlob(leb128(if (b) 1 else 0));
case (#Principal p) sha256.writeBlob(Principal.toBlob(p));
case (#ValueMap map) { // ValueMap: 
  var hashes = RBTree.empty<Blob, Blob>(); // rbtree for key sorting
  for ((k, v) in map.vals()) {
    hashes := RBTree.insert(hashes, Blob.compare, hashValue(k), hashValue(v));
  };
  for ((kh, vh) in RBTree.entries(hashes)) {
    sha256.writeBlob(kh); sha256.writeBlob(vh);
  };
// ...
sha256.sum()