You've Got Mail: A Developer's Guide to Communication Protocols

In the beginning, there was messaging. Since the dawn of the internet, the ability to communicate with one another in not just bytes and packets but with words and media has been the true value of this platform. To the end user, it is just a click of the 'Send' button. But behind the scenes, there are a series of well-planned and battle-tested protocols hard at work. 

In this article, we will explore what is a protocol, the elements of a protocol, and how protocols mature over time. We will look at this through the lens of one of the most popular sets of protocols: email. 

‍

Protocols, Explained 

‍

Protocol is a word much used in Web3 but probably least understood. What is a protocol? If you asked 100 people at the next crypto conference, prepare for 100 different answers. Let's define and look at what elements make up a protocol. 

The simple definition of a protocol is a set of rules that allows communication between two or more parties. Protocols work because the parties agree to follow those rules when communicating. In this way, protocols are like languages. To be able to communicate with others, we must follow the rules of grammar and vocabulary. 

We need protocols. Without them, we would have a very divided internet. Companies would own little islands that could never communicate with others. Protocols also fight against the incentives of a company to hold users hostage on their islands by making it painful to go anywhere else. If you ever used America Online in the early days, you will understand.

‍

The Elements of a Communication Protocol 

Any communication protocol must answer a few important questions: 

1. What is the message?

2. How will it be sent?

3. When will it be sent?

The "what" is being communicated covers the syntax of the message. Syntax means the size of the message and how it is interpreted. Protocols must regulate how much data a message can take and specific instructions in that message. For example, a protocol can set a message size to 16 bits so that everyone communicating through this protocol expects the same size. Within those 16 bits, there can be information about the sender's and receiver's addresses. Participants need to know where to look for this information according to the protocol. 

How things are communicated deals with semantics. This allows the protocol to look at the meaning of the message and take certain actions. Actions could be where the data should flow to next, has the message reached its final destination and no further action is needed or if there are any errors then how should they be handled? 

Lastly, is the timing of the when the message should be communicated. This is an important question for a protocol to answer to prevent or at least limit any type of data loss. Data needs to be delivered to the right destination, in a certain order and may even travel across different protocols. Differences in networking speeds, address identifiers, and connectivity are only some of the obstacles that can cause disruptions in communication. 

Now that we have a better understanding of how a protocol changes over time. 

‍

Email, A Tale of Two Protocols 

Email was the early "killer app" of the internet. It enabled everyone from businesses e to preteens to communicate with friends and strangers. Looking at its humble beginnings to what it is now, we can appreciate how early we are on the path to building scalable Web3 protocols. 

Email is a collection of several protocols working together to create the user experience of reading, sending, and storing messages. 

• Simple Mail Transfer Protocol (SMTP) enables the sending of messages. 
• Post Office Protocol 3 (POP3) allows messages to be retrieved from a remote server.
• Multipurpose Internet Mail Extensions (MIME) are used for encoding and decoding media like audio, video, and images. 

Similar to Ethereum Request for Comments (ERC), all of these protocols were proposed with Request for Comments (RFCs) and reviewed by a community of peers. These RFCs shared the same ideals and goals that Web3 aims for. Email started as being fully decentralized, global, and permissionless. 

Every email was treated the same by the protocol. A community of server admins hosted their SMTP servers that were responsible for relaying messages across the network. Messages could pass through a server even if it was not the final destination of the message. Thus the value and reliability of the network was connected to how many servers were participating

As great as that sounds, this approach came with drawbacks. Originally messages sent using SMTP were unauthenticated and unencrypted. This opened up the doors for attackers to perform man-in-the-middle attacks and spoof other emails. As email grew from just a niche protocol to something more commercial, these vulnerabilities were more exploited.

The main driving force behind this was spam. As email user growth started to increase, so did advertiser's hunger to reach a new audience cheaply. They turned all the good things about how accessible email was and used it against the protocol and its users by sending unwanted messages across the network. This called for changes both at the protocol and application level. 

The Downfall of The Original Decentralized Email 

A protocol that was built and designed to reliably send messages across the network now had to focus on what messages were worth sending. This meant closing off and controlling the protocol for certain senders which many felt was against the protocol itself. 

The first approach was adding spammers to blacklists like Mail Abuse Prevention System (MAPS). Having a static list of spammers proved to be ineffective over time. Internet Service Providers (ISPs) decided to step in and create whitelists. These whitelists were a list of senders whose messages should be accepted by email services. 

To get on these whitelists, you needed a proof of reputation. This gatekeeping led to the centralization of email providers. Now roughly 99% of all email users are using the services of just 5 companies. This essentially closes off both individuals running their own servers or new providers from starting up. This is because there is a high risk they could be banned by their IP address much easier either intentionally or affected by a large IP range being banned. 

The Path Forward

The battle for a decentralized email is done but the war is not over. As privacy concerns get thrown aside for the need for more data for AI models or more surveillance for security, there is a growing need to break free from the email monopoly. Going full circle back to  decentralization seems like a good start on the journey to a world with a truly private and reliable way to send emails to one another.

We will start traveling on this path in the next article of this series looking at the Web3-enabled future of email!

‍