Add runtime API for authorizations

[franciscoaguirre]

Addresses #495

We have recently changed the AuthorizationExtent fields with data irrelevant for most client applications. I'm adding a runtime API for returning a simpler and more stable version of authorizations for client applications to use.

TODO

• Add expiration

[bkontur]

not sure if client will be able to interpret this - relay block, Bulletin para block?

[franciscoaguirre]

Do you want to use time? Relay chain block would be better for me, I'm vouching for that

[bkontur]

Do you want to use time? Relay chain block would be better for me, I'm vouching for that

Well, I don't know now, we don't use relay chain blocks, and everything is in Bulletin parachain blocks. I am not sure about the time. For now, with actual impl, I would just consider this Bulletin para block number and client could interpret this to the real clock time?

[franciscoaguirre]

With authorization slots, this will be relay blocks

[karolk91]

I think can_renew should also take into account the case of AUTO_RENEWAL_ALREADY_ENABLED - maybe we could extract some common "verify" method between this API and check_signed (related to renews) so these are less likely to diverge

[karolk91]

If we are going the direction of can_renew and can_store, I'm afraid that the most common case will be the need to check against multiple items instead of every single one in separation - even if we can check every item separately, especially in case of can_renew, that will not answer the question if its possible to renew batch of items

[bkontur]

If we are going the direction of can_renew and can_store, I'm afraid that the most common case will be the need to check against multiple items instead of every single one in separation - even if we can check every item separately, especially in case of can_renew, that will not answer the question if its possible to renew batch of items

can_store takes bytes, so the client just sum all the chunks -> so should be ok, just one call.

hmm, but can_renew, good question, I mean I am ok to merge as it is now, can_renew(one_tx).

if we go with BulletinTransactionStorageApi::can _renew_batch(batch: Vec<TransactionRef> we need to resolve the nice result type List<Result<(), Error> or something like this + maybe limit the input Vec cize? it can be a follow-up.

@karolk91 what do you suggest?

[karolk91]

If we are going the direction of can_renew and can_store, I'm afraid that the most common case will be the need to check against multiple items instead of every single one in separation - even if we can check every item separately, especially in case of can_renew, that will not answer the question if its possible to renew batch of items

can_store takes bytes, so the client just sum all the chunks -> so should be ok, just one call.

hmm, but can_renew, good question, I mean I am ok to merge as it is now, can_renew(one_tx).

if we go with BulletinTransactionStorageApi::can _renew_batch(batch: Vec<TransactionRef> we need to resolve the nice result type List<Result<(), Error> or something like this + maybe limit the input Vec cize? it can be a follow-up.

@karolk91 what do you suggest?

Yeah I was thinking about something similar, to allow Vec in the can_renew. But would need to double check what are the possible limits here - how big this Vec could be. We could do some follow-up but current real life scenarios always involve multiple CIDs - no one will use can_renew or can_store and just use account_authorization instead

In addition to above, current APIs also doesn't support preimage authorizations

[bkontur]

Yeah I was thinking about something similar, to allow Vec in the can_renew. But would need to double check what are the possible limits here - how big this Vec could be. We could do some follow-up but current real life scenarios always involve multiple CIDs - no one will use can_renew or can_store and just use account_authorization instead

Yes, agree, let's iterate

In addition to above, current APIs also doesn't support preimage authorizations

Well, yes, good point, but who can auhorize_preimage? Only OpenGov now, we don't have use-cases for that, again, we can iterate with follow-ups also.

[franciscoaguirre]

@bkontur I was thinking about ideas for the runtime API. I will make a new PR then :)