ENS Mail could be integrated in:

• RiotChat
• Slack plugin
• Status.im
• Keybase
• Discord

• accountsChanged
• chainChanged
• connect
• disconnect

see: https://github.com/corpus-ventures/ens-mail/wiki/Technical-Specification#alice-creates-a-x25519_xsalsa20_poly1305-key-and-publishes-it-on-chain

• Align connect and sign in buttons vertically
• Put connect and sign in next to contact list
• Add description to connect and sign in buttons
• Make add account a form so that it can be submitted with enter
• Change layout

• Avatar URL
• Twitter
• Github
  ...

• #54
• #55
• #56
• #57
• #60
• #62

For the MVP, we store it on one of our servers, but in order to open it up and make it a true protocol, it needs more flexibility.

Options:
IPFS + Filecoin
Swarm
Matrix

Current

sequenceDiagram
    UI->>+BackendAPILib: getMessages()
    BackendAPILib->>+Backend: POST getMessages
    Backend-->>-BackendAPILib: Messages
    BackendAPILib-->>-UI: Messages

Goal

sequenceDiagram
    UI->>+MessagingHandler: getMessages()
    MessagingHandler->>+BackendAPILib: getNewMessages()
    BackendAPILib->>+DeliveryService: POST getMessages
    DeliveryService-->>-BackendAPILib: Messages
    Note right of MessagingHandler: "new" messages
    BackendAPILib-->>-MessagingHandler: Messages

    MessagingHandler->>MessagingHandler: decryptedMessages()

    MessagingHandler->>+StorageLib: storeMessages()
    StorageLib-->>-MessagingHandler: success

    MessagingHandler->>+StorageLib: getConversation()
    Note right of MessagingHandler: "new" + "old" messages
    StorageLib-->>-MessagingHandler: Messages
    MessagingHandler-->>-UI: Messages

Todo

• Decide on storage framework
• Implement messaging handler
• Store outgoing messages

Make sure, the leakage of an encryption key does not reveal the whole message history.
Here is one way on how to do it: https://medium.com/coinmonks/perfect-forward-secrecy-in-turms-anonymous-message-transport-f770527992bd

Lib

• getMessages()
  • decrypt()

• Vision
• Solution
• Technical principles
• Way to adoption
• Token?

• Check public key instead of signature

Happen more often if a address is added compared to ens names

• vision / the problem it solves
• describe functionality
• technical solution

• Deploy dapp as github pages
• Deploy test backend using heroku

Idea

We use a decentral protocol to deliver messages and the messages are only stored in the user's sphere (e.g. google drive integration, dropbox integration, simple file).

Options

Matrix Option 1

Matrix Architecture

https://github.com/matrix-org/synapse/#id2

client <----> homeserver <=====================> homeserver <----> client
       https://somewhere.org/_matrix      https://elsewhere.net/_matrix

"In Matrix, every user runs one or more Matrix clients, which connect through to a Matrix homeserver. The homeserver stores all their personal chat history and user account information - much as a mail client connects through to an IMAP/SMTP server. Just like email, you can either run your own Matrix homeserver and control and own your own communications and history or use one hosted by someone else (e.g. matrix.org) - there is no single point of control or mandatory service provider in Matrix, unlike WhatsApp, Facebook, Hangouts, etc."

Drawbacks

• Single point of failure: Matrix home server (user can still choose another one)
• Matrix is designed so that the home server stores the messages for the user
• Matrix doesn't directly support key pair authentication
• Matrix has a room design supporting more than two participants. This brings a lot of overhead which we don't need since we only want to support messages between two parties.

Benefits

• Matrix is an established protocol
• Matrix provides bridges to a lot of other services https://matrix.org/bridges/ e.g. email, WhatsApp, telegram, ...

Implementation Suggestion

1. Change the server implementation so that it deletes messages after they are delivered to everyone involved.
2. We use the Identity Service API to build a service allowing ethereum key pair authentication

graph TB
    subgraph sg0[Alice]
        id0(Dapp)
        id7[(Messages)]
    end
    id0 --> id9[Chain]
    id0 --> id7
    id0 --> id1[ENS Mail Homeserver] 
    id1 --> id5[ENS Mail Identity Server]

    id4(Bob)
    id4 --> id1

    id1 -.- id2[Other Homeserver] 
    id1 --- id3[Bridges] 
   
    id2 -.-id6(Max)

    id5 --> id9

   classDef green fill:#9f6,stroke:#333
   classDef orange fill:#f96,stroke:#333
   class id0,id4,id6,id7,id8 green
   class id1,id5 orange

Matrix Option 2

Same as Matrix Option 1 but we drop the idea that the user stores the messages in their sphere and let the messages on the homeserver.

