Web3 Email

blockchain-mail.md

Blockchain mailing protocol

Benefits of on-chain email

Personal

• No spam
• Important people can demand $ and the email is guaranteed to be read and responded. E.g. VCs can identify and email and read and respond to your pitch deck guaranteed.
• Email can be used directly for business (as means of payment). And the un-encrypted source can be used as evidence of payment.

Corporate

• No spam
• Security, All below:
• No phishing possible. (If partners must use on-chain email protocol)
• Email registration can be limited to the corp, audited.
• Full provable, accessible audit records, even for cross corporation emails
• Email servers will be decentralized. Hence, resilient to attacks.
• Hardware can be used for signing / encrypting emails. Military level security

On-chain

The bc mailing will have an on-chain component. This smart contract has the following features:

• Email registry. Address, list of encryption keys (pk), optional alias, email cost (asking for money to receive email) Practical Challenge: Famous alias registry to make adoption easy? Solution: Normal alias could have address suffix. But a special class of aliases can be published with a centralized entity. Or be bought.
• DBs: List of registered dbs, and their reputation. (dbs may need to stake / slash). DB requires a fee
• Mails: email hash. dbs, and the receiver's encryption key used.

Entities

• DBs: DBs are centralized entities recording and keeping the encrypted contents of emails. They make money by charging per email. And they have reputation / stake, to prevent bad actors forming. All emails / attachments are stored on db. DB charges some wei / kbyte

• Email Clients: These entities, could be run as courtesy service (e.g. by DBs). They forward emails to dbs. E.g. 0x131231...123@somemail.com. These clients enable sending emails using old fashioned email clients, but they only act as proxies for dbs.

  Note: Clients can optionally provide free email, which are just old fashion emails, so that the use can use their email address in different apps. The on-chain email, is a spam-free experience, but cannot be used for app registrations, etc. because services are not going to pay for sending each email. So. I may have my_alias as my on-chain email. However, I can register for my_alias@onch.mail, and my_alis@some_other.com and both clients will represent same on-chain mails, but they can also receive standard emails on these addresses.

• SMTP proxies: Paid services that provides on-chain email data. So that people can use their favorite email client to receive emails.

• On-Chain emails: No comments needed

User experience using existing email clients - Sender (option 1)

1. User installs gmail / protonmail browser extension
2. User writes the email. If to is an on-chain address, the extension replaces the Send button with Sign, pay, and send.
3. After user presses the button, email gets encrypted using the advertised public key (Note, the extension holds the private key). Then a tx is generated, and sent to the connected wallet.
4. Tx is submitted, email is stored in db (through the intermediary or the extension), and paid for.

CONS:

• An extension required
• Understanding of signing / working with SCs required
• Hard to do with various clients

User experience using existing email clients - Sender (option 2)

1. User sends and email using the standard email client. The proxy stores emails temporarily
2. It receives a bill back, to pay for the transactions, (e.g. qr code of an address and amount)
3. After tx is paid, emails are registered on-chain.

CONS:

• The proxy email service has the un-encrypted email
• Sender is not the real sender (is the proxy)

PROS:

• Easy peasy for user
• One can pay with credit card