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.
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.
Your summary makes me think that the reasons for which huge number of people uses Excel as a database at work are very similar. There is such a thing as not enough flexibility, too much structure.
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.
I'd add one more thing to ubiquitous, distributed, and federated, and that's free-form.
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.
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.)
Filtering doesn't work well enough at all. The fact that you can't be sure if your email was received is a problem. Many companies have over-aggressive spam filters and the recipients sometimes never even see the emails in their spam box - they're either bounced or black-holed. Often this is done by blacklisting IP addresses. When that IP happens to be the mail server of a service provider with many customers, when one of them sends spam, all of them get their emails blocked.
Unreliable delivery is perhaps on of the biggest problems with email. Largely due to faulty spam filtering.
There's also the fact that the email format (something that is specifically not instant or near-instant, is primarily text, and works well in limited bandwidth situations) is well suited to interplanetary messages. I hope we will have that "problem" soon!
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?
IRC is for multi-user on-topic chats (eg: support, help channels, or specific topics, etc), while XMPP is more for personal IM. Plus, XMPP is open, standard, and decentralized.
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:
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
Relay.js is a user friendly IRC client, see http://relayjs.jit.su/ for a demo. Converse.js (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.
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.
I assume the only reason people boldly claim they will kill email is so they can get VCs excited about their disrupt strategy. It's always about taking out an entire existing industry or system (see Uber).
I think that Maciej Cegłowski got it right in his talk [0] with the concept of investor storytime.
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.
I've re-read that a few times (and created my own local copy with some simplified and fixed HTML -- it's missing a section heading and has a slew of un-closed anchors). My opinion of it continues to climb. It's well up my list as one of the ten best recently written essays I've read this year. Maciej posts here as "idlewords".
"Investor storytime" is a pretty good insight as well.
There are a lot of people for whom I have no email address, but whom I can reach at a moment's notice on Facebook. The problem with email is there is no directory, whereas on Facebook it's easy to search for "Friends of Joe named July" or what have you and get in touch with them.
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.
How do I ask them how they prefer to be contacted if I can't contact them? Imagine an old friend or acquaintance or someone you briefly met at a party. A Facebook friend request is hardly intrusive or difficult to ignore.
FOAF. If you can't reach someone directly, find someone who might be able to. Through their work, friends, organizations, etc. Much of that is fairly easy to work out.
It's how people used to get by. It's called legwork.
Vinyl was physical. As were cassettes, envelopes, postcards etc.
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.
It would be interesting to see an alternative to Twitter that is as open as email is. eg: A microblogging system that is built on open standards in a distributed and federated way. Where no-one owns the platform and protocols.
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?
First, money showed up on the Internet. Second, if you don't stand to make a ton of it, you can keep using email, IRC, DNS... No need to launch something else.
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.
It would be interesting to see an alternative to Twitter that is as open as email is. eg: A microblogging system that is built on open standards in a distributed and federated way. Where no-one owns the platform and protocols.
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 would agree that emails are not suitable for some use cases. Many to many updates on many projects, as you pointed out, is one that email is not a suitable medium. However, I don't see that particular use case as significant by the normal Internet users, rather an enterprise problem. The fact that emails have used for that just shows its robustness and popularity (hey it's good enough and all the people I need to connect with have it, so why not just using it?)
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.
Many-to-Many isn't really bad for email. It depends on having servers which intelligently handle the duplication.
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.
As a former Pro DJ that now leads a Unified Communications Startup I find your comparison especially entertaining... and accurate. Vinyl records are still around now although they are more of a novelty item (no one is making real money on them). What has persisted is the analog user interface (especially around DJ'ing). While Email may persist in the future all your contacts and all your communications will be all together in one place. It is ABSURD that when we lose/misplace our physical phones we often simultaneously lose contacts and the ability to make/receive calls & SMS. It is also ridiculous that we can't all have a simple threaded chat log of our communications with all our friends/contacts regardless of if they were calls/SMS/Email etc. Different messaging channels are like different music genre's, many people used to think genre's like rock and hip hop were totally separate because the companies that marketed them worked hard to reinforce this distinction. As tools like the iPod gave the user more choice in how to organize and experience their music they blurred the lines between these genre's. The same thing will happen in messaging. People don't care whether it's a Twitter Message, Email, SMS or call. They just see it as all as communication and no one platform will win the day, it will be a mashup of all of them.
The seemingly forever existence of email might be due to the fact that writing an email is the same act as writing a letter. No matter how much technology we have, people will never stop writing letters. The human biological machine chooses the tools that is most familiar and the path of least resistance to achieve its goal. By evolution, we are machines that are designed to be somewhat efficient in the process of achieving our goals. Find the simplest thing that works and use it to get the job done.
Good points. And I would also observe that email's share of electronic communication is going down with the rise of Facebook and other messaging services.
True, and the cellular wave has made many phone numbers one-to-one rather than one-to-household. But for long form communication, SMS is rather painful, but it would be interesting to see something like Front built on top of it.
Why's that? At least within the US I can easily port a number between providers. But if I want to stop using Gmail and switch to Yahoo, I'm screwed. All of my accounts use the gmail address for my login, and most have no visible mechanism for changing it.
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.
gmail and yahoo have not shut down, so i've had no reason to stop receiving mail from those accounts. if i so desire, i can keep renewing a .com domain almost indefinitely for a pittance, and run my own mail for the domain. on the other hand, every 1-2 years when my mobile phone and/or internet connection contract runs out, i reconsider my phone plans. free phone number portability is relatively new thing compared to how old gmail,yahoo mail and hotmail(or running your own mailserver) are.
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 ?
Whitfield Diffie (yes, of Diffie-Hellman), just posted to the IP list an email he pulled up from 1976(!) in response to a crappy article about VA Shiva Ayyadura "inventing" email. I'm sure he's got even older emails, but the fact that he had it, was able to easily find it, and then resend it with a descendant of itself 38 years later is pretty amazing to me!
"
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
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..)
You might want to have a look at notmuch (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.
And the reality is that there's a vanishingly small percentage of that archived email that is of any use to you or anyone else. I don't have anything before about 2001 for reasons of isolated proprietary mail systems (e.g. minicomputer-based), disk failures, or just not making the effort to archive. I do have about the next 10 years saved but it's sitting in Outlook on a retired Windows system I keep around for such purposes--but there's no easy way AFAIK to translate it to another format and it's not something I'm inspired to devote great energy to.
Since I always use IMAP, the local archive format is irrelevant to me - my mail entirely lives on an IMAP server.
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 !
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
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).
That sounds like a really cool idea. Have you submitted it here? Got me thinking of pluses and minuses, and ways to bootstrap. Probably somebody would have to put up a free email service that implemented these hidden auto-replies, and maybe submit some pull requests to open-source projects to use it. Maybe Android and iPhone apps for the service that handled the phone info side. Sounds a bit big for an individual side project to me, but maybe it's a startup. It would probably help to get input from a bunch of people/projects on what they'd want for specific use cases.
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 upvoted it, though I feel the pain on getting upvotes and reads on here. I think the last article I wrote got more upvotes on Lobsters than here. You gotta get just the right title at the right time, or it slides off the front page before anybody sees it.
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.
It strikes me that this is all available with XMPP, which also has user@domain address; If we build the correct tools, XMPP can very well supplant SMTP.
Indeed, if XMPP gained enough popularity, it would solve this problem, since it already implements several of these things (personal information, location, etc), AND is extensible.
Does this have the classic XKCD 927 problem (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).
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.
I tried emailing that address and didn't get a reply.
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.
Ah yes - I was being a bit thick and I hadn't read your blog post at that point.
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>
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.
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
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.
- 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??"
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.
Encrypted SMTP is already in widespread use. Many MTA's already receive and deliver email over secure channels, and email clients (e.g. Outlook) have supported secure channels for a long time.
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.
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.
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/ ) 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.
> 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.
> To me that is a good example of how email is flexible, and also simple.
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".
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/ -- 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...
Looks interesting. IMAP is a pain! We spent months trying to get really simple stuff working for a mail client we're building (http://www.sortd.com). Actually, to be accurate it runs inside Gmail because it's more of a way to manage email rather than a standalone client, but we still need to connect to the mailbox itself via IMAP. Started using context.io, which was useful, but they went kind of wayward from their original vision.
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?
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.
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. :)
> 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.
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.
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.
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.
Well, it's not high if you count writing in. Today I spent ~2h just on a single e-mail conversation (few e-mails sent, few received). Writing thoughtfully to another human takes time.
What does that even mean "on" their emails? Actively reading and replying to email is very different from having email open or receiving emails on your phone, etc.
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...
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.
That's a problem with the end-point, not with the medium. Consider a system like RT[0]; it has no concept of an inbox, yet most (if not all) client interaction is via email. My take is that if you're tempted to set up a shared inbox, don't. Set up a ticketing system instead.
The single most important issue with email: Team Inboxes.
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.
Is that really the single most important issue? I'd lean towards privacy and authentication as being more important. Team inboxes are not really a mandatory part of email.
At my last job we had several shared IMAP mailboxes. The workflow that we used that worked fairly well was to have a sub-folder for each user. When a new mail came in, you'd first move it into your folder, then handle the email.
This worked really well for us, but I think the biggest inbox only had a dozen users.
> nearly none of the products you mentioned work without an email notification feature.
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.
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)
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.
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.
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.
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.
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;
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.
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.
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"
30-50 years is surely "forever" even in snail mail terms. 1000 years? Wow now we're talking about an era-defining technology for civilization itself! I'm going to go with your lower bound: if email lasts largely unchanged for 30 years, then it will have been the most important application of the internet era.
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.
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.
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.
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.
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).
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.
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.
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.
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."
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.
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.
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.
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.
"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.
> "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.
> 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.
They countered an assertion that people that a particular statement about the impersonality of email was "only ever" made by people without access to email by asserting the existence of multiple people they had known to make that particular statement about the impersonality about email whilst possessing an email address. Which would make the former statement factually incorrect even if the second poster's experiences were atypical.
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...
Are you kidding me? In my lifetime, letter mail has had a longer run than email. And you presume from our brief couple years with it that email is never going to be different?
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.