graph TB
    subgraph sg0[Alice]
        id0(Dapp)
        
    end
    id0 --> id9[Chain]

    id0 --> id1[ENS Mail Homeserver] 
    id1 --> id7[(Messages)]
    id1 --> id5[ENS Mail Identity Server]

    id4(Bob)
    id4 --> id1

    id1 -.- id2[Other Homeserver] 
    id1 --- id3[Bridges] 
   
    id2 -.-id6(Max)

    id5 --> id9

   classDef green fill:#9f6,stroke:#333
   classDef orange fill:#f96,stroke:#333
   class id0,id4,id6,id8 green
   class id1,id5,id7 orange

Minimal Delivery Service Option

We take the current backend service and change the implementation so that messages are deleted after they are delivered. In a second step we can make it more decentral and support inter delivery service communication (like matrix). This means a user could run their own or use a third party delivery service by changing an ENS text record (possible text record name: eth.mail.home.service). The delivery service would forward messages to the target delivery service by looking up the ENS record and sending it to the registered service URL.

graph TB
    subgraph sg0[Alice]
        id0(Dapp)
        id7[(Messages)]
    end
    id0 --> id9[Chain]
    id0 --> id7
    id0 --> id1[ENS Mail Home Delivery Service] 


    id4(Bob)
    id4 --> id1

    id1 -.- id2[Other Delivery Service] 
    id1 --- id3[Bridges] 
   
    id2 -.-id6(Max)

    id1 --> id9
    id2 --> id9

   classDef green fill:#9f6,stroke:#333
   classDef orange fill:#f96,stroke:#333
   class id0,id4,id6,id7,id8 green
   class id1,id5 orange

Drawbacks

• Not an established protocol
• Single point of failure: Default Delivery Service (user can still choose another one)

Benefits

• No overhead (e.g. rooms, identity server)
• Less complex => faster development

Note

For all the mentioned options we need to provide a server storing the messages until they are delivered. If we don't want this we need to use some kind of peer-to-peer solution which isn't a solution for our use case because this would require the user to be online all the time.

Suggestion

I slightly prefer using the minimal delivery service option because the current Matrix server implementations aren't a 100% fit for our needs and matrix comes with a lot of overhead. The minimal delivery service option should also be faster to implement. I still like the matrix protocol and we should consider using it in the future for example if we want to enable group chats. But also if we use Matrix in the future I think we need to write our own Matrix server implementation or we build a bridge between our service and Matrix.

Integrations

• GnosisSafe integration (owners have a channel and can discuss/sign/send transactions using ENS mail)
• Fill Profile with ENS text records e.g. twitter, github, avatar (https://twitter.com/taytemss/status/1493821719509106689?s=21)
• Send eth and ERC20

Messenger

• Contact state (e.g. online)
• Contact is typing indicator
• Scroll loading

Lib

• send()
  • getSecurityMode() Returns "best" security / encryption mode (sign or X25519_XSalsa20_Poly1305)
  • getEncryptionPubKey()
  • encrypt() encrypts the message itself but not the metadata
  • signEnvelop() necessary so that the message storage / transport service can verify the sender
  • send()

• Unit tests script
• Linter
• Prettier

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication
https://socket.io/get-started/private-messaging-part-2/

• encrypted private keys
• contact list
• rename MessageDB to UserDB

Functionality:

• Write mail
• Send signed mail
• Encrypt mail with public key of receiver
• read mail
• decrypt mail
• simple mailbox
• connect with Metamask

• Delete message if it was delivered to all conversation participants

• File download view
• User storage file generation
• Encrypt file
• File upload
• #73

• React
• Typescript
• Test suit

• Generate encryption key at first sign in
• Use generated encryption key for signing

See: https://github.com/corpus-ventures/ens-mail/wiki/Technical-Specification#alice-sends-signed-message-to-bob

Front end

• show account address or ENS name
• Contact list
• Add contact form

Lib

• addContact()
• getContacts()
• resolveENSName()
• lookupAddress()

Back end

• POST contacts
• GET contacts

• Get persistence sync state
• Sync state view
• "Not synced" warning if browser is about to close

Front end

• Fetch new messages
• Show signature verified indicator

Lib

• getMessages
  • check signatures of received messages

Backend

• POST getMessages
• POST -> WS sendMessage

See: https://github.com/corpus-ventures/ens-mail/wiki/Technical-Specification#alice-sends-signed-message-to-bob

Message structure:

{
  data: {
    to,
    timestamp,
    message
  },
  signature
}

Front end

• Let a user select a contact by clicking on the list
• Chat widget
• Submit message handler

Lib

• signAndSend()
  • sign
  • send

Backend

• POST submitMessage

See: https://github.com/corpus-ventures/ens-mail/wiki/Technical-Specification#alice-connects-and-signs-in

Front end

• connnect
• sign in

Lib

• getWeb3Provider()
• connectAccount()
• signIn()

Back end

• requestSignInChallenge
• submitSignedChallenge

• Only load new messages
• Scroll paging