EIP-191 Signature and Waku Message version 1

Waku
1

As part of the Status Community Directory Curation dApp, voters will need to sign with their Ethereum wallet messages to cast their vote or respond to a poll. Eth-DM also uses signature to prove ownership of a public encryption key before it is published.

At the moment, both apps store and transmit the signature as part of a custom application payload.
Because we see a need for various dApps. I thought it would be interesting to use 26/WAKU2-PAYLOAD | Vac RFC 's signature placeholder for this purpose.

26/WAKU-PAYLOAD specifies that Keccak(flags || payload-length || payload || padding) should be signed.

Now, Ethereum wallets have several ways to data.
The current/old way is ERC-191: Signed Data Standard, the operation is accessible via:

All methods above seem to follow the 0x45 version of the EIP, .e.g, prepending the message to sign with "\x19Ethereum Signed Message:\n" + len(message). (also called eth_personal) before hashing.

This is not ideal as the data signed may seem arbitrary for a user. Hence, a new EIP was created: EIP-712: Typed structured data hashing and signing as an extension of EIP-191 and it is experimentally supported by Ether.js and Metamask.

EIP-712 introduce the concept of domain and structure message to sign, allowing the user to better understand what he/she signs.

So far, Eth-DM uses EIP-191 x45. I intend to play around with EIP-712 as I believe it better fits our purposes (signing structure data).

Now the question is, should we consider supporting EIP-712 signature format in WakuMessage version 1 or should leave it as an “application concern”?

2

Note that in term of Status Wallet/Keycard support, I could not find much:

3

Actually, it iss possible to sign messages with ethereum account and with keycard with Status wallet.
“personal_sign” and “eth_signTypedData” (v3/v4) are supported.