@diegop any help here? I’d like to enumerate subnets and scan canisters, but it’s unclear from the Candid for the registry canister how to do this.
For context Azle and Kybra canisters now have public metadata sharing that they’ve been created with Azle or Kybra at a certain version, and we want to start tracking live how many canisters of each are actually deployed. Will probably be our best metric to measure our own adoption.
@mraszyk shared this repo with me: GitHub - mraszyk/sexp: Subnet Explorer. This seems to be the crucial line: sexp/src/main.rs at main · mraszyk/sexp · GitHub
Please checkout the branch: GitHub - mraszyk/sexp at mraszyk/only-canister-ranges and follow the README to enumerate all subnets and its canister ranges.
@lastmjs were the responses presented helpful? (I admit I did not click through and try them out)
Very helpful, thanks everyone!
@mraszyk I’ve created an issue in the repo but am also posting here for more visability: Effective canister id in URL orcis-3qaaa-aaaad-qaaaa-cai does not match requested canister id: zsumk-yqaaa-aaaad-p34ya-cai.) · Issue #1 · mraszyk/sexp · GitHub
I keep getting errors about the effective canister id not being the same as the canister id in the state path…I’m not sure how batch requests can ever be made to the state tree if the effective canister id has to match each path. Does anyone know the answer to this?
I’ve replied on the issue.
I think it would be helpful to continue this discussion here.
So unfortunately the batching technique doesn’t work anymore because the effective canister id in the state tree path must march the effective canister id of the request, which seems to make grabbing many state paths for different canisters not possible with one request.
Does anyone know of another way to batch these kinds of requests? I want to get some public metadata for all canisters and doing an individual request for each one is undesirable.
@lastmjs Would it be possible for you to use our IC Dashboard: Canisters - IC Dashboard or do you need the information to be up-to-date (the dashboard loads the data from a cache) and have the module hashes and subnet IDs available all at once (not sure if this can be achieved by crawling the IC dashboard with a script)? In the latter case, we would need to reenable batching the paths /canisters/<canister_id>/module_hash and /canisters/<canister_id>/controllers for multiple canister IDs in the replica code.
My end goal is to be able to count all Azle and Kybra canisters on the IC, and it would be great to count all Rust and Motoko canisters as well. The way to do it is by reading a custom metadata section. Azle and Kybra canisters now provide a custom metadata section describing the CDK. It would be neat if all canisters did this eventually.
So, ideally IC Dashboard or other indexers would just do this work for us as they index canisters. Is that something you’d be interested in?
To sum up, indexers could provide this information for each canister and for the IC as a whole, and people could filter through all Rust, Motoko, Azle, Kybra, etc canisters.
Custom metadata sections cannot be fetched for multiple canister IDs in a single read_state for the sake of DoS prevention (every canister can have a custom metadata section of size up to 1MB). Hence, to get the custom metadata sections of all canisters, you’d need to query them one by one or use a dashboard that caches that information.
Cool idea. Yes, if there was a standard way that canisters identified their source code language in the custom metadata section, the IC Dashboard could save that as a property of the canisters and then use it to filter or sort the Canisters table.
All we need to do is come up with the convention then. I’d like to get this conversation started. I don’t think it should be the source code language though, but the CDK name, considering there could be many different CDKs per language.
Thoughts?
Good point, the CDK name makes sense.
would really love an up-to-date method of doing this, been trying to figure it out for the past day without much luck
how can you determine when to stop the iteration(checking next canister id)? what happens when canister is deleted?