
Email will last forever - mathouc
http://blog.frontapp.com/email-will-last-forever/
======
ChuckMcM
I find it interesting to contrast 'forever' with another technology that will
last forever 'vinyl records'. I expect there will always be point to point,
store and forward communication channels, but those channels have existed for
millenia, from travelers who stacked rocks to tell those who came after where
the trail was, to people who send compromising photos of themselves across
cellular networks. So if we set aside the tautology for a moment,
communication channels get morphed into a solution for a particular need,
regardless of how well they service that need, and when there is a
particularly wide disparity between need and implementation, there is an
opportunity to create a better channel.

My current favorite example is Trello as a way of communicating activity
status from many to many on many projects. Something email does poorly (but
has been used for in the past) and Trello does brilliantly.

But lets look at the points one by one.

 _#1 everyone has an email address_ \-- sure today they do, and 25 years ago
nobody did, and 25 years from now its possible everyone will have a
"fooservice" address.

 _#2 email is flexible_ \-- see my point above, flexing is not the same as
serving.

 _#3 other stuff is great for professional communication but we still use
email._ \-- and before that inter-office memos.

I get that these guys (Front) are invested in email sticking around but I
would note that putting an adapter layer in front of it is no more, nor less,
efficient than putting an adapter layer in front of TCP/IP or smoke signals or
a 45 year old text file transfer protocol, whether or not "email" in the form
of SMTP will survive should be irrelevant to Front, the question should be
will the need for their service survive.

~~~
TeMPOraL
My opinionated 2¢ on why e-mails will live while many an "e-mail killer" dies
mourned by no one.

E-mail is just better way of doing snail-mail, a technology that we had since
we first invented writing. One could say that our whole civilization is built
on such communication, as one could not conduct business, make a war or govern
a country without mail. E-mails is just the same, only faster, and it shares
all the benefits with the snail-mail medium. Interestingly, many of those
benefits are also shared by... phone.

Why snail-mail, e-mail and phone calls do better than others and will outlast
random fads is visible if you look at the structure of the medium. The main
features those three forms have that various "e-mail killers" don't are:

\- ubiquitous - you can reach anyone...

\- distributed and federated - ...anywhere, without caring about whether they
subscribe to the same service as you.

The last thing is important. When I send you a snail-mail, I don't know or
care how the post office works in your country. When I send you an e-mail, I
likely don't know (and again, I don't care) if you pay for your mail server
and to whom. When I call you, again, I don't know or care who provides you
cellular service. I don't even know what kind of device you use to receive
that call.

No single entity owns snail mail, e-mail or the phone network.

On the other hand, with Facebook Messenger you can talk only to Facebook users
on Facebook platform. With Asana, I can only talk to other Asana users.

The reasons those services die quickly (when was the last time you ICQd
someone? MSNd? or <insert your national IM equivalent that no one uses nowdays
anyway>'d?), and the reasons I STRONGLY WISH THEM TO DIE A QUICK DEATH for are
_greed_ and _hubris_. I go to Asana web-page (I don't mean to single them out,
apply this to any other similar service) and I can see that idea, "we will
replace e-mail, _everyone_ will use our service and we will rule over in-
company communication!", floating in the air. No, this will not happen. There
will always be people who won't use your service because they don't like your
UI or like a competitor more. But what you're trying to do is to throw away
freedom of collaboration and interoperability to earn a quick buck. This is
damaging to communications, damaging to society, damaging to humanity, and
fortunately will disappear quickly into oblivion, like countless other similar
startups.

Want to create an "e-mail killer"? Apply some humility. Accept that you will
not be The One Gateway to Human Communication; it would be bad for everyone
(yourself included) to become one. Just aim for a federated protocol, awesome
UI and play nice with others. Sure, success will not be yours only; many
others will profit in the same space as you. But embrace that. Wanting to keep
everything for yourself is just greed.

~~~
userbinator
I agree with your reasons, but it's interesting to consider that realtime IM
is one area that, while there exists a standard, simple, and scalable protocol
that's been around for a _long_ time - IRC - it's nowhere near as popular as
the proprietary alternatives that followed. IRC usage is declining, and of the
people I know, the majority have never heard of it. Yet almost everyone knows
about email, AIM, MSN Messenger, and now Skype. What lead to this huge
difference? Is it just the triumph of marketing client software, or is there
something else?

~~~
TeMPOraL
There's IM the one-to-one communication, and there's IM the multi-user chat.
Those are two different concepts, they have their own mechanics of working and
are treated differently by society.

But since you brought it up, let's talk about IRC. I'm betting its lack of
widespread success is because of the general UX combined with some historical
mishaps.

There are things you need to think about when IRCing, like:

    
    
      - servers
      - channel discovery
      - NickServ, ChanServ
      - channel modes
    

that all boil down to a. thinking, b. learning, and c. typing magic
incantation into a command prompt. It all gives off this complicated, "techie"
vibe.

Remember that the general population can't use a computer [0]. That level of
involvement is already too much for people to start using it without a strong
reason to do so.

I remember when I started IRCing for the first time. There was another
solution, that captured much more users - the web chats. Those ugly, scammy
looking Java applets embedded on news portals. They solved all the above
problems, i.e. you didn't care about "servers" or "connecting", all channels
("rooms", they were called) were listed on a website and there were no magic
modes or something, just users, administrators and kicking (and you as an user
had only to grok what "being kicked/banned" means).

And of course you could post rainbows and cat gifs and animated faces made by
a crazy artist on drugs.

Chats ultimately mostly died, having gained the (deserved) reputation of
scammy and ugly places. Or maybe because society still thinks that talking
with random strangers on the Internet is something weird and/or dangerous, I
don't know.

Anyway, back to the topic of technological obstacles. At my local Hackerspace,
every now and then we invite people to our IRC channel, and sometimes those
people are not exactly of computer-competent type. A good way to do this is to
point a person to a IRC web frame, that is pre-configured with server and
channel names. From his point of view, it's just like entering that old-school
chat, except that it looks less crappy. After that person hangs out a bit with
us and likes the place, we teach him how to install and configure a best-
suited IRC client.

If the IRC is ever to reach popularity again, I think someone needs to build
a, pardon the startupy meme, GMail of IRC. That is, an UI that looks good,
hides complexity from you. An UI that lets you click through everything, and
explains things like "+v", "@", "-c" or "NickServ" in human-readable terms.
With icons and colors and simple sentences.

Then there's the marketing angle, but I bet you, if Google ever built an IRC
client for massess, we'd see a great resurgence of this protocol

[0] - [http://coding2learn.org/blog/2013/07/29/kids-cant-use-
comput...](http://coding2learn.org/blog/2013/07/29/kids-cant-use-computers/)

~~~
quoiquoi
Relay.js is a user friendly IRC client, see
[http://relayjs.jit.su/](http://relayjs.jit.su/) for a demo. Converse.js
([https://conversejs.org/](https://conversejs.org/)) is an XMPP web client
that supports XMPP conference rooms. So I'd say we already have good, nice-
looking clients and there's room for improving integration on a single service
to reach for the masses.

~~~
TeMPOraL
I've never heard of those tools before, thanks.

Unfortunately, Relay.js seems to not support colors in IRC, i.e. the "^C3i'm
green^C" mIRC encoding. But it looks sweet though, and if one could just skip
the "type the server and channel name" (i.e. embed on a community website), it
would pretty much mimic the chat experience, only better :).

Anyway, so even if we have examples of pretty, somewhat simple and good enough
XMPP/IRC clients, the next step is to get them to the world at large. That
pretty much leaves marketing to focus on.

EDIT:

Somebody should bundle a pre-configured IRC server and a webserver hosting
Relay.js into a Docker/Sandstorm
([https://sandstorm.io/](https://sandstorm.io/)) container set and give
it/sell it to companies as "awesome internal collaboration facilitator that
improves communication and helps empower the teams to build products for the
next generation of the web", or sth.

------
liotier
No one mentions portability, but I believe it is a wonderful property of email
- I have more than 15 years of email, moved across various servers and clients
on various operating systems and it is still available and functional. What
other personal communication channel is that resilient to technological change
?

~~~
ibisum
True. But on the other hand, its still (against all reason) too hard to
actually _do_ anything with such massive archives unless you really prepare
for it .. like you, I have more than 15 years of email collected over the
decades, but actually being able to do something productive with it depends on
just how much time I want to spend setting up a system that can handle the
mbox files of the 80's, the Eudora archives of the 90's, the Mail.app sql-
database of the 21st Century, and so on. It has persisted, dear mail-format,
but oh what a mess it _still_ is after all these years. I'd kill for a
solution that just gives me my own full-text search engine to query/manipulate
this archive, without first having to configure stream-plugins to do text
conversions and so on. I guess this is one of those cases where I should just
set up a dedicated Linux machine (finally, a use for an rPi!) with all the
years mails, and promptly set a text search tool on the problem .. trouble is,
can I do that without having to train the thing to handle SMTP headers first?
Intuitively I'd say "probably this is a done deal out there somewhere" but a
part of me still cowers at the idea ..

(And before anyone mentions it: no, google is not my solution. I want to do
offline manipulation of decades of mail archives .. not just turn it over to
some Entity, Inc. to solve..)

~~~
rakoo
You might want to have a look at notmuch
([http://notmuchmail.org/](http://notmuchmail.org/)). Said abruptly, it's a
wrapper on top of Xapian (the search engine) that you feed with your email,
after which you can query using mail-related queries:

    
    
        $ notmuch search from:linus crap
    

and, most usefully, tag:

    
    
        $ notmuch tag +rant from:linus crap
    

Tags work exactly how you would expect them to:

    
    
        $ notmuch count tag:rant
    

There are myriads of frontends (even a web-based one [0]) if you want to go
further than cli.

You're gonna have to transform everything to maildir or mh though (unless you
can somehow iterate over your mails from the formats you have), but I guess
that's not too unreasonable to do anyway.

[0] [https://bitbucket.org/wuzzeb/notmuch-
web](https://bitbucket.org/wuzzeb/notmuch-web)

~~~
ibisum
Thanks for the recommendation - I'll check it out!

------
mrb
The fact "email will last forever" is precisely why I believe it is absolutely
the best protocol to build automatic services to access and share personal
information. I have spoken about it here:
[http://blog.zorinaq.com/?e=76](http://blog.zorinaq.com/?e=76)

Edit: Someone1234: you don't need to wait for companies to support my
proposal. It already works today with Gmail: try my live demo on
pm33at@gmail.com - it works by leveraging standard auto-responder features. As
to the comparison with XKCD 927, it is invalid: my proposal is radically
different from anything that currently exists, because it is decentralized
while all current personal information sharing platforms are centralized.

Edit: rakoo: yes, XMPP would work too, and would probably be a bit better than
SMTP because it is real time. However in practice building something over SMTP
has more chances of seeing success (because not everybody uses XMPP, but
everybody has email).

~~~
Someone1234
Does this have the classic XKCD 927 problem
([https://xkcd.com/927/](https://xkcd.com/927/))? Also wasn't this what XML
was meant to solve (a single unified standard for interop)?

It could "work" but unless you got at least Microsoft (Exchange server,
Hotmail) and Google (Gmail) to sign up then it won't go anywhere (which is
largely the issue with all email momentum, Microsoft and Google have no
interest so it cannot move forward).

~~~
silverbax88
XML is a markup to establish protocol, not a standard by itself (other than
the basic syntactical standard). A standard would be something like MathML.

------
AndrewDucker
The reason email will last forever is that nobody owns it.

If Twitter goes bust then you lose all of your tweets. If Facebook goes bust
then all of your status updates go out of the window.

But email is an open, free protocol that anyone can implement and is
deliberately designed to be decentralised.

And so the ecosystem will last as long as a few people find it useful.

~~~
ldng
Exactly. Email is so resilient because it's an open decentralized protocol.
Every other alternatives I've seen is closed and/or centralized in a way or
another. No wonder they fail.

------
pearknob
I think that a lot of "startups" are using the fantasy of an email-less world
as a marketing tactic. I agree, I don't think email is going to disappear.
Whether that is a good thing or bad, it's irrelevant

~~~
daigoba66
I'm still hoping to see a resurgence in software designed around federated
protocols and architectures.

Basically the opposite of things like Google Hangouts, iMessage, Skype,
Dropbox, iCloud/Google Docs, and many others.

~~~
pearknob
Totally agree. Which is why I'm excited about the Gmail API and Inboxapp

~~~
walterbell
Is that centralized or federated?

------
usethis
Sure, email is not perfect, but it is the most flexible communication method
the internet has to offer. It is not tight to a single organization, or
"owned" by a single company and reasonably portable with an open protocol.
Tools will be invented to further optimize the experience, but in essence it
will remain the same, just like a telephone call hasn't changed. I will not
commit an essential part of my business again, to a single company's closed-
sourced product (like for instance MS Office in the past, though OSX being the
exception).

I recently started using Mailbox as my personal Email Client again, and I am
very impressed in how they "optimized" the experience. It basically converts
your emails into task items, with different priorities, in lists etc. When
combined with notes, it could make any task / note app obsolete.

Unfortunately it only works with GMail and iCloud, but I hope Dropbox keeps
investing in the product.

------
Mz
_\- Email is not sexy? Design beautiful interfaces. Mailbox has managed to
make email light, fast, and mobile-friendly. Sparrow was creating the most
intuitive and pleasurable mailing experience etc._

I wish the author had not said "etc" at the end. He is obviously very
knowledgeable about the topic. A lot of people, even people who spend LOTS of
time online (like me) have not tried out every email client out there, and
this is a missed opportunity to inform me and impress me with his depth of
expertise on the domain his company is involved in.

I am sure I am guilty of this at times, where I either assume "everyone knows
what I know" or I realize they don't and I don't want to sound like a braggart
or something but I find myself feeling like I have been told "surely, you know
all these examples and what they did different/right" and the answer is "No,
no I do not -- what did they do??"

------
hrvbr
The concept of email is too fuzzy. Is it SMTP that will last forever? This
technology is more like sending postcards that every middleman can read.
Certainly a more private alternative will replace it someday, and it should be
more spam-proof.

Also email serves many purposes. If it is to be replaced, it will be on a use-
case by use-case manner. RSS is a better alternative to one-to-many mailing
lists. Forums are a better alternative to many-to-many mailing lists. Etc.

But yes, we should improve what we have until we can replace it.

~~~
dinglefuk
SMTP and POP have encrypted analogous. Web server+Forum+Web browsers is hardly
a better alternative to email many-many mailing lists.

~~~
daigoba66
While SMTP and POP protocols can be transmitted over TLS between hosts, which
prevents reading messages along the wire, the email data itself is _not_
encrypted. A compromised SMTP server can easily read and copy any message
received or transmitted.

~~~
byerley
And, even if you use a side-channel to distribute keys between the sender and
receiver (to encrypt the data safely), the header absolutely has to be plain-
text. Governments and companies scraping email meta-data is already a huge
problem.

A protocol closer to Tor would make for much more secure email distribution,
but it would also require a complete protocol rewrite. Potential death of
email from a back-end point of view at least.

------
deathanatos
> The email protocol is simple and flexible.

Ha, okay. I'm going to include actual emails in "the email protocol", because
if you just count the network protocols you're not doing anything useful.
Emails are anything but simple. They were born in the early days of the
Internet, and no doubt time and the impossibility of predicting the future is
responsible for how things turned out — but they are anything but simple.

Email messages are ASCII only. You can _put_ non-ASCII characters into a
header however. It looks like this:

    
    
      Subject: =?UTF-8?B?SMOpbGzDtOKApgo=?=
    

Writing a parser for this is an unnecessary challenge in this day. (If you
ever need to do email, for parsing _or_ outputting, _get a library_.) Watching
a coworker unwilling to take the time to the read the RFC try to write a
parser for this… is a very special hell.¹

The body also has to be ASCII, so just about every email client out there has
to do:

    
    
      Content-Transfer-Encoding: base64
    

And then encode the body in base64, wasting space and network bandwidth.
Technically, you can send full 8-bit message bodies, but the sender and
receiver have to agree ahead of time. Either GMail doesn't support it, or it
just doesn't bother even when the email destinations are all GMail. (Or, it
could be because some IMAP client might get the message, and not support it.)

There's also that every message has a text version and an HTML version —
hopefully semantically similar — but HTML support in email clients (at least
the big ones) is terrible. (see for example [http://www.email-
standards.org/](http://www.email-standards.org/) ) You'll think support is
great on the web after you're done.

I've not covered un-wrapping headers. Or the things people think aren't valid
email addresses. (Your average Joe thinks [a-zA-Z0-9]+@<a domain name> matches
all valid emails. Oh, and that they're case insensitive too.) Or IMAP. Or
encryption. Or even whether email gets encrypted while on the wire from
Hotmail to Comcast.

> Slack pretends to be “an email killer”

I'm not sure they're out to kill all emails… just the ones that would be
better as a real-time communication.

¹Don't test your library's output email on Gmail, either. Gmail is _creepy_
good at correcting bad input. "It works on Gmail" != it's correct.

I do wish I could send restructured text emails and have the client just
render them. In theory, email has everything I need. Clients just need to
support it, that's all. I'll admit, that is kinda cool.

~~~
EntiPag
> Email messages are ASCII only. You can put non-ASCII characters into a
> header however. It looks like this:

To me that is a good example of how email is flexible, and also simple.

It's flexible because it could support non-ascii text strings, without
changing a thing.

It's simple because the protocol doesn't care what the subject says. It only
cares that it's an ASCII string.

That sounds like good engineering to me, as well.

You could argue that a new version of the email protocol could be improved to
do away with those hacks, but that doesn't take anything away from email's
simplicity and flexibility.

~~~
MetaCosm
Email is simple the way a plane is simple. As long as you don't see all the
moving parts, and get to go along for the ride, it just seems like a magical
flying tube!

I spent about 18 months on an email client project (was already 3 years in
when I joined the team). I can tell you email is insane... so much more broken
than you would expect (on all sides).

There is a reason many clients do "gmail" instead of "email". "Email" is a
nasty barely functional ball of duct tape greased with WD-40 in the places it
needs to go fast -- the fact that it works at all is breathtaking and only
explained by the fact that it is one of the "killer features" of the internet.

The number of broken clients and servers is shocking and breathtaking. So you
have to accept and expect bad data from everywhere. From the server directly,
violating the imap spec, and in the body of the message violating all sanity.
Yet, your users will see any failure as "this email client sucks" because the
OTHER older email clients have already seen this idiocy and custom coded
around it. Email clients end up being giant laundry lists of "if <stupid
server> (act way 1)", "if created with <stupid client> (render 'right' way
2)"...

The reason new email clients are relatively slow to be created, and even fewer
take off, is they are forced to deal with an insane clusterfuck of standards
and corner cases to get to that 80% good enough mark -- or simply build out to
one service at a time (we support gmail, hotmail and yahoo... etc).

There are 20+ RFCs you need to deal with the cover the spectrum of "basic"
email with calendaring across a number of servers. That is just the "good"
standard parts. On top of that you have the hundreds of server oddities that
you need to handle else your email client will fail to get email off broken
server X. Add to that the hundreds of rendering special cases you need to be
aware of (ohh, this game from old outlook, so X means Y).

After you do all that, you have to deal with spam (both how servers tell you
about it, how you show it, how you maintain it, etc) and an entire new set of
oddities (very similar but simpler) for sending mail.

FastMail has an idea floating around that appears less terrible:
[http://jmap.io/](http://jmap.io/) \-- but I am blissfully out of that
industry and simply don't care anymore.

EDIT: For the record, I agree with the article, email will be around for a
long time, it is the "point of record" \-- many of the "email killers" require
your email address to sign up... so...

~~~
grinich
That's why we built Inbox. :)

[https://www.inboxapp.com/](https://www.inboxapp.com/)

In short, the Inbox API is a translation layer between IMAP's eccentricities
and modern JSON REST endpoints. Plus it's open source free software.

~~~
MetaCosm
Wow, how long have you guys existed? I am shocked I didn't know about this
product. That is IMHO, EXACTLY the product that has needed to be built for
awhile. Get all those eccentricities into one library that provides a clean
interface.

~~~
grinich
We announced this a couple of months ago, though the company has been around
for a while. We're also just quieter than most startups. Less blogging and
talk, more code. :)

------
peterevans
Disclaimer: I work for a company for whom email is a core part of business.

Email and letter-writing go together, in my mind. Not so much because email is
a literal model of letter-writing, but rather because they give you an
important abstraction that I think we all need, which is a form of passive
communication.

You may get letters which are urgent, and you may get email that is urgent,
but the nature of both is that they are hands-off. You don't need to be
present to receive mail or email. Well, there is some physical mail that you
do need to be present for! -- that being certified mail, some package
deliveries, and those represent perhaps a different abstraction. That aside,
you have a mailbox to hold mail, and a carrier to deliver it to you. Nobody
needs to talk to you, to tell you that happened. You can go and check your
mailbox and see what you have at any time.

People who want to "kill" email may dislike the form, the implementation, but
the abstraction is useful. It will likely continue to be useful -- I don't
foresee a time when it will not be. Email, in _some sense_ , will stick
around.

------
kevincennis
> "People spend on average 2.5 hours per day on their emails"

Source? That seems really, really high to me for an _average_.

~~~
michael_h
That sounds about right to me if you include both personal and work email
time. You might be surprised at the number of people in large organizations
that spend seven hours a day actively reading and writing email.

------
talles
_Forever_ is a strong word... but I do believe that email will stand still for
some good years.

Email will last forever because email has been around since... well...
_forever_. That is one key factor that the article misses: practically
everyone is used to email. It's really tough to replace something so well
known and widespread.

I guess the desire of doing so it's due to so many people struggling with
email. How many times have I peeked people's email client looking to hundreds,
heck sometimes thousands, of unread emails.

I always had inbox zero. I won't say that for me email is a joy, but is
definitely no struggle. I guess I'm more organized than most people anyway...

------
grexi
The single most important issue with email: Team Inboxes.

As soon as more than one person works with an inbox, it sucks big time.

But I agree - email will last forever, nearly none of the products you
mentioned work without an email notification feature.

~~~
dsr_
A team inbox is almost always better handled by a ticketing system or a
mailing list or both.

~~~
mathouc
or Front :)

~~~
dsr_
A brief look through Front suggests that it is a specialized ticketing system.
I predict that, if successful, it will incorporate more traditional ticketing
system features.

------
akrymski
Any argument around "Email" should first define what email is. Does the author
mean SMTP will last forever? MIME? IMAP? Email is a way of sending a message
using a number of old, insecure and inefficient protocols. Will better
alternatives to these protocols gain traction one day? Most definitely. What
will remain of "Email" as we know it today is the addressing scheme IMO. The
universally acceptable way of messaging a user@any-host is the real power of
email, and will remain for the foreseeable future whilst transport and
encoding protocols come and go (eg VoIP succeeding PSTN). In fact, email
should last as long as the DNS system exists, given that the addressing system
is directly tied to it. Being a flexible P2P messaging system, email can be
easily extended to provide features of any "email-killer" app out there
(including realtime communication) if need be. These innovations haven't
happened simply because major email server providers dominate their existing
markets (Exchange!) and have little incentive to innovate given the high
barrier to entry for startups selling email servers to corporates. Email
clients have seen more innovation, but there's only so much a client can do to
extend capabilities of email.

plug: for this reason we're developing a full-stack email service in Node
comprising client and server apps (end plug)

------
lucian1900
It is, however, a horrifically bad protocol. We don't need a new app, but a
better protocol for unified mail, IM and audio/video. XMPP is close, but
flawed.

~~~
leonroy
I have my own opinions on the subject but curious what you see as XMPPs
failings?

~~~
lucian1900
Very high overhead (largely because of all the XML) and the implicit
requirement of a persistent connection.

There are other things, like awkward and unevenly supported voice and
encryption, but those are higher level concerns.

TextSecure's protocol is probably closest to what I'd like to see as a
standard.

------
jrapdx3
Email is wonderful and terrible. SMTP is pretty simple, and everyone with a
static IP can run their own email server. Configuring it requires some study,
but it's not too hard.

OTOH creating email clients is hard. I wrote a web server and wanted a webmail
client. Basic SMPT messaging is straightforward enough, but MIME is a
confusing tangle of protocols and rules that is difficult to understand and
implement correctly.

I mostly succeeded but it took a long time. Part of the problem is the
complexity means protocols are often violated and my webmail client has to
deal with loads of exceptions to protocol rules to work in the real world.

But that's hardly limited to email. Look at http, it has arcane rules too, and
some of the common security issues on the net are the result of "sloppily"
implementing programs using http. (You know, XSS attacks, SQL injections and
so on.)

Email has warts but what doesn't. Certainly email "replacements" will have
warts too, especially as they are extended to cover the breadth that email has
encompassed.

------
exodust
I like email and can't see it dying at all. I have several email addresses for
various purposes and it's no hassle to manage.

I have about 5 email addresses and 1 work email. It's good having a dedicated
"website sign-up" email address for forums and so on, where you don't care
about the spam level.

The flexibility in setting up your in-box how you want is a great thing about
email. I don't understand people who constantly complain about their in-boxes.
Learn to manage your in-box, I say, and stop crying about your first-world
inbox clutter problem!

I'm interested in secure online collaboration tools, and it's great to see so
many options emerging. These secure tools can easily coexist with email and
keep everyone happy.

Email is a familiar, reliable, predictable service that everyone knows about.
It doesn't get "updated" every 3 months by some agenda-driven tech giant with
ideas about how we ought to be communicating.

------
LeicaLatte
I hate the tight coupling slack introduces. It should have been called leash
instead. Glad to see it slowly going away.

Email is a product of the 60s predating HTTP itself and built to stand on its
own. Its non-invasive and loosely coupled which scales across all kinds of
people. Not just for ADD nerds like us.

------
edpichler
When Google Wave appeared on public I really liked and believed it would
replace the email. I think one day the, now open sourced, Apache Wave Project
will rebirth with: \- a fast user interface (today really sucks); \-
decentralized and easy to install servers; \- Features that are missing;

------
pkorzeniewski
E-mail is a sufficient way of communication for almost every case - just like
traditional, physical mail was 100 years ago. You can send a party invite to
your friends, you can send family pictures to your mother, you can discuss a
project with your co-worker and you can send an invoice to your customer - all
of that using a single application. If you need to contact someone immediately
- use IM or phone. Why do we need a seperate tool for every scenario? Sure,
they provide some useful stuff, but nothing beats simply opening your e-mail
client and typing a message to whoever you want.

------
josephschmoe
Email will last as long as we are thinking of computers in terms of files and
text.

That's the foreseeable future. Anything beyond that is speculation.

------
scoofy
Depends on what you mean by "forever." If you mean, say, 30-50 years, even
maybe 1000, sure, i'll give you that, but i'm still skeptical, but to suggest
that there won't be a better communication tool that comes along to replace
the written word from one node to one other, i'd say you're deluded. There is
lots of room for improvement.

~~~
gabriel34
Agreed. It might seem pedantic to call this article on its use of "forever",
but it is not. By setting this in stone you are actually discouraging
innovation. Not everyone who promises ground breaking enhancement over email
is right, but someone might come up with something.

And if the article's author really meant forever, I can envision a future of
effortless communication through PC facilitated "telepathy" or any other sci-
fi concept that obviates email. "Eternity, my friend, is a long f[ __*]ing
time "

------
baumbart
Well for me, Email is already dead. Of course, dead software still exists, for
information can not be destroyed. But, there will be more surveillance. There
will be more counter-surveillance tools becoming popular. But Email will not
stay on that list. Over the long run, the electronic mail will fall back
behind inherently encrypted solutions. At least I hope that.

~~~
jcbrand
What do you use instead of email?

~~~
baumbart
[https://bitmessage.org/](https://bitmessage.org/)

~~~
walterbell
Isn't bitmessage (like bitcoin) susceptible to traffic analysis?

~~~
baumbart
No. Bitmessage is essentially a decentralized version of
alt.anonymous.messages.

------
findjashua
I recently joined a company where bulk of the communication is done on
hipchat. I find it to be a much much better way of communicating, especially
due to the chatrooms. I now only use email when I need to have a conversation
regarding a specific subject or something I need to bookmark (star) for later.

------
jonifico
Dude, if IE6 is still around, there's not chance email is going out of
business any time soon. Period. However, with the rising of new communication
channels, we might get better at communicating certain pieces of information
over time, that's what it's all about, anyway.

------
adnsr
Something is weird about email: Everyone can pretend to be someone else. It
would be sane to reject all emails from a domain, that has no SPF record. I
was asthonished when i realized that this is not already happening. Designing
a large communication system it is just pure insanity to not include a
sentence like this in the spec: "One can only send messages as one of the
names he has power over." This could be ensured simply by SPF. It should be
safe to assume, that a domain that has no SPF-record is not used for sending
emails. I know that this is not the case right now, but it would change really
fast, if you would push an update to the SPF-checkers, to enforce that rule.
SPAM would be much less of problem than it is right now. Today you have to
block ip-addresses, which is a large mess. With this rule enforced, you could
block domains. Which are much harder to obtain and have a way smaller
quantity.

------
michaelbuckbee
To the point of needing email as soon as you're interfacing with a person
outside of your group: I'm seeing more and more options for this built into
things like HipChat and Slack (both of which have the concept of 'guest'
users).

------
cletus
There are certain phrases I hear in startup pitches that immediately cause me
to tune out. One of them is some combination of social, mobile and local.
Another is "fixing emaiL" or "email is broken".

It isn't.

With all the change that's happened with the Internet two forms of
communication have proven to be incredibly resilient: SMS and email.

SMS is resilient because every phone has it. It's portable and it's simple.
The best effort thus far at dethroning SMS seems to be WhatsApp. Sure phone
companies (particularly US phone companies) charge a ridiculous amount for
SMS. It's no longer the valuable bandwidth control channel that it once was.
But even so, I don't see it going away anytime soon.

The beauty of email is that it's largely decentralized. With something like
Facebok, you get ads inserted into your stream, you're constantly at risk of
some privacy snafu and there's always the risk the service changes in some
problematic (for you) way or disappears altogether (OK, Facebook isn't going
anywhere anytime soon but we've all had services we like get bought out and
sunsetted).

Email addresses are mostly non-portable. You can have your own domain and have
a portable address but most people don't. Just like a phone number has limited
portability (eg only within the same country).

Changing phone numbers and email addresses seems to be an infrequent enough
occurrence for most people that they don't really care about it (as a whole).

Certain services provide useful value-adds to email. Spam filtering on GMail
is a prime example. There are ads on the Web UI but hey you don't have to use
it (there are POP3/IMAP interfaces) and they aren't that offensive (as, say,
Facebook ads are).

The fundamental use case of both SMS and email is one person sending a message
to another person. Think of this like IP (the protocol). People find each
other with contacts. Think of this like DNS (kinda).

Every "email killer" I've seen has made this most important use case harder or
just more complicated and, more to the point, for this use case provides no
tangible benefits (that anyone cares about).

And in all cases you're giving up the decentralized nature of email so someone
has control over your messages and your experience. Why would anyone make that
tradeoff? It doesn't make any sense.

So forever? Well that's tough to argue. But for a really long time? Sure,
absolutely.

~~~
mrborgen
The "fixing email" / "email is broken" are quotes you only hear from startup
guys and UX geeks. Email is indeed working really well. Most people outside of
this niche seems to have no fundamental problems with it.

Just an example: I recently needed to send a script to an 8 year old kid and a
grandma at around 75. Couldn't have done it any other way than email. The
point being that email is an enormously broad platform.

Its so broad that the second you turn to mobile to solve email, you have
limited your way out the competition.

------
Mad_Dud
Couple of years ago RJBS gave a great talk about email, it's complexity and
issues -
[https://www.youtube.com/watch?v=JENdgiAPD6c](https://www.youtube.com/watch?v=JENdgiAPD6c)

------
mergy
Yes! >> [http://mergy.org/2014/04/please-stop-trying-to-kill-
email/](http://mergy.org/2014/04/please-stop-trying-to-kill-email/)

------
elwell
IMO, written communication en totale will fade away within the century.
Thinking [0] is much faster.

[0] - [http://emotiv.com/](http://emotiv.com/)

~~~
miles932
Having tried it, and recognizing the degree to which this (at least so far) is
happening in the "conscious" mind-space rather than sub-conscious/motor-
muscle-memory mind-space, typing is _vastly_ faster. Today. It strikes me as
an amazingly hard problem to separate one's "inner monologue" from "thoughts i
want to transmit". I suspect an easy cheat would be "imagine typing it out" to
create a specific, "physical" demarcation in communication types.

------
Mustafabei
Made me remember the quote by Reinhold Niebuhr: "Frantic orthodoxy is never
rooted in faith but in doubt. It is when we are unsure that we are doubly
sure."

------
lasermike026
It's insecure and it must die. To be more correct, email can not continue in
its current form.

~~~
JoeAltmaier
Right! Most of the problem is unauthentic email - spam. Why oh why don't my
peers sign their email, so I can test the signature and even file them by
source/topic? This seems dead obvious.

------
spammy_throw1
[https://zulip.com/hello](https://zulip.com/hello)

------
azinman2
News flash: startup working on email product says email will last forever.

------
andyl
There are tools to make use of HTTP in all sorts of ways. Curl, Wget, Restful
APIs, Sinatra, Grape, etc. Fast, flexible, lightweight.

Email - not so much. Want a local email server? There's Postfix - yuckkk. The
overhead of spam - yuckk. The lack of tooling, the lack of configurability,
the DNS complexity. The fact that it requires a SAAS to do shared inboxes.
Yuck.

Email could be so much better.

~~~
aaronem
What's wrong with Postfix? Sure, configuring it takes a little work, but it's
not _hard_ , especially not by comparison with Sendmail, which was the
standard everywhere when I began my career.

~~~
_delirium
I didn't even find configuring Postfix to take much work, and I'd never
configured a mailserver until a few months ago. Debian's config script
autogenerated a basic configuration for me, after prompting with a few
questions: receive email for my domain to my unix account, and relay mail only
from local or AUTH'd clients. This is the entirety of the manual config I
added on top of what Debian produced:

    
    
        # use maildir instead of mbox
        home_mailbox = Maildir/
    
        # reject obvious spam
        smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
           reject_unknown_client_hostname,
           reject_rbl_client zen.spamhaus.org
    

It has a very nice manual too, but I have not had to use most of it, because
it just works out of the box.

------
dunno
No, it won't. I distinctly remember being told by many people that email would
never replace letter mail because email was too impersonal.

~~~
moron4hire
"Impersonal" was only ever a label applied to email by people who didn't yet
have access to the Internet, jealous they were being excluded. It's the same
people who decried smartphones.

In all areas that matter, email is superior to paper letters. And in all areas
that matter, no one has proposed an alternative to email that is superior in a
way that cannot be applied to email.

In other words, whatever is wrong about email, can be fixed from within the
system. Paper letters had to become email to fix what was wrong with paper
letters.

~~~
dragonwriter
> "Impersonal" was only ever a label applied to email by people who didn't yet
> have access to the Internet, jealous they were being excluded.

This is factually incorrect. _Everone_ I've ever heard use the term to
describe email had internet access and was a regular email user at the time
they used the term. I'm sure some people who didn't have email have used the
term, and I'm sure some of those people had the motivation you describe, but
it is simply not true that it was "only ever" used by people without access to
the internet (or, more relevantly, email -- whether on the internet or
otherwise, as electronic mail existed on networks besides the internet.)

> In all areas that matter, email is superior to paper letters.

"areas that matter" is a subjective category (and, further, superiority in
each of those areas is, generally, subjective as well), it may well be
superior _to you_ in each of the areas that matter _to you_ , but those
subjective judgements may not hold more generally.

~~~
silverbax88
You say something is factually incorrect based on _your_ own experiences, then
comment on subjectivity?

Are you being serious, or kidding? I honestly can't tell.

~~~
dragonwriter
> You say something is factually incorrect based on your own experiences

Well, yes, a categorical claim that something was "only ever" used by people
with certain objective features and for a particular reason is factually
incorrect if it was ever used by people without those features or for a
different reason, so personal experience, while inadequate to establish that
it is factually correct, can be quite sufficient to establish that it is
factually incorrect.

(You'll note that while I state that the categorical claim is clearly
factually incorrect, that it is also quite likely that, while not a
categorical truth, there have been at least some dismissals that fit the
pattern that it falsely claims is the _exclusive_ pattern for all dismissals
of email as "impersonal" \-- the error isn't in saying that _some_ people
describe email as impersonal for the particular reason described, but in
claiming that that is the _only_ reason email has _ever_ been described as
"impersonal" by _anyone_.)

> then comment on subjectivity

The comment on subjectivity was on a different statement (a claim of what is
superior and what matters, both of which are inherently subjective) not the
categorical fact claim. Recognizing the difference between subjective
statements and fact claims is pretty important to being able to participate in
a productive discussion of pretty much any topic, IMO.

> Are you being serious, or kidding?

The former.

------
billpg
Looking at the listed "Email is..." statements, an important one was missed.

Email is broken.

Disagree? I'm sure your response expressing your disagreement won't end up in
the spam folder.

------
eric_cc
"\- People spend on average 2.5 hours per day on their emails

\- Workers check their emails an average of 74 times a day"

LOL

