Closed Reecepbcups closed 10 months ago
Can you provide a dump of the unsigned transaction from the osmosisd tx ibc-transfer transfer transfer ...
command? Is this the transaction memo or the MsgTransfer memo? The later is currently not supported but could be.
@webmaster128
{"body":{"messages":[{"@type":"/ibc.applications.transfer.v1.MsgTransfer","source_port":"transfer","source_channel":"channel-0","token":{"denom":"uosmo","amount":"2"},"sender":"osmo10r39fueph9fq7a6lgswu4zdsg8t3gxlqyhl56p","receiver":"cosmos10r39fueph9fq7a6lgswu4zdsg8t3gxlqvvvyvn","timeout_height":{"revision_number":"4","revision_height":"14849961"},"timeout_timestamp":"1681250180453486857","memo":"{ \"forward\": { \"receiver\": \"juno10r39fueph9fq7a6lgswu4zdsg8t3gxlq670lt0\", \"port\": \"transfer\", \"channel\": \"channel-207\" }}"}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[{"denom":"uosmo","amount":"750"}],"gas_limit":"250000","payer":"","granter":""}},"signatures":[]}
Its for the MsgTransfer memo which is scoped to FungibleTokenPacketData from ibc-go. CLI scopes it to the correct one under the hood it seems
Definitely needed as Packet Forward Middleware & ibc-hooks both will use this packet data for transferring tokens
As you can see here: https://www.mintscan.io/osmosis/txs/06F9B34BFCEAA0A3EAE4ACA5F2074A149E127EFCCF380DFFEC48768E72E76141 a successful transfer will not show it in the memo (note) field in Mintscan
Great, so all you need is that new memo field for MsgTransfer
. Since you put your JSON in there, you don't even need FungibleTokenPacketData types.
That's cool because I want to build a re-designed API for sendIbcTokens anyways.
@webmaster128
Can you let me know when I can expect the ibcMsgTransfer
with memo
functionality?
Is this WIP? or just planned?
You can already use it by creating the message yourself and use signAndBroadcast. This ticket here is a bit of API design challenge as we suddenly have two types of memo in the same method. Not sure how to do this nicely.
You can already use it by creating the message yourself and use signAndBroadcast. This ticket here is a bit of API design challenge as we suddenly have two types of memo in the same method. Not sure how to do this nicely.
Thanks!
One question, the fact that I can use the ibcMsgTranfer
with memo
field means that I can use the packet-forward-middleware
& ibc-hook
functionality with cosmjs
.
Right?
I don't know packet-forward-middleware & ibc-hook but I think yes.
You can do something like the current sendIbcTokens
implementation in your app code. More or less this:
const timeoutTimestampNanoseconds = timeoutTimestamp
? Long.fromNumber(timeoutTimestamp).multiply(1_000_000_000)
: undefined;
const transferMsg: MsgTransferEncodeObject = {
typeUrl: "/ibc.applications.transfer.v1.MsgTransfer",
value: MsgTransfer.fromPartial({
sourcePort: sourcePort,
sourceChannel: sourceChannel,
sender: senderAddress,
receiver: recipientAddress,
token: transferAmount,
timeoutHeight: timeoutHeight,
timeoutTimestamp: timeoutTimestampNanoseconds,
memo: "" /* your IBC memo goes here */,
}),
};
client.signAndBroadcast(senderAddress, [transferMsg], fee, txLevelMemo);
Please see https://github.com/cosmos/cosmjs/issues/1493 for the current state of the MsgTransfer memo field. Closing here since sendIbcTokens
won't be changed. Instead it will be fading out.
Can we get FungibleTokenPacketData memo so we can create Middleware UIs (packet forward middleware specifically)? It requires JSON encoded values in this to properly work. This works for the CLI but not on cosmjs
Working CLI example
Even though this is --memo, it's not the 'correct' memo for Keplr / cosmjs
https://github.com/cosmos/ibc-go/blob/v5.1.0/proto/ibc/applications/transfer/v2/packet.proto