Email will last forever
blog.frontapp.com
blog.frontapp.com
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.
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.
Quite a few of these email replacement services seem to add a bunch of stuff specific to some particular use-case. It might make it nicer for that particular use-case, but as soon as you need to do something outside of what's anticipated, it grinds to a halt. That means that any organization that uses something like that ends up using 3 or 4 of them, in addition to email. At that point, it's easier to just use email for everything.
Yes! A thousand times yes!
Being free-form is also extremely important. I think that the best way to add another "stuff specific to some particular use-case" is just to add additional layers of UI over current form.
Look at how HTML mail is implemented - it's just using underlying text protocol. Ditto for images and other attachments.
I don't see any reason for people not to agree on Markdown formatting, folding Org-mode style headings, rendering [ ] as checkbox that will send a special "I'm ticked" e-mail as a reply when clicked (didn't GitHub start to do something similar with checkhoxes in readme files recently?), etc. Just keep the underlying format simple and gracefully degrading to plain-text for clients who don't support your new feature.
Spam is horrible, but filtering seems to work well enough these days. (Which makes me wonder why people are still spamming, but that's a separate post about game theory.)
Unreliable delivery is perhaps on of the biggest problems with email. Largely due to faulty spam filtering.
I'm actually surprised, since I actually expected more spam to get through.
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
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...
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/) 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.
To quote:
"Recall that advertising is when someone pays you to tell your users they'll be happy if they buy a product or service.
Yahoo is an example of a company that runs on advertising. Gawker is a company that runs on advertising.
Investor storytime is when someone pays you to tell them how rich they'll get when you finally put ads on your site.
Pinterest is a site that runs on investor storytime. Most startups run on investor storytime.
Investor storytime is not exactly advertising, but it is related to advertising. Think of it as an advertising future, or perhaps the world's most targeted ad.
Both business models involve persuasion. In one of them, you're asking millions of listeners to hand over a little bit of money. In the other, you're persuading one or two listeners to hand over millions of money."
Most startups indeed do run on investor-storytime.
"Investor storytime" is a pretty good insight as well.
That's like saying that the problem with home addresses is that there is no directory.
Well, that's why you ask the people you wish to interact with the contacts he prefers. Business cards, writing you a quick email, phoning them,... You know, stuff that works for centuries.
What doesn't work at all is spreading your info for anyone to see and having to spend the good part of a day to fend off cold callers.
It's how people used to get by. It's called legwork.
Email is the ultimate "killer app" you can digitally deliver anything to anyone via email, and many folks use it for all sorts of different processes and purposes. Solutions that claim to displace email don't really displace email -- they displace common use cases that were handled ad hoc using email as a lowest common denominator. Most of these use cases cry out for a more structured solution.
For example, There are 1,000 services that displace emailing pictures to each other. There is probably an order of magnitude more services for managing tasks, approving things, exchanging quick exchanges, or performing any number of other tasks.
But at the end of the day, for the core function of email -- unstructured written communication, email is the king.
Now, what are the problems with e-mail that it's inevitable successor will fix other than, "it's old" ?
Those who complain about email tend to focus on arguing for solutions to problems that don't exist.
Email has one thing going for it that other platforms similarly didn't offer : It's the first personalised, and therefore recognisable, addressing system for an intangible communications platform that's still largely open (Ex: Unlike twitter et al. which has severely limited means of communication and, more importantly, what I can communicate).
I submit that we don't have an equivalent that's evenly matched and so no basis yet to compare it to. That's not to say there won't be one in the future, but I don't see anything close to matching it today or on the horizon.
In the beginning of the internet a bunch of open system emerged: Email, IRC, DNS, ... Nowadays it's mostly businesses that launch proprietary solutions to make $$$. What has changed since those early days?
Although it's not like new IRC daemons are not written, or new irc networks are not started. It's not dead, it's slowly evolving.
* https://jappix.com/ Jappix (XMPP)
* http://gnu.io/social/ GNU social (statusnet/pump)
* http://twister.net.co/ Twister (p2p microblogging)
* http://redmatrix.me/&JS=1 Red Matrix
The thing is: noone uses them.
There has been for years, it's called StatusNet (now GNU Social, apparently) and it's based on the open OStatus protocol. I had my own server federating with the reference instance (Laconi.ca), on which I followed a few users, like Tim Berners-Lee (who mostly cross-posted from Twitter).
I don't think your analogy with vinyl records app as emails are actually the electronic version of the communication method human have been using for hundreds (if not thousands) of years: mails. People know exactly how to use email and what exactly do they expect from emails: - to send an email, you need an address - to receive emails, you need a mail box - once you hit send, you don't have control on the emails anymore, some thing (or post office workers) have control of it - you don't expect to get a reply right away, that lowers your expectation of an instant reply - a lot of emails are replies, which means there is a strong context which is what was said in the previous emails
There are many other good things with email such as the openness, federated and robustness nature of the underlying technologies. However, just from the end users perspectives, it matches perfectly with a communication model that most humans have used and understood for many years, and one that doesn't go away very soon.
Which today, most servers do - they'll hardlink identical mails in mailboxes they control, and fan out those which need to be fanned out.
Email in that sort of medium is just visibly doing the grunt work you need to do for that type of thing over multiple distributed servers. Its no real accident that the Git distributed cloning model pretty closely mirrors this, since it was developed to replace emailing tarballs around for kernel developers.
I don't change my phone number because it's easy to keep it. I don't change my email because the address is tied to a specific provider and getting everyone to switch to using my new one may be impossible.
" A quick look at my files finds messages from from 1976 that use that format:
29-SEP-76 1935 FTP:CERF at USC-ISI Data Communication Conference/ Sept 1977
Date: 29 SEP 1976 1802-PDT
From: CERF at USC-ISI
Subject: Data Communication Conference/ Sept 1977
To: walker
cc: cerf, wd at SU-AI
22-AUG-76 0857 FTP:LEFAIVRE at RUTGERS-10 MORE ON THE LISP COMPILER
Date: 22 Aug 1976 (Sunday) 1155-Est
From: LEFAIVRE at RUTGERS-10
Subject: MORE ON THE LISP COMPILER
To: DIFFIE at SU-AI
Whit(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..)
$ notmuch search from:linus crap
$ notmuch tag +rant from:linus crap
$ notmuch count tag:rant
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.
The other way to convert it was to forward it to another system.
Among the reasons I've vastly preferred Maildir / mbox mail formats (even allowing for mbox's brokenness).
I did have to migrate twice: once when switching from Eudora using POP3 to using IMAP, I moved the mail from the local Eudora archive to the IMAP server. Then other times when switching servers - either by moving the maildir or using IMAP synchronization.
I subscribe to the old archiving adage: if it is not spinning, it is dead !
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).
https://news.ycombinator.com/item?id=8263848
I had submitted it twice before, but it got few upvotes: https://news.ycombinator.com/item?id=8157645 and https://news.ycombinator.com/item?id=8030337 It is hard to find a short title that succinctly describes the concept.
ufmace: I think writing a browser extension that configures filters + auto-responders on some popular webmails (Gmail, Hotmail, etc) would work best to entice users to adopt the technology. As I explained, many webmails already have all the necessary features to implement the concept (see FAQ 1 at http://blog.zorinaq.com/?e=76). Also, writing a smartphone app to do the same for mobile users would help. There is really no need to launch and run a full-blown webmail service.
I'm not sure what the best way to get going is. A webmail service dedicated to it would get the best UI, but there's the overhead of getting a webmail service with competitive features to Gmail, Yahoo, etc going and keeping it running. Or you could do a plugin or something, where it might be a challenge to put together a good UI and keep it in sync with Gmail's updates.
Why? So that clients that do not support this protocol will display a normal email to the end-user, instead of something not-so-friendly.
This also means that the body can be free-formed text explaining to the user what this message represents, and how to support this protocol.
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).
But I think that could be a rather cool idea - something like REST over SMTP? Know a single email address, send it a blank email get back and kick off the whole HATEOS process - which actually might more sense for something like this rather than over HTTP.
I do like the blank email + HATEOAS idea.
NB I left a comment there but it didn't format correctly. What I suggested was having the subject line be similar to the first line of an HTTP request i.e. <verb> <path>
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.
Basically the opposite of things like Google Hangouts, iMessage, Skype, Dropbox, iCloud/Google Docs, and many others.
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.
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??"
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.
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.
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=?=
The body also has to be ASCII, so just about every email client out there has to do:
Content-Transfer-Encoding: base64
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/ ) 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.
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.
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/ -- 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...
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.
What about performance though? Things like search are almost just not viable with IMAP - WAY too slow - we find ourselves having to hack the Gmail DOM to do things we should be able to do directly via the mailbox.
Seems to me that IMAP needs to be updated or replaced. What do you think of the new Gmail API?
I fail to see how a complex encoding is "simple". (Maybe I should mention that there are complex rules about where that encoding can appear, and there's two variants of it)
> It's flexible because it could support non-ascii text strings, without changing a thing.
No, clients had to be upgraded to support it.
> It's simple because the protocol doesn't care what the subject says. It only cares that it's an ASCII string.
Well, sure; why would the protocol care about it? But at some point you're encoding the email for delivery (say, you're a web service) or you're an email client trying to display it. At that point, its a deceptively simple not-ASCII string.
> but that doesn't take anything away from email's simplicity
I'm arguing that you have a twisted definition of "simple".
I had to do this once (some fifteen years ago, when finding a bulletproof library wasn't necessarily an easier task) and after reading the RFC very carefully, it still wasn't exactly a cakewalk.
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.
Source? That seems really, really high to me for an average.
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...
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.
This worked really well for us, but I think the biggest inbox only had a dozen users.
Not to mention the ability to reply to those emails to add new content to those products. Building around email as a messaging backbone is incredibly powerful.
Yeah, that's apparently what their product is trying to address:
- Email is not adapted to the enterprise world? Make it more collaborative. Here at Front, we introduce productivity and collaborative features in a standard email client and let companies work as a team on all their incoming emails.
I had a job where I had to deal with a team inbox. It took a bit of work to get it working well. I wasn't in that job terribly long, so I don't know very much about the problem space. But, yes, it was a pain. And I hope they really do have something better to offer.
plug: for this reason we're developing a full-stack email service in Node comprising client and server apps (end plug)
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.
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.
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.
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.
That's the foreseeable future. Anything beyond that is speculation.
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"
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.
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.
[0] - http://emotiv.com/
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.
# 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
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.
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.
Are you being serious, or kidding? I honestly can't tell.
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.
There's nothing "subjective" about logically refuting one sweeping general claim with a counterexample from ones own experience, unless we're getting really postmodern about whether people actually recall others referring to email as impersonal whilst possessing email addresses or just perceive that to be the case...
</pedantry>
Email is broken.
Disagree? I'm sure your response expressing your disagreement won't end up in the spam folder.
- Workers check their emails an average of 74 times a day"
LOL