Subnet Identity

[distributedstatemachine]

Description

Currently, the subnet registration process doesn't include identity information, and the SubnetInfo struct lacks fields for storing this data. We need to enhance the subnet registration process to include identity information and extend the SubnetInfo struct to accommodate these new fields.

This enhancement will allow subnet owners to provide more detailed information about their subnets, making it easier for users and administrators to identify and interact with different subnets in the Bittensor network.

Acceptance Criteria

1. Extend the SubnetInfo struct in pallets/subtensor/src/rpc_info/subnet_info.rs to include the following new fields:

   • subnet_name: Option<Vec<u8>>
   • github_repo: Option<Vec<u8>>
   • subnet_contact: Option<Vec<u8>>

2. Modify the subnet registration process to accept and store the new identity information.

3. Update the get_subnet_info function to retrieve and return the new identity fields.

4. Ensure that the subnet deregistration process clears the identity information.

5. Add appropriate error handling for cases where required identity information is missing during registration.

Tasks

• Update the SubnetInfo struct in pallets/subtensor/src/rpc_info/subnet_info.rs.
• Modify the register_subnet function to accept and store identity information.
• Update the get_subnet_info function to include the new identity fields in its return value.
• Modify the deregister_subnet function to clear identity information.
• Add new error types for missing required identity information.
• Update any relevant tests to cover the new functionality.
• Update documentation to reflect the changes in subnet registration and information retrieval.

Additional Considerations

• Consider making subnet_name and github_repo required fields, while keeping subnet_contact optional.
• Evaluate the impact of these changes on existing subnets and consider a migration strategy if necessary.
• Consider adding a function to update subnet identity information separately from the registration process.

[mvds00]

What's wrong with the current identity mechanism?

[distributedstatemachine]

What's wrong with the current identity mechanism?

@mvds00 its manual and often leads to significant onboarding friction , as moderators need to figure out who the owner is , what the repo is etc.

[mvds00]

By manual you mean as a separate step? All of this remains manual. The core feature of this proposal is that the values can only be set once, at registration time, right? That will not hold, these things are not set in stone, names change, repos change. When we registered our SN we did not have a definite name yet, for one thing, so we would have put some placeholder data in there.

[distributedstatemachine]

By manual you mean as a separate step? All of this remains manual. The core feature of this proposal is that the values can only be set once, at registration time, right? That will not hold, these things are not set in stone, names change, repos change. When we registered our SN we did not have a definite name yet, for one thing, so we would have put some placeholder data in there.

@mvds00 good point. Similar to how we backfil the delegates file, we would have to do this too. We do have an extrinsic that will allow subnet owners do this. We just need to check its the owning coldkey cc @JohnReedV