A Very Short History of Electronic Mail

“You’ve got mail!” It was the phrase that changed the Internet forever and is burned into the brains of most people born before 2000. As the Internet, or ‘the world wide web’ as it was referred to back in the ‘90s, became adopted by more businesses and people started buying computers for their homes, electronic mail became more prevalent. Fax machines and typewriters bit the dust, the mail delivered by your local post person became “snail mail,” and the rest is history.

‍

‍

Electronic communication over the Internet has supported much of the technological innovation we’ve seen in the last 20 years, particularly with the rise of e-commerce, content marketing, and social media. And what those tools all have in common is that they leverage different forms of Internet messaging.

To understand how electronic communication influences the ways messages get sent on the blockchain, let’s first unpack how a message gets sent on web2.

‍

Here’s a quick breakdown:

1. A sender creates a message with one or many intended recipients.
2. That content is translated from the sender's content advanced format types like html or images to plain text, so the recipient’s client can render it.
3. A server then pushes that content to the recipients client’s servers which it is able to identify by an email address.
4. That content is translated from plain text back to the sender’s intended format by the recipient’s client.
5. The recipient sees this content in the place where they view their other Internet messages - Twitter, Facebook, Gmail, etc.

‍

Clients, networks, protocols, and servers act as the core technologies leveraged in the process described above. Let’s look at them a little closer since they’ll come into play when we get into blockchain messaging a little later:

💡 Clients - Software that provides users access to human-readable information from a server that received information transmitted by a network.‍

💡 Networks -  A group of dedicated hardware machines that moves information packets from one computer to another. Packet switching the actual method by which this information moves.‍

💡 Servers - Hardware that communicates with clients, so users access data and information provisioned for them. These machines also offer computational resources.‍

💡 Protocols - TCP/IP (the Internet protocol suite) is an end-to-end data communication standard that specifies how data is transmitted, routed and received, and powers chat and instant messaging functions. Simple email clients use SMTP for sending messages and IMAP for retrieving messages.

‍

So there you have it on web2 messaging, which essentially hasn’t changed since the days of that automated AOL “you’ve got mail” voice floating out of your computer speakers.

‍

The State of Blockchain Mail

But what happens when we apply messaging to web3, which uses a blockchain in place of the networks and servers that web2 email leverages? Whereas web2 networks and servers are separate technologies, the blockchain serves as a global state machine for sending and receiving information, the distributed nodes powering the chain, and maintaining how data is organized.

On the blockchain, there is more room for innovation around interoperability, transparency, and security:

• Interoperability: You have total control over your data. With web2, if you decided that you wanted to switch from using Yahoo to using Gmail, you’d have to change your email address and you’d no longer be able to access or see the messages you’d sent and received before switching. Using web3, you can change your address and move your history of previous messages sent and received right over to your wallet or renderer.
• Transparency: You can see every piece of data that’s ever been sent to you. This is a bit of a double-edged sword because it eliminates the entire concept of the spam folder, but it provides a censorship-resistant experience. For instance, imagine that you lived in a country that censored information about blockchain technology on the internet, they might have agreements with email providers to block known websites or newsletters. This sort of censorship would be more difficult with on-chain messaging because the data is stored across a network of decentralized nodes.
• Security: You can prove that the sender of a message is who they say they are by the message signature. (If you want to play around with this concept Etherscan has a cool tool.)

‍

Here’s how the core technologies of web2 messaging today map to the web3 stack:

💡 Clients - Wallets and dApps like Zerion or Zapper provide end-users a window into the blockchain and the things associated with their wallet addresses. This is similar to how an Internet browser allows us to access websites.

💡 Networks - Blockchains and their validators move information between accounts, which include smart contracts and externally owned accounts.

💡 Servers - Blockchains and their validators have the ability to store the data, but it can be expensive. It’s become popular to store pointers to off-chain information in the on-chain data that provide access to other mutable or immutable storage platforms. We’ll dive deeper into this later.

💡 Protocols - Like web2’s STMP and IMAP protocols, developers are creating web3 standards that allow for scalability and better UX. For example, blockchain transactions are structured in a standard format that wallets are able ingest to provide human-readable information.

‍

Sounds cool, right? Let’s see what can be done with the building blocks offered by this new technology.

‍

First, we’ll start with input data. Ethereum and many other chains allow you to send input data as part of any transaction. Input data is the “message payload” of a transaction and it’s important because it provides instructions to the functions within smart contracts that power decentralized finance, or DeFi, NFTs and other programs built on the blockchain.

