make assets registry abstract over remote location

[dzmitry-lahoda]

so we can have IBC and XCM locations configured in runtime, not on pallet level

[xlc]

can you provide bit more specific examples? I am not familiar with IBC. is there a MultiLocation equivalent in IBC? is it possible to describe it with MultiLocation?

[dzmitry-lahoda]

see location here https://docs.google.com/spreadsheets/d/1geVYBeMqlUI6TiJaZs24RMQlBTyZNPwmWrJM1BddGU0/edit?usp=sharing

documented here https://github.com/cosmos/ibc/tree/main/spec/app/ics-020-fungible-token-transfer in IBC white paper.

seem similar to XCM multilocation.

here is how configuration can be made https://github.com/ComposableFi/composable/blob/67508881c57ac0ac5894e91d843fbc74381978aa/code/parachain/frame/assets-registry/src/lib.rs#L76

here is what it can be https://github.com/ComposableFi/composable/blob/67508881c57ac0ac5894e91d843fbc74381978aa/code/parachain/runtime/primitives/src/currency.rs#L374

can IBC ICS 20 denom be encoded as XCM MultiLocation? kind of yes. but it would lost all relevant semantics. so i doubt that is good (assumin ICS-999 or XCVM can reuse underlying channels of each other).

[xlc]

can IBC ICS 20 denom be encoded as XCM MultiLocation? kind of yes. but it would lost all relevant semantics

Can you elaborate on that? Looks like IBC token is just a string? So something like Junction::GlobalConsensus(Network::ByGenesis(xxx)), Junction::GeneralKey(yyy), Junction::GeneralKey(zzz) could work?

[dzmitry-lahoda]

it is port id which is string, then channel number which is number, repeat previous several times, some asset id which is string, usually symbol, hash or number. ibc path parts part are not limited to 32 bytes. there are 64 and 128 limits. and also it is ics20. there is future ics999. also need to diff asset by bridge they will go, hence encoding will be weird to erase meaninful ibc info nice for fe and pdjs, put wrong limits, and hard to diff xcm vs ics20 protocol ids on storage level. and each chain may have several channels. same genesis but many channels. so no. i just wrote it as people anyway ask or suggest it. but it is not resonablw to do so.

[dzmitry-lahoda]

basically protocol prefix defines asset remote location encoding. including future zk assets. ibc and xcm have opposite design for error handling too. so xcm does not fit it all.

[xlc]

I see. Ideally, I want to solve this properly with XCM which suppose to be a universal format. While I don't think it is designed with IBC in mind but I believe be IBC compatible is in scope of XCM. I just don't really want to require chains to explicitly support IBC on top of XCM. I am not against your proposal, but just want to explore alternatives first before making a decision.

I also raised by concern to Gav about XCM general key size is capped to 32 bytes and that will not be enough for many use cases and he suggested a solution: use asset registry to assign a local short id and use that in XCM.

So in this case an alternative solution will be Composable to have a IBC asset registry pallet to register IBC address and have them assigned an ID. Then to transfer those IBC assets, other parachain will just treat them as a standard asset in Composable parachain and no need to deal with any IBC code.

On Composable, it just need to use the IBC asset registry to handle the mapping. With that been said, the generalized version of asset registry could be used to implement the IBC asset registry so your suggestion is still a valid one.