Beyond E-Mail

E-mail was inherently peer to peer in its original implementation—a message from a user at a terminal on one machine to a user on another, something that underlies the basic syntax of the “user@machine” address invented thirty years ago by Ray Tomlinson to streamline a feature that was already then some six years old.

Over time, however, this direct user-to-user communication became more indirect. The user model of terminals directly connected to respective mainframe computers evolved into a situation where most had individual transient connections from local PCs to the network and could not support the protocol requirements.

E-mail transport presupposes a constant connectivity on the part of the recipient service, so it’s not practical in the dial-up situation for each user system to incorporate its own mailbox server. Instead, host systems provide both mailbox services and sendmail services for large groups of users, each of whom access the services with local client software. The e-mail addressing model (now based on repointable domain rather than a specific machine) ensures that the sendmail service finds the host mailbox service of the addressee. This indirection has become the prevailing e-mail paradigm, and the concept is illustrated in Figure 6.1.

Note that nothing in the network architecture prevents using local machine implementations to send and receive e-mail directly, for those who can and wish to do so. The practical requirement is merely that the user’s e-mail address properly translates to a machine running mailbox software that is online regularly. This ability to receive e-mail correctly is also a prerequisite to compliant sending, because the sending system must be able to receive e-mail response messages in case of problems.

Despite the sometimes problematic extensions of e-mail formats (rich text, html, forms, attachments, media content, etc.), an ongoing evolution, the underlying e-mail protocol is an open and uniform one, not dependent on platform. This means that anyone with an e-mail address and an e-mail client (or a web browser and access to a webmail service) can in principle communicate with anyone else. Anyone can implement compliant software.

Bit 6.1 E-mail is an open, uniform and extensible, albeit asynchronous and low-priority p2p (server) protocol. Easily the most popular application of the Internet, e-mail early became its killer application for the general user base, but evolved away from user p2p.

Unfortunately, e-mail got the short end of the stick with regard to network priority, so network congestion and other problems can quickly stall e-mail transfer. In addition, some mail “vanishes” in the system; undeliverable without error responses reaching the sender. The built-in ability to request delivery and read receipts can’t compensate for this uncertainty, because the problem of unsolicited e-mail abusing these requests to confirm valid addresses, along with issues of corporate security, have led to the default mail server and client behavior of ignoring such requests. Lack of receipt responses therefore tells the sender nothing.

E-mail however is not a real-time conversation; it’s a ping-pong of message and reply separated by arbitrary time delays. And this is perhaps, at the same time, both the greatest feature and failing of e-mail.

• Feature, because it allows recipients to deal with messages at their own convenience, without interrupting the tasks at hand. (Notwithstanding the fact that in practice many users with constant connectivity still allow themselves to be interrupted by incoming mail; stressed to formulate an immediate reply, as if they were answering a phone call.)

• Failing, because people prefer real-time conversations, as in telephony. In the text-based message context, this translates to immediate end-user delivery, which e-mail is not guaranteed (or, guaranteed not) to be.

This latter preference for real-time communication paved the way for both chat and instant messaging as strong contenders for the title “killer application of the Internet” (at least for people who frequently sit in front of a computer).

In passing, server-relayed chat over the Internet broadcast to connected members is not considered user p2p, although the many IRC servers are themselves peer connected. IRC however can often serve as a valuable precursor to user p2p by allowing presumptive peers to discover each other and initiate direct contact using other client technologies, sometimes built into the chat client itself. Some p2p client software therefore includes IRC chat as an extra component or use a special automated IRC channel as an “out-of-band” means to distribute node lists or other information. General p2p development discussions are also often held over chat.

Somewhat confusing is the way the term “chat” is sometimes used both for broadcast relay to multiple users and for private messaging over a true end-to-end connection. A separate group of applications became dedicated to the latter, and IM rapidly emerged—IM is the term used here for the peer-connectivity version of chat, which is considered in detail in the next section.

Net-Babble

This flip heading refers to instant communication over p2p networks. Conversing with social or professional peers always seems to be the primary interest of users, irrespective of medium or other pursuits.

Early in the book, telephony was called the earliest p2p technology—not because of the technology’s inherent characteristics, but simply because that was the way people came to use it. The implementations adapted. As we’ve seen, this insatiable desire for personal communication has driven the evolution of telephony to the ubiquitous personal cell phone. Never mind that this mobile mode of phoning is significantly more expensive than using the older fixed-location phones, people prefer to use it even for the most trivial connections.

Along the way, other direct modes for conversation developed. IM provided a text-based analogue to a phone conversation, over LAN or over Internet; useful for those who often sat by their PCs. IM is faster and more convenient than e-mail because it’s usually a real-time conversation, just like a phone call. It’s not as fast or convenient as a real face-to-face conversation, but then neither is a phone call—both lack important nonverbal cues. On the other hand, both IM and e-mail have as written text a form of persistency and can be archived.

A special convenience of IM is that it transparently supports an intermediate form of delayed response that’s socially less demanding than a real-time conversation. Thus, the first impression of an IM conversation—that user A connects with user B, they exchange typed messages, and then they disconnect—is not representative.

In practice, the IM situation is more commonly that user A is doing something and needs an answer to a question. A knows that B on his “buddy list” probably knows the answer. Now, user A could phone B, but A is busy and knows that phoning often leads to longer conversations. Phoning just to ask a short question risks seeming rude, and there’s the risk of interrupting B—user A doesn’t know what B is doing beforehand. E-mail would risk being too slow if B doesn’t check his inbox that often.

Bit 6.2 That IM implements the notion of user presence is its greatest asset. IM needs presence because its primary focus is on immediate end-user delivery. Neither phone nor e-mail has this feature. (Cellular phones might get it.)

Extensive presence information was readily available on early Internet-connected systems because users had open sessions to well-known multiuser systems, and friends and colleagues could easily tell who was connected where and whether they were actively online. This kind of user information, still commonly available in the Unix and Linux environment, became obscured by the increasingly distributed computing infrastructure and the lack of a standard way to make presence information known to other peers. Different (p2p) technologies have tried to remedy this lack, though often in proprietary and nonstandard ways.

An IM system can, even with fairly simple presence information, in advance let A know if B is available for a quick question by simply indicating the online and presence status B currently has. If so, A can send a one-liner IM message to B and get back to other work, confident that B will respond immediately if it’s convenient, or later if not. A flurry of follow-ups might result, or the single answer might be adequate. There’s greater immediacy to an IM message than e-mail, because the client is on-screen to show notification, but it’s not as intrusive as a ringing phone.

However, one major failing of the current generation of IM technologies is their lack of security—increasingly seen as a serious problem. Current popular IM clients usually communicate without encryption or proper authentication. In addition, they tend to pass through other security measures such as corporate firewalls without being subject to their restraints or filters.

Another serious failing is that unlike e-mail, the current dominant IM technologies implement both proprietary and intentionally incompatible networks. Members of one network can’t communicate with members of another. It’s therefore not unusual that a user must install several incompatible clients to reach important contacts. This issue is examined in the next section.