Candid equivalents for protobuf endpoints on the nns registry canister?

Developers
1

I’m looking to replicate some of the ic-admin tool functionalities from a canister, to eliminate the need to run off-chain crons to collect various data.

Specifically, the get-subnet-list and get-subnet commands.

I noticed that the ic-admin tool calls a get_value endpoint on the registry canister that accepts different keys, but that this endpoint’s arguments are protobuf encoded, and the endpoint isn’t explicitly documented in the candid.

Are there any plans to expose open candid interfaces for these API endpoints too?

5 Likes
2

I don’t think so. I don’t think we are against it either though.

In general, please, let us know if you plan to call any methods that are not mentioned in the .did file. There is a good chance that such methods are not intended for general consumption.

1 Like
3

This general purpose get_value endpoint on the registry canister. I’d like to be able to query all current subnets & associated metadata such as subnet type, authorization, and specialization from a Motoko canister, instead of needing to use a tool like ic-admin and then backfilling that data to my canister.

4

Thanks. I am thinking of making some slightly breaking changes to that. I’ll let you know soon when the proposal is more precise. You might not be affected; it depends on which keys you query. There will most likely be a nice migration path.

1 Like
5

Thanks for the heads up on this!

In the meantime, it would be nice to have a candid endpoint on the registry canister that returns a list of all active subnet ids with:

  • subnet type (application, system, etc.)
  • array of specializations if any, such as (fiduciary, european, etc.)
  • node count
  • deployment authorization (public, must have canister on subnet, private/restricted principals only)
  • date/time created

There are a few other fields that are be nice to haves, but this would be a good starting place.