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/WAKU-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 EIP-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: Ethereum 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”?