This data can be numbers or text, but either needs to be formatted as hexadecimal. There isn’t a fixed limit for the length of the input data, but the input data does consume “gas,” or the computational work required to run transactions on the blockchain, so the bigger the message is the more expensive it will be to send.

If you examine the transaction you sign when you initiate a swap on Uniswap, a decentralized trading platform, you’ll see you’re passing 420 bytes of data to a multicall function housed within the Uniswap smart contract. While it might not be readable to the naked-eye, the data is actually structured in a standard way that the contract can understand known as the Application Binary Interface (ABI). The data decoded by the smart contract gives it instructions about what transactions should occur.

‍

Check out the example below:

‍

Sure, it sounds very technical and complicated, but it all boils down to a user sending a signed “message payload” to a program on the blockchain. This same “messaging” technology can similarly be leveraged to pass simple messages from one wallet to another.

Let’s walk through an example of how someone with a Metamask wallet would do this. Using Polygon, which is also an Ethereum Virtual Machine-based blockchain, my wallet has been configured to show the hex input data field.

When you transfer MATIC from one wallet to another, a user is able to include additional input data into that transaction. As you can see below, it’s nearly identical to our Uniswap transaction except the size of the data payload is much smaller with only 18 bytes (a different function type was also called).

‍

‍

You can examine this finalized transaction in closer detail on a block explorer or simply decode the string to see that additional input data is just a plain text message that reads, “This is a message!”

‍

0x77A…6888 just got mail!

‍

‍

Here’s what’s going on from a technical perspective:

1. A user drafted a message in their wallet to an intended recipient. This message had to be translated from plain text to a machine-readable format (hexadecimal) before composing it in the client, which isn’t great UX.
2. The user signed the message and relayed the message to a node for submission to the Polygon network via a Remote Procedure Call. This happens behind the scenes of the wallet.
3. After the block with that transaction is confirmed, this message is stored on the blockchain, and its data is stored by validator nodes across the network.
4. This message can then be accessed by making a via Remote Procedure Call to a node or your own local copy of the blockchain’s data. This is the protocol used to retrieve information from the blockchain.
5. User interface clients (like a wallet or a block explorers) can then serve this message to the intended recipient or other users.

Voila, that’s web3 messaging.

‍

The Opportunities for Web3 Messaging

So that’s how it works today, but there’s room for improvement. Let’s dive into the pain points.
‍

• Who is 0x77A…6888? It’s just an Externally Owned Account on a blockchain. If you type out one of the 42 characters in the address incorrectly, it’s very difficult to tell that you’ve made a mistake, and there are limited UX features like “unable to deliver” messages. Projects like Ethereum Naming Service and Unstoppable Domains are doing cool things with domain names to make addresses more human-readable like emails.
• Input data needs to be unlocked in the “advanced” settings tab, and users have to covert the plain text into hexadecimal. Imagine having to cut and paste your email text into Google Translate before sending.
• When you’re paying per character, there’s value in being concise. Hypothetically, you could convert richer message types like HTML to hexidecimal to send them this way as well but they would be even more verbose and expensive.  Metadata can help solve this problem in some instances. When metadata is present, which isn’t always the case, you can ask the contract for additional information which could even contain pointers to off-chain information like urls. IPFS is a popular storage platform for this information because it’s immutable since hosted on a decentralized and distributed platform.
• After this message is posted to the network, it’s not exactly easy for the recipient to find that message. Wallets aren’t configured to show users this type of message, unless they have additional configurations built on top of them. For example, Notifi has created a protocol that supports communications on the Solana blockchain—but only if your wallet or your dApp supports it.

‍

It all comes down to the same core question that web2 had to solve: Does the user interface client have the ability to retrieve relevant information from the servers and show it to the user? This is what Gmail, WhatsApp and Facebook have spent decades on improving.

‍

These are the pain points we’re looking to solve at Dispatch. We want to help form the standards around messaging and engagement in web3 that have been so crucial to web2’s success so far. Dispatch is building the tools that projects need to help identify their users without leveraging PII (Personal Identifiable Information) like names, emails and numbers. Instead, we’re building ways to speak to them using the blockchain primitives that already exist, like NFTs. We’re also continuously shipping new code focused on dynamic message rendering and engagement tracking.

Community is the flywheel in web3, where users are owners, contributors and consumers. So facilitating community growth via messaging is critical to the web3 ecosystem. In the absence of on-chain messaging, Telegram and Discord have become popular for a reason!

There needs to be a more native form of communication directly on the blockchain, which better serves these communities. In a world full of addresses, but no messages, it’s to build.

‍

‍