Technical Specification

Features

MVP

• Send signed messages to an account (ENS Domain or hex address)
• Create a X25519_XSalsa20_Poly1305 key and publicize it as ENS text record
• End to end encryption of messages using the X25519_XSalsa20_Poly1305 key pairs
• Notifications

Later

• Use the public key derived from the registration transaction or from an EIP 619 entry to encrypt messages (in combination with a MetaMask Snap)
• Perfect Forward Secrecy
• Decentralized message storage and transport
• Tokenization

Architecture

Flows

Alice Sends Signed Message to Bob

1. Alice enters Bob's ENS Name
2. Bob's ENS name is resolved to an ethereum address
3. Alice submits a message
4. Alice is asked to sign the message via MetaMask
5. Alice sends the message via the ENS Mail Storage and Transport Service
6. The service checks the signature
7. The message including the signature is stored in a DB controlled by the service
8. Bob's ENS Mail Dapp queries for new messages
9. The message from Alice is received and checked if the message matches the signature
10. The message is displayed

Alice Sends Message to Bob Using X25519_XSalsa20_Poly1305 Encryption

Same as "Alice Sends Signed Message to Bob" but with the following additional steps:

• 3.1 Alice requests the eth.ensmail.X25519_XSalsa20_Poly1305 text record of Bob's ENS name
• 3.2 Alice uses Bob's public key to encrypt the message
• 4. Alice is asked to sign the encrypted message via MetaMask
• 10.1 Bob is asked to decrypt the message via MetaMask (eth_decrypt)

Alices Sends a Message to Bob Using Perfect Forward Secrecy

I didn't dive deep into PFS until now. So this may not work but I want to document this first idea anyway.

1. Alice types the message and clicks send
2. The message is stored locally in the Dapp
3. The exchange of the ephemeral session key is done over the same channel the actual message would be sent (e.g. over the ENS Mail Storage and Transport Service)
4. After the key is exchanged Alice encrypts the message and sends it.