Consider allowing alternative sender/receiver address in ICS 20 ADR 8 callbacks

[colin-axner]

Summary

The initial implementation of GetSourceCallbacksAddress and GetDestCallbacksAddress requires the sender/receiver to be the same as the source/destinations addresses specified in the memo for ICS 20

This issue is to document discussion on whether/how to change that.

One possible solution is adding an optional boolean to allow a non receiver for the destination callback

Same suggestion could be true for the sender

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[0xekez]

i think this is a pretty common use case and would be great to have!

in addition, it would be great to be able to add data to the callbacks from the initiator, that the receiver gets from the callback. for example, this is my callback design:

/// Executed on the callback receiver upon message completion. When
/// being executed, the message will be tagged with "callback":
///
/// ```json
/// {"callback": {
///       "initiator": ...,
///       "initiator_msg": ...,
///       "result": ...,
/// }}
/// ```
#[cw_serde]
pub struct CallbackMessage {
    /// Initaitor on the controller chain.
    pub initiator: Addr,
    /// Message sent by the initaitor.
    pub initiator_msg: Binary,
    /// Data from the host chain.
    pub result: Callback,
}

[0xekez]

a use i can imagine in this is outposts where you want to:

1. transfer token to outpost account.
2. list(swap/whatever) token using outpost account.

to do this, the outpost needs to get a callback on the ics20 completion, and the initiator needs to include information (initiator_data) in the callback to the outpost in step (2) saying what action to take (list/swap/whatever).