support readable data signing about kwil-db

[Yaiba]

If we don't not encode txBody, for person_sign, we could get something like:

eip712, we could get something like:

[Yaiba]

#132 even in cosmos account, we still need this

[Yaiba]

This diagram shows how a message got transformed to a Tx.

We can see that encoding happens two times:
a. data being signed is encoded
b. actually payload is encoded

a) will cause personal_sign gives out a message to sign just like in the description
b) will cause payload always non-readable, which is also a crucial filed for the message to sign. Even for eip712.

So unless we don't encode payload, in best scenario, we can get something like below:

@brennanjl @KwilLuke @jchappelow

[jchappelow]

So even with eip 712 there's still a not-human-readable blob, correct? I don't think that screen quite makes sense since there's a "signature_bytes" which they obviously would not be signing. Still we can make this friendly.

Here's my experience with personal sign in a variety of web3 apps:

Signing into llamanodes (an RPC provider with web3 sign in)

Signing into blast (also an RPC provider)

Signing into Omnia

That one is almost identical to Llama, but with a request ID.

Async art connect

The point

In all cases, it's 90% human readable, free form definition apparently, with a small "token" or otherwise meaningless character string.

Can we not also make our message quite friendly like this in whatever textual template we like, and reduce both the payload+nonce with a hash and embed even a 16 byte token derived from the hash in our human readable message?

In all cases, the user is inevitably going to be signing something that includes a small piece of info that is meaningless to a human, but we can minimize that and make a lot of friendly text around it. The end result is that they understand it's for a Kwil request and that they are not signing a transaction or giving away some tokens (it should say "Kwil" message, include ephemeral data, readable fee, etc).

[jchappelow]

To clarify, that payload is the base64 encoding (text) of the rlp encoding of some procedure/action? I am still thinking that rlp makes the most sense as an efficient deterministic encoding for storage in the blockchain, but I'm not totally clear why frontend/client sdk needs to also do it.

[Yaiba]

So even with eip 712 there's still a not-human-readable blob, correct? I don't think that screen quite makes sense since there's a "signature_bytes" which they obviously would not be signing. Still we can make this friendly.

Here's my experience with personal sign in a variety of web3 apps:

Signing into llamanodes (an RPC provider with web3 sign in)

Signing into blast (also an RPC provider)

Signing into Omnia

That one is almost identical to Llama, but with a request ID.

Async art connect

The point

In all cases, it's 90% human readable, free form definition apparently, with a small "token" or otherwise meaningless character string.

Can we not also make our message quite friendly like this in whatever textual template we like, and reduce both the payload+nonce with a hash and embed even a 16 byte token derived from the hash in our human readable message?

In all cases, the user is inevitably going to be signing something that includes a small piece of info that is meaningless to a human, but we can minimize that and make a lot of friendly text around it. The end result is that they understand it's for a Kwil request and that they are not signing a transaction or giving away some tokens (it should say "Kwil" message, include ephemeral data, readable fee, etc).

Yeah i'm actually going to change the personal_sign so that user will sign a message like:
You're signing a kwil message: *&^#*)@^$#@
Later, in eip712(we cannot encode txBody), we'll be able to let user sign something like:
{ payload: "#@#@#", payloadType: "deploy_schema", fee: 10, nonce: 3 }

As long as we encode payload, payload will not be readable,

[Yaiba]

To clarify, that payload is the base64 encoding (text) of the rlp encoding of some procedure/action? I am still thinking that rlp makes the most sense as an efficient deterministic encoding for storage in the blockchain, but I'm not totally clear why frontend/client sdk needs to also do it.

That's because we are actually signing the txBody, and payload is a filed of byte(which we encoded in rlp).

We can actually not rlpEncode txBody, instead just format and concatenate those fields, we could get something like what we could get from eip712:
`
You're singing a kwil message:

payload: "#@$#@$"
payloadType: "deploy_schema"
fee: 10
nonce: 3
`
@brennanjl

[brennanjl]

AFAIK this got closed, unless you meant for this to include eip712 @Yaiba

[Yaiba]

AFAIK this got closed, unless you meant for this to include eip712 @Yaiba

Yes i guess we can consider this is resolved, #241 supports a structured template message.

I'll create issue dedicated to eip712 later if we need it.