[Feature]: RPC for Getting All Delegation Information for an MSA

[wilwade]

Feature Description

Details

I want to be able to get the delegation information for all providers for a specific user.

Currently there exists only a query way to access this information api.query.msa.delegatorAndProviderToDelegation and making sure the second option is None. However, direct access to this state with an optional is not supported by all libraries.

There exists the runtime and custom API that mirrors this, but it does not have the optional: grantedSchemaIdsByMsaId(delegator_msa_id, provider_msa_id)

We should also provide grantedSchemaIdsByMsaId(delegator_msa_id) that returns the data indexed by provider id.

Example Response (based on Mainnet MSA Id 5500):

[
  {
    provider_id: 2,
    permissions: [
      {
        schema_id: 6
        revoked_at: 0
      }
      {
        schema_id: 7
        revoked_at: 0
      }
      {
        schema_id: 8
        revoked_at: 0
      }
      {
        schema_id: 9
        revoked_at: 0
      }
      {
        schema_id: 10
        revoked_at: 0
      }
    ]
  }
]

Possible Related Issues

• 420 Original RPC PR

Searched for Related Issues

• [X] I have done a search for related issues and either found none, or noted them

[JoeCap08055]

A couple of points:

1. The main delegation should also have a revoked_at property, unless the idea is to not return a delegation object for a provider if the entire delegation has been revoked. But I would argue against that, as it could be information that we want.
2. Would it be more efficient for a consumer to return a keyed object instead of an array? ie:

   {
   "2": {
   "provider_id": 2, // redundant, but useful?
   "revoked_at": 0,
   "permissions": []
   }
   }

3. Would it make sense to simply change the existing RPC to make provider_id an Option? Or is the issue that we need a version that doesn't require using Option because of spotty library support for that type? Another "hack" would be to update the existing RPC to treat a provider_id of 0 (zero) the same as None, seeing as zero is not a valid Provider ID...

[wilwade]

@JoeCap08055

1. The main delegation should also have a `revoked_at` property, unless the idea is to not return a delegation object for a provider if the entire delegation has been revoked. But I would argue against that, as it could be information that we want.

I suggest we do the same as grantedSchemaIdsByMsaId(delegator_msa_id, provider_msa_id)... Although I'm not sure what that is.

2. Would it be more efficient for a consumer to return a keyed object instead of an array?

Nope. It is harder for serde and parsing in typed languages to handle keyed objects.

3. Would it make sense to simply change the existing RPC to make `provider_id` an Option?

I think it makes sense to just have a second RPC. Mostly because it is simple and doesn't require a breaking change.

[JoeCap08055]

@JoeCap08055

1. The main delegation should also have a `revoked_at` property, unless the idea is to not return a delegation object for a provider if the entire delegation has been revoked. But I would argue against that, as it could be information that we want.

I suggest we do the same as grantedSchemaIdsByMsaId(delegator_msa_id, provider_msa_id)... Although I'm not sure what that is.

~grantedSchemaIdsByMsaId only returns info about individual schema delegations (but it massages the revoked_at property of each delegated schema in the event the entire delegation is revoked). But I think for this RPC, since we're returning the entire delegation object, not just the list of schema permissions, we should include the main delegation's revoked_at property on its own.~

Ah, I see. Got it. grantedSchemaIdsByMsaId returns info about individual schema delegations, but the revoked_at property is min(delegation.revoked_at, schema.revoked_at), if they're both non-zero, or the non-zero value if only one of them is non-zero.