MACI Mailbox – An On-chain Mail System

We are not reinventing email.

Even a glance at the TOC of IETF RFC 5322 reveals: email is long-standing and well-established, but far from simple. This is just one piece of the puzzle in today’s email system.

What we would like to do first is to review the essence of message delivery.

Proto-mail

A typical process of message delivery can be broken down into three critical components:

1. Individuals intending to exchange messages—referred to as the users.
2. An intermediary, or agent, that facilitates the delivery.
3. The message itself.

Message delivery takes place when the sender hands over the message (e.g., a written note) to an agent—a person (a messenger), a device (a beacon), or an institution (a post office). The agent then dispatches the message to the recipient.

Though direct communication, such as face-to-face conversation, falls outside the scope of this context.

The Protocol of MACI Mailbox

The MACI Mailbox is an encryption-based mailing protocol that builds directly on the three components above, with modifications and extensions.

1. The user consists of two parts:
   • An account, typically with a publicly visible mailing address.
   • A keypair (a private key and its corresponding public key), which works its magic in encrypted communication.
2. The agent has a similar structure:
   • An account.
   • A keypair.
3. The message is simple, consisting of two fields:
   • Subject.
   • Body.

The following outlines the flow of message delivery in the MACI Mailbox protocol. The process of sending a message is addressed first.

1. The sender writes a message.
2. The agent encrypts the message using its public key, posts and stores it in a shared public database (e.g. a blockchain, Nostr), and assigns it a queryable ID.
3. The sender wraps the ID of encrypted message together with the agent’s private key, encrypts them using the recipient’s public key, and broadcasts the resulting encrypted data to a public space. Yes, broadcasts it publicly—feeling like encrypted radio communication yet?

In this process, asymmetric encryption is introduced twice, achieving something valuable: the decoupling of message storage from broadcast. This has at least two key implications:

1. It’s highly flexible to choose the infrastructures for encrypted message posting and storage as well as broadcasting facilities—both of which are modular, replaceable, and trustless.
2. Storage and broadcast infrastructures can be separately tailored to meet specific requirements. Typically:
   • Message storage is expected to be inexpensive, reliable, and scalable.
   • Broadcast infrastructure can be customized to fit the varying user ecosystems or needs.

Receiving a message is basically the reverse process:

1. The recipient indexes their mail in the broadcast space, decrypts it with their own private key (guaranteed by the principles of asymmetric encryption), and retrieves both the ID of encrypted message (storage address) and the agent’s private key (which, as you may recall, was bundled with the message ID before broadcast).
2. With the message ID, the recipient fetches the encrypted message from storage and decrypts it using the agent’s private key to obtain the plaintext message.
3. Tada.

It can be observed that the agent’s role described above is highly procedural, lending itself to a modular and replaceable design. This enables significant flexibility in the implementation of MACI Mailbox services and applications.

Vota-Nostr Mailbox: basic architecture

The Vota-Nostr Mailbox is the first implementation of the Protocol by Dora Factory, consisting of several core modules:

• A smart contract deployed on Dora Vota appchain to handle the broadcasting of messages.
• Nostr relays, used for publishing and storing encrypted messages.
• An indexer service to assist users in locating relevant messages, such as those sent to or from themselves.
• A web app as the interface for interacting with the Vota-Nostr Mailbox.

First, user accounts are implemented as on-chain accounts of Dora Vota (represented as a wallet address) paired with a public/private ECC keypair. Message content is kept simple as plain-text strings, with the flexibility to upgrade it later (Everybody Loves Rich Text).

Next, let’s push the boundaries for the agent. Ideally, users shouldn’t have to learn how to interact with it actively—think about fully automated agents. Or picture a stylish scene from The Day of the Jackal: Eddie Redmayne casually discarding a phone after each call.

Thus, a disposable, one-time auto agent is designed for each mail flow. This agent consists of a randomly generated ECC keypair and a temporarily created Nostr account (essentially another keypair: npub/nsec).

Vota-Nostr Mailbox: communication workflow

In Vota-Nostr implementation of MACI Mailbox Protocol, the communication flow is as follows. Both the encryption/decryption of message content and the broadcast rely on elliptic-curve cryptography.

To enhance user experience, a “Sent Messages” feature has been implemented, allowing senders to index, decrypt, and review their sent messages. In general, with asymmetric encryption, only the recipient’s private key can decrypt the encrypted content. Technically, there are cryptographic methods to enable mutual decryption by both sender and recipient.

For simplicity at this stage, this issue is addressed by creating a duplicate of each broadcast data (on Dora Vota appchain). This duplicate is encrypted using the sender’s own public key, allowing the sender to decrypt it with their private key.

Since the Protocol decouples the storage of encrypted message from the broadcast data, this duplication doesn’t significantly increase the payload on the broadcast infrastructure. Only the message ID and the agent’s private key need to be processed as duplicates, both of which are compact and independent of the actual message size (the length of your address line and the size of your front door key don’t depend on the dimensions of your house).

Below outlines the entire communication process:

1. The sender encrypts their message using the agent’s one-time public key and publishes it to Nostr relay(s) via the agent’s one-time Nostr account, obtaining the encrypted message’s ID (i.e., Nostr event ID).
2. The sender wraps the encrypted message ID along with the agent’s one-time private key, encrypts them using the recipient’s public key, and broadcasts the resulting encrypted data to the appchain via their own Dora Vota account. This process leverages wallet apps/extensions for transaction submission and the smart contract for processing, closely resembling how users typically interact with blockchains and dapps.
3. Once the on-chain transaction is processed, the encrypted data is broadcast on Dora Vota. Both the sender and the recipient can retrieve the data at any time via the Mailbox Indexer.
4. The recipient decrypts the broadcast encrypted data using their own private key, finding the Nostr event ID and the corresponding decryption key (one-time agent private key). They then fetch the encrypted message from Nostr relay(s) by the ID and decrypt it with the one-time private key.
5. The sender can follow a nearly identical process to fetch and decrypt their own duplicate, enabling them to review sent messages.

Acknowledgements

The MACI Mailbox protocol was conceived during a Dora Factory developer meeting in Kyoto, March 2024. Eric Zhang supported its implementation in October as a tool to facilitate communications and campaigns in MACI decentralized governance. Shrey Khater and Divyansh Joshi contributed to an MVP of the Vota-Nostr implementation. The protocol was officially integrated with Dora Vota appchain as well as its frontend with efforts from Zhengyu Qian, Dennis Tang, and Vegebun.