Yes, the metadata section can be customized with arbitrary sub-sections (private or public); beyond that, I’m not aware of any standard being enforced for which metadata subsections. (Some tools, e.g., DFX, seem to be creating their own metadata standard within a particular metadata subsection, e.g. icp:public dfx, followed by a string in JSON notation).
Speaking of DFX, it has a nice feature for reading the metadata section of a deployed canister, e.g., the following git_commit_id metadata sub-section:
dfx canister --network ic metadata $CANISTER git_commit_id
I’m pretty sure one could read the metadata via an agent library, but I’ve not tried that with agent-js.
Note that a matadata section of a compressed (gzipped) WASMs is itself not compressed.
A great metadata entry that I would recommend to add to any canister is candid:service, pointing to the canister’s Candid definition.
Thanks for the answer and confirmation. Is there is any limitation such as size or types? Any specification available somewhere?
That’s the second important aspect of my question. I would be really curious to know about this as it would be an interesting reason why I would foreseen the use of those metadata sections.
@aterga mentionned that dfx seem to be creating particular metadata, so it’s 16 counting does already used by dfx or it’s minus those? if minus, do we know how many sections dfx is using?
Do I get it right, the argument paths should then be used as the key?
e.g. given a public metadata “hello:world”
$ ic-wasm input.wasm -o output.wasm metadata hello:world -d "that's my value" -v public
Yes, metadata made by dfx are counted towards the 16 limit. I think you can opt-out this behavior in dfx.json. I think dfx only add 2-3 metadata sections. You can check it by running ic-wasm a.wasm metadata to list all metadata in a wasm binary.
Do I get it right, the argument paths should then be used as the key?