Email Is Obsolete

TentativeSummary: email functionality should be subsumed by a more inclusive and better thing.

Email has been obsolete almost since it got invented. It was obsoleted by newsgroups, of which it is a special case. The correct way to think of email is that it creates a private invite-only newsgroup with known subscribers. So instead of an “address book” you have a list of channels. And instead of an “inbox” and an “outbox”, you have threaded news. And instead of “forwarding”, you’ve got crossposting.

There is absolutely nothing that email can do which newsgroups can’t do better, faster, simpler, easier and more efficiently. And then there are the things that newsgroups can do which email absolutely cannot do. For example, issuing an invitation to an outsider to join the newsgroup and have them access everything that’s been sent from an arbitrary point in the past.

Note that the above doesn’t mean that the email protocol is obsolete or that email should be sent over usenet. What it does mean is that any and all email *applications* are obsolete, have been obsolete now for more than two decades. -- RichardKulisz

My personal decades-old opinion may be similar to Richard's stance. I'd say that all the modes of communication (email, newsgroups, BBS-style forums, InstantMessaging -- which in a broad sense has been around as long as has email, btw -- etc.) are unnaturally segregated, that each has certain handy attributes, and that those attributes should be aggregated into a single place where they can be individually selected/deselected as appropriate.

In other words, loosely speaking, email should borrow features from newsgroups, and vice versa, to the point where they are not differentiated. Richard gave an excellent example of desirable functionality: to retroactively grant person C access to what had previously been a private discussion between person A and B, so that they not only began participating in current exchanges but could also browse the archive of the past exchanges.

Email clients are also highly obnoxious in their extremely minimal support for searching/sorting the email archive, due precisely to this over-segregation. Searching and sorting of data archives is a relatively solved problem which mostly just hasn't been applied to communication archives. -- DougMerritt

I can accept that message storage is not of necessity "server" bound. There are storage, sharing, and replication schemes that I'm sure would handle how the content is shipped. Further, I concur that searching/sorting and correlating message content is something current clients do poorly. This bears thinking. -- gh

What Doug is saying is true. However, on this page the point I've been trying to make is that email clients could have been replaced with technology available off the shelf way back in 1980. You could have taken the article reading component of a threaded newsreader such as trn, and the channel management component of any old IRC client, and spliced them together to get something vastly superior to even the best currently available email client.

The server side of it didn't even register to me until several people repeatedly brought it up. I mean, what do I care how the messages are stored and transmitted? They should be transmitted somewhat like SMTP since it's a great protocol for transient channels that have extremely sparse membership. After all, permanent channels with extremely sparse membership (we call them "mailing lists") also use SMTP so why shouldn't transient channels? Usenet is optimized for permanent newsgroups with dense membership and so wouldn't be any good.

But note how all of these backend details (SMTP vs Usenet) are *optimization details* that have absolutely nothing to do with the nature of asynchronous textual conversation. What does have a great deal to do with such conversation is the ability to navigate messages (which requires threading) and managing the audience/membership (which requires a concept of channels). You should note though that I've explicitly said the channels would be transient, in keeping with the impermanent nature of conversation, like in IRC, and not permanent like newsgroups.

-- RichardKulisz

Note I meant to imply that transient vs permanent would be just another selectable attribute. BTW threading took a while to come to Usenet, so that historical timeline is a bit off. -- Doug

It's really quite disgusting how it still hasn't made its way into all newsreaders.

As for the transient thing, I knew you'd understand.

The best way to do transience is to tag content with a timestamp on the server and let the client take it out if it exceeds a user-provided time length. That would let everyone add their Me toos and I love yous everywhere without actually cluttering a page.

And of course, attributes should have per-page/thread or finer granularity instead of being per-subject. -- RK

I mis-read that at first to be "finer granularity of threading", which is good, too, but difficult in some ways. But since you actually said "of attributes": absolutely. And in fact, rather than a hierarchy of granularity, perhaps it could be based on arbitrary selectors, e.g. persist even lines, make transient (transiate?? :-) odd lines, except lines that are odd but prime numbers should be retained for exactly 10 days. A silly example, but why not? (To whatever extent arbitrary selectors are supported, anyway.) -- DougMerritt