Add IBC support to multi-test

[ethanfrey]

We now have support for Custom Msg and Queries, and an easy way to plug in Staking and Distribution support. (#266)

One missing feature is being able to simulate IBC calls between 2 apps. This will require significant changes to the App structure and some coordinator that controls 2 apps. Rather than hide this as a checkbox, it makes sense to pull it into a full-blown issue to discuss.

[hoomp3]

Has any progress been made here?

[ethanfrey]

I am considering doing this with cosmjs, as the ibc stack is very hard to emulate.

I will post some update here in a week, please ping me if I forget

[hoomp3]

Okay, sounds good, thanks for letting me know!

[hoomp3]

@ethanfrey Hey, any update to this?

[ethanfrey]

I have made https://github.com/CosmWasm/resources with many links

In particular, I made a new repo https://github.com/confio/cw-ibc-demo which I explain at hackatom Seoul (jt was 11am Saturday if you find the recording.

check it out

[hoomp3]

Okay sweet, found the recording and linking it here in case anyone else finds this thread - https://youtu.be/x75UobIr4qo?t=7183

[hashedone]

I guess I would take it at some point unless anyone else would. My suggestion for that is:

[ ] Add module to handle IbcMsg
[ ] Add API to call IBC-related entry points
[ ] Add additional type to abstract IBC relayer. It should keep handles (borrows?) to pair/group of Apps and have an API to relay single message/all pending messages/all messages until both queues are empty (so also messages generated while executing relayed messages)

Open question - App is mutable and it has to be mutable to call various entry points. However, the new relayer type would need to keep borrows (probably mutable) to make it possible to execute IBC-related entry points. This would make it impossible to execute messages on App when there is an existing relayer on that App. Solutions in my mind are:

• Make a relayer own Apps, so they are accessed through it - but it would make it impossible to create a couple of relates for the same App
• Use Rc<App> in relayer - but it would require to use Rc<App> in the entire test, it is not the best possible API
• Pass borrow to Apps to relayer API functions instead to keep them in it
• Make relayers to be built "ad hoc" (maybe from configuration stored in some additional type)

All approaches have pros and cons, after a bit of thought I am leading to the last one.

[hoomp3]

The last one sounds like it would work best.

[DariuszDepta]

I am closing this issue, as IBC support will be implemented as in #184.