Big blob and icrc7 nft

Hey guys,
We are implementing a icrc7 nft, with “infinite” storage scalability. But here, lets say we want to upload a big file (as a Blob) to the canister, what is the good pratice here now on dfinity ?
Do we have any lib to handle the chunks ? How would you design this?`

Edit : Is assets storage canister code opensource?
Thanks!

I think @Vivienne you are working on it, right ?

Icrc-7 is not designed to handle large/infinite data. For that you need ICRC-56. ICRC/ICRCs/ICRC-56/readme.md at icrc56 · skilesare/ICRC · GitHub

This is just a draft and pair the existing asset canister api patter with Origyn-nft storage schematics which are generally available and published here:

Bluntly icrc-56 needs community review and updating to incorporate verification v2.

You can’t really put unlimited blobs in metadata and an icrc exists to provide a hash and to point to the file elsewhere(obvious tie in to 56 would make sense with a standard https schema that matches with 56 structure as demonstrated by Origyn-nft but without needing the protocol proxy.). 95% is already in the nft, just needs standardization and then refactoring.

See Reserved For Large Metadata Handling in Transaction Logs · Issue #61 · dfinity/ICRC · GitHub and Proposal for initial best practices for ICRC7 metadata · Issue #76 · dfinity/ICRC · GitHub and ICRC-97: Non-Fungible Token (NFT) Metadata Standard · Issue #97 · dfinity/ICRC · GitHub

Here is the asset canister code, and here is a description of the interface. The thing that does the upload that we have is icx-asset or the ic-asset crate if done via dfx.

ICRC-7 by itself does not specify metadata and assets, there’s ongoing discussion around ICRC-97 regarding metadata, where assets are referred to by URI within the metadata.

If the file upload itself doesn’t need to be standardized, then any custom batch of chunks flow will suffice.

Most straightforward approach would be copying what the asset canister does, as suggested by @Vivienne, but you might want to implement additional permissions, rules etc for your use case.

Thanks !
Can you update candid dependencies in this crate ? crates.io: Rust Package Registry Please ?

edit : Looks like the right way to do it now is to use ic-asset-certification ?

Yes as seen here: sdk/src/canisters/frontend/ic-frontend-canister at master · dfinity/sdk · GitHub

Not sure to understand,
ic_certified_assets has not been updated since 2 years now, and on this topics : Announcing the HTTP certification library for Rust - #14 by unixway Severin said it’s not up to date anymore and we should use ic-asset-certification, which is not yet released AFAIK.

looks like this part is currently been reworked, right ?
Basicly what i’m looking for is the crate to handle the upload/get of the (potential big) file to a specific canister, ideally compatible with icx-asset (and a js lib) so we dont have to re-invent the wheel.

Thanks !

It looks like this might not use stable memory yet :confused:

So you’ll likely be limited to the heap memory, for a website of only a few gb that might be fine. But for larger file storage purposes you might want to opt for something else.

Maybe the following project might be an alternative: Improving the Stable-FS: Enhancements and Optimizations for Better Performance

Keep in mind this does not implement chunk uploading and http_request so you’ll need to combine both projects manually.

See @dfinity/assets for a js lib and the crate is available already at crates.io: Rust Package Registry

1 Like

Ah thanks !
For some reason i didnt found it earlier, maybe typo error on my side.
I’ll try to add this to my project. Thanks again ! I’ll come back here to put this as solution if i’m able to do it :pray:

ic-asset-certification is already released and working

do you have a public repository where you are using ic-asset-certification ?
Looks like it’s only define some type, but the method requiered here : sdk/docs/design/asset-canister-interface.md at master · dfinity/sdk · GitHub are not defined ?

We have not released it yet.

However, based on your original topic, it seems to me that it would not solve your problem. The purpose of this library (ic-asset-certification) is to certify assets without the hassle and boilerplate code of the original ic-http-certification. It does not provide a way to upload or store assets.