Discussion: Human Readable Subnet Names

Developers
1

Goal

To establish a standard for human readable subnet names

Motivation

How many of you can name the first 5 characters of 3 subnets? The ones your canisters are deployed to? How about the European “BOB” subnet?

In other cloud ecosystems such as AWS or GCP, deployment regions, such as us-east-1 provide a human readable name that allows developers or teams to remember where their application is deployed.

On ICP, knowing the name of a subnet has several benefits:

  • Performance: Being on the same subnet improves application inter-canister call performance
  • Functionality: There are features such as composite queries that are only available if all involved canisters are on the same subnet. Additionally, when a canister creates a new canister through the management canister, that canister is created on the same subnet as the parent canister
  • Migrations: Canister migrations are a current roadmap priority, allowing a developer to move a canister from one subnet to another.
  • Degradation/Outages: At times, certain subnets experience outages or degraded performance. In these times, it helps to refer to a subnet by something other than bkfrj

Potential Naming Schemes

Below I’ve listed a few rough ideas for human readable subnet names. This is just to get the conversation started, so feedback and additional naming scheme ideas are encouraged!

By Specialization & Type

Name subnets categorically by their specialization and type according to:

{subnet_specialization}-{subnet_type}-{incrementing counter id}

Each unique combination of subnet_specialization and subnet_type would reset the counter to start from 1.

Some examples:

  • fid-app-1 - A fiduciary, application subnet assigned counter id 1
  • app-5 - An application subnet that was assigned counter id 5
  • eu-app-2 - An european, application subnet that was assigned counter id 2
  • sys-1 A system subnet that was assigned counter id 1

Note: I’m biased towards this option, since it’s in-line with what most cloud ecosystems do and seems to work pretty well.

By theme/category

Keep subnet specializations and types, and replace the “counter” suffix with names from a certain category such as elements (app-iron, eu-app-uranium ), crystals/minerals (fid-app-quartz , sys-opal ), or some other category.

By community choice

Similar to before with {subnet_specialization}-{subnet_type}-{suffix name}, but allow the community to choose the suffix. Each time a new subnet is added, have the NNS or another community elect a name for the new subnet.

16 Likes
2

:+1:

DNS was a good idea because giant meaningless blobs are very bad for human consumption.

5 Likes
3

This is a good idea
No strong preference, but my gut tells me to stop re-inventing the wheel with everything on the IC and go with the more industry standard one, to reduce the learning curve when coming from other places.

Do you have any thoughts on where these names will be officially stored?
Is it adding a new property to subnet metadata somewhere that would be backfilled through an NNS proposal?

4 Likes
4

No defined thoughts at the moment, mostly curious to receive thoughts around naming schemes.

This type of a service doesn’t necessarily have to controlled by the NNS - it could at least start out as being completely managed as a community owned canister service and gradually be adopted because of the convenience it provides.

At some point, if enough critical services and processes rely on it or there is demand, it can be transferred to multi-sig or DAO control.

2 Likes