Continuing the work on js-waku, the latest objective was to build and spec an end-to-end encrypted messaging dApp: Eth-DM, standing for Ethereum Direct Message.
You can find:
- A deployed version of the app on js-waku GitHub Pages.
- Specs at 20/ETH-DM | Vac RFC.
- Code at js-waku/examples/eth-dm at main · status-im/js-waku · GitHub.
It is very rudimentary, the aim was to ship a first PoC and then build on it. The current PoC allows you to:
- Generate an Eth-DM key-pair, used for encryption and decryption of messages. Your Ethereum wallet (e.g. Status, Metamask) is used to generate the keys meaning you do not need to back them up; Eth-DM keys can be recovered using your Ethereum account.
- Publish your Eth-DM public key to the network to allow others to find it using your Ethereum address.
- Send encrypted messages to another peer.
- Received said encrypted messages from other peers.
The standard Web3/Metamask/Status API does not permit much around key access and encryption.
Some wallet such as Metamask supports methods for encryption. However, it is restricted and not broadly available. Having EIP-2844 commonly available would be another way to more easily implement Eth-DM like dApps.
To work around these restrictions, Eth-DM uses the signature of a salt message as the encryption private key.
I find it to be a clunky way to work around these restrictions, without the EIPs cited above, another solution would be to simply generate fresh new keys for encryption. In this case, the user would need to properly backup said keys to not loose messages.
It is evident from the feedback we got at 0xHack that encrypting and signing messages is a feature that dApp builders are likely to implement in projects using js-waku.
Currently, signatures and encryption are considered an application level concern: Waku v2 does not enforce or restrict the payload dApp includes in Waku Messages. If this payload needs to be signed or encrypted, the dApp is free to do so by including the necessary data in the Waku Message payload field.
This is why I want to provide a number of examples on how to sign and encrypt messages sent over Waku. Eth-DM provides a good use case to do so, the next step is to allow user to sign their messages to prove their authenticity.
Furthermore, Eth-DM only uses Light Push: messages and public key are not retrieved from Store nodes. This means that for two peers to communicate, they have to have the dApp opened at the same time. I will include Store in a subsequent release and probably smooth out the recipient selection UX too.
One of the objective is to show how js-waku can be integrated with web3.
The current integration done with Eth-DM to offer message encryption is somewhat clunky so I will aim to showcase message signature instead. I expect message signature using web3 to be much smoother as etherjs and web3js both provide a simple API for it.
Moreover, I am keen to provide a simple module that automatically sign messages sent over Waku v2. It may be interesting at this point to review whether we should have a new signature or metadata field on WakuMessage to allow complete freedom on the application payload while having a generic way to include signatures of said payload. An idea already proposed by bgits.