Off-chain Messages

[JulianToledano]

No description provided.

[webmaster128]

🍾❤️🚀

[JulianToledano]

@tac0turtle @webmaster128
Hey guys! I did commit most of your suggestions. One thing I don't have clear is:
should we go with just one message or both?
As commented above the main problem with ADR-036 was that the message defined wasn't human readable.

[webmaster128]

should we go with just one message or both?

I like the separate MsgProveIdentity. Sounds specific and flexible at the same time.

For the arbitrary content signing I'd go with arbitrary valid UTF-8 text. This is readable by default, encourages the design of readable solutions and can host arbitrary data as well. E.g. any JSON document is a printable string and embedding raw data using some kind of encoding is just as good as a bytes blob that the UI has to show as base64 anyways. Given that I don't see a reason for arbitrary non-string data signing.

[testinginprod]

LGTM.

I would sync with Keplr since I saw they have a MsgSignData they use for off-chain signing, and understand how this might impact them.

Thank you.

[tac0turtle]

merging for now, but we will still sync with wallets and clients

[dogemos]

one minor feedback from @Thunnini.

could an optional chainID field be added?

[webmaster128]

could an optional chainID field be added?

This was discussed somwhere in here. Where and why do you need this? Since off-chain messages are outside of any chain, I don't see how this belongs in here. In MsgSignArbitraryData you can add application specific context (which might include a chain ID). MsgProveIdentity proved a keypair ownership independent of a chain.

[JulianToledano]

could an optional chainID field be added?

This was discussed somwhere in here.

Here is the discussion.