Hacker News new | comments | show | ask | jobs | submit login
Ask HN: What will be the future for email?
40 points by anacleto 892 days ago | hide | past | web | 81 comments | favorite
Email is probably one of the the oldest (and most used) services of all time. Email killed the Fax and Letter Writing in general. Today, it is the de facto communication tool for businesses.

In recent years were born hundreds of services that have tried to make email less painful.

In your opinion what will be the future for email?




> In recent years were born hundreds of services that have tried to make email less painful.

Most if not all of those services were proprietary and tied to the success of one company. Only the Darkmail alliance to the best of my knowledge is actually putting out a new open protocol not tied to their bottom line. Not sure if they have actually put out an RFC yet.

It's like people saying Slack will one day will replace IRC or XMPP. It will never happen. It may if slack started as it's own protocol with a simple RFC and the company was an implementation of said open protocol. Offering a paid option with the option to also do it by yourself for free.

The future of email will start with a new open standard and RFC everybody has access to. It will offer benefits not facilitated by current technologies and will be easily adopted when such happens. Until this happens though there is no reason to replace email. Companies are not going dive into one company and create some massive monopoly who will then hold them hostage.


> It's like people saying Slack will one day will replace IRC or XMPP. It will never happen.

XMPP has already been "replaced" by Google Hangouts, Facebook Chat, and WhatsApp, which are all proprietary extensions of XMPP. Very few of my friends use a chat service which allows XMPP federation. Facebook chat doesn't even allow you to use a third-party XMPP client anymore.

"Embrace, extend, extinguish" is still very much alive.


I've been using Facebook chat via bitlbee (which uses Jabber/XMPP) for several months. It was supposed to stop working on April 30th, but for some reason it does still work.


I really don't see how it was replaced. Now we just have three or more smaller products that some people use.

many people still use XMPP and magnitudes more use XMPP and don't even know it.


I use fb chat with chat secure on android. Xmpp seems to work fine?


How? According to https://developers.facebook.com/docs/chat XMPP access was disabled at the end of April.


Oh. Well, then I used to use XMPP with fb chat :-/

(I'm not sure when they killed it - chat secure doesn't appear to log in now, and the last message I received via fb was apparently on May 4th).


Hm. It's back - Just got a fb message via xmpp.


I found that group chat on Facebook doesn't work through XMPP.


True enough.


XMPP (sadly) seems pretty much dead. Even among CS students adoption rate is <10 %, client situation is quite messy, ... I still don't know an alternative that could replace it entirely in theory, but in practice it IS replaced by other things.

Slack gets a lot of things right (including things like the IRC bridge), although I'd very much prefer something like it on a federated platform.

Most messengers nowadays seem to be obsessed with mobile, single-device use, which just doesn't work for me.

E-mail isn't a messenger though, and as such is only indirectly replaced by those. It also works surprisingly well, despite spam (filtering) and other hurdles.

Combining these would be a big thing to figure out: The messenger-like, "attention now" and the more traditional e-mail/letter like "long form, read when you get to it".


> In recent years were born hundreds of services that have tried to make email less painful.

I actually haven't seen many services that try to make email less painful. Most services I've seen have tried to kill email, and almost always by replacing it with a walled-garden, closed protocol.

So far, email has resisted this, and I really hope it survives. Email is a truly federated, truly open protocol, and distributed open protocols are by far the best way to encourage an open exchange of ideas.


There have been a fair number of attempts to kill email, but I'd say there have been many more products aimed at enhancing it. Popular examples are gmail and spam filters. Neither of them are native "email" concepts and did not exist until email became tremendously popular, and both made e-mail considerably less paintful when they were introduced.

For many more products that enhance email (and a few that try to kill it), check out this list:

Email Apps - Things that make email less paintful": http://www.producthunt.com/e/email-apps


I'm not sure how gmail makes email "less painful"? I'm not even sure it makes webmail less painful.


Really?

With Gmail, you set up an account, then you start sending email. It doesn't get easier than that.

It's easy to take for granted the sheer number of things Gmail and similar services take care for you. I've recently set up my own email server for fun. Now that was painful. The number of settings I had to twiddle with is definitely way too much for the average user.


How is that any different from Hotmail or Yahoo? (Web)mail as a service is about as old as http, smtp and imap. Hotmail even was a cool startup runnning on all FreeBSD before MS bought them up...

I don't think it makes sense to compare X as a service, to implementing X as a service. Of course it is a bit of a hassle to set up email. But it's not really that hard: the hardest part is probably setting up SSL certs. Now, if you want to complicate things with spf/dkim, anti-virus and greylisting -- things do get a little complicated.

Personally I think spf is strange band-aid, and luckily I get bye quite well with just greylisting against spam (most spam I get is actually to a throw-away address that got leaked in the Adobe/Macromedia hack: yay site-specific email address!).

This here, is an example of what I mean:

https://scaron.info/technology/debian-mail-postfix-dovecot.h...

It's not exactly rocket science[1] for someone that is able to set up a secure server with password login disabled and only regular-user login via ssh keys -- which I consider the minimum for any internet-facing system unless you have a very special use-case, and a really good plan.

Now, if you can't set up a server -- you can't set up a server. I'm not saying we shouldn't make it easer -- eg:

https://blog.sandstorm.io/news/2014-07-07-mailpile.html

or:

https://blog.sandstorm.io/news/2014-08-11-roundcube.html

(Note, these both rely on sandstorm.io handling incomming smtp, as far as I can tell. At least for now. Not sure if allowing stmp/imap in/out of a sandstorm.io-container is likely to be implemented -- but then again setting up a sandstorm cluster/cloud isn't likely to be as easy as using sandstorm to run apps... such is the nature of things).

[1] https://scaron.info/technology/debian-mail-postfix-dovecot.h...

[ed: re: email and sandstorm.io -- I was both right and wrong it seems. When running sandstorm.io it is possible to set it up to send mail (requires a working smtp-server), and receive mail (requires some twiddling and ability to set up a (sub)domain with proper MX records, or a traditional smtp server set up to forward email into sandstorm.io. For more info see: https://github.com/sandstorm-io/sandstorm/wiki/Configuring-y... ]


To some Gmail may not been very different from Hotmail or Yahoo Mail, and email predates those products as well. All three were invented with hopes of attracting users by brining a better experience to email. That was precisely the point of my comment—that there have been a large number of products that have been introduced to enhance email.

A few of these products have been very widely adopted. Some others have been adopted but to a lesser degrees. Some (e.g. spam filtering, which used to be completely independent of mail clients/services) have become so universal that they are now shipped as features of the clients themselves.

Sometimes products are so successful that it's hard to remember what it was like before they came out. While every person has preferences for this or that service, there is a reason why so many people now use gmail instead of what they used previously, which was often their ISP provided address and a desktop client. Good clients are just one such example.


GMail was probably the first widely used client with threading and tagging instead of folders.


Not just federated and open, but flexible, extensible, lightweight, fault-tolerant...

We might build something radical on top of RFC 821, but email's flaws are not challenges that need solving at the protocol level.


I've thought about this on and off for a few years and have one thought: e-mail will find a way out of the inbox. It is now an almost ubiquitous way to deliver something to a contact, especially on mobile.

I know this is fuzzy, but I imagine Facebook notifications being sent via e-mail and if Facebook is "installed" either on the device or via opening the browser, opening the e-mail would deliver you to Facebook, or just display as a regular e-mail otherwise. Taking this one step further: if I deliver you a to-do list item, it would open in my default to-do list app making e-mail more of a platform or launcher than anything else.

If you ever figure out how that would work, let me know. I've tried and haven't been able to connect all of the dots connecting those sending the e-mail and those receiving the e-mail as a platform, how it interoperates and where to start. I'd use the hell out of this though.


>> I know this is fuzzy, but I imagine Facebook notifications being sent via e-mail

A while back I envisioned an open-source Facebook app. Updates would be sent through email. The email client would recognize such a message and forward it to the app. Decentralized Facebook with direct communication would be great for users. I envisioned much more than just that, but you get the idea. By using email, things can be non-realtime, distributed, and private. There are already protocols for encrypting email, so not even your ISP could monitor your stuff.


Wow, I had the very same idea. But everyone I told the idea basically said: "email is a horrible protocol stack, you don't want to build anything on top of it" or just something like "email is dead". I still think it is good idea.


Like many things, it's a fantastic idea for people and a poor idea for business. The main advantage is that it keeps business out exactly opposite of how facebook invites it in and ruins everything.

email is a fan-fucking-tastic protocol stack BTW. It's detractors all want to do something the user doesn't want or need.


"fan-fucking-tastic protocol". I agree completely. it's time for our systems to centralize email as a first-class citizen and treat it as among the main ways to interact with the system.

Ping me at sethjgore@gmail.com if you agree. I'm organizing something and I want to have people who think email is still underused onboard.


Are you pursuing your idea? I am organizing a team focused on building a system that centralizes email as an essential mode of interaction.

Ping me at sethjgore@gmail.com if interested.


I also buy that it looks like a great idea, and will like to see how far it can get.


How far do you want it to get? Ping me at sethjgore@gmail.com with the answer. I have something under the wraps that centralizes email and all messaging into a form of interaction.


> A while back I envisioned an open-source Facebook app. Updates would be sent through email. The email client would recognize such a message and forward it to the app.

I would have to replace my email client to use your social networking app? That's a problem.


Google does integrations close to this inside GMail (adding calender events, adding context-specific buttons). Outlooks calender requests are an example where embedded metadata is recognized by a lot of clients.


I suspect the problem would be like when Microsoft was making Comic Chat (a visual, comic-strip-based chat client) and their users were flooding IRC channels with useless metadata that normal clients didn't know how to filter out. I feel like this as a transitional period would be worth it though, and not significantly more painful than right now clients dealing with ical/outlook event notifications. I am really surprised nobody's made even a toy implementation of a social network on top of SMTP.


This actually sounds a lot like what the folks at Pebble are doing with the new timeline based flow. I recommend reading up on it a bit. Not that their platform is the future, but a good experiment toward what you're taking about.


Not even close. Facebook and its creation have not enough of public trust, especially after Internet.org initiative.

Actually imo no popular company has it anymore. We will wait for new big player.

There are solutions already, but no big guys would trust them to any corpo existing atm.


It would likely have the following traits:

1. Decentralization 2. Realtime 3. Spam protection 4. Contextual

1. Decentralization typically generates wide adoption, once it's able to overcome the barrier of entry to wide adoption. An excellent example of this would be JavaScript. It thrives largely because nobody owns it, and contributing to its success it's often used as a means to stave off the advantages of competing platforms.

2. Realtime meaning push, just because it's a modern technological expectation. Email frequently is realtime, except IMAP/POP.

3. GMail et.al have gotten pretty good here. Future solutions would need to be as good, ideally with some built-in mechanism for unsubscribe as well.

4. Contextual messaging would be the defining feature. It's a broad term that simply means some manner of object graph between messages that would natively support arbitrary organization of messages (flat, nesting, topic stream, overlapping (for edits), etc...).


5. Encryption as part of the core protocol, always on.


Is it possible (in principle) to have an email-like-service with end-to-end encryption so that no one other than the sender and receiver can decipher messages?


There's a myriad ways to do this. One approach would be "ecc-pub-key-in-hex+user@example.com" as email address, with user@example.com and whatever+user@example.com going to the same mailbox. This is even something gmail hasn't broken (prefix+user@gmail.com goes to user@gmail.com).

Why not just pubkey@example.com? Allowing for key rotation. Having the address be (part-of) the key may or may not be a horrible/good idea. It certainly is easy to bootstrap: smart MUAs could encrypt to the key, dumb/old ones could send plaintext, or use S/MIME or GPG).

There are plenty of attack-modes: for one - while the key/address need not be kept secret, the sender needs to know that it is corrrect/maps to the right user (eg: key1-e_smith@example.edu vs key2-eve_smith@example.edu).


Yes. Why not? You just have to encrypt the message before sending it and decrypt it after you received it.

https://github.com/google/end-to-end

I think the actual challenge is to do it with senders/receivers you do not know. I do not have enough secuirty experience to be able to answer how you can encrypt something on one end but decrypt it on the other hand without knowing the key? I guess something like HTTPS would work.


> I do not have enough secuirty experience to be able to answer how you can encrypt something on one end but decrypt it on the other hand without knowing the key?

You distribute public keys. That's what people do for PGP nowadays, and you have repositories of public keys you can access.


What if I don't want to encrypt my email?


Why wouldn't you want to?

As long as we're talking about a hypothetical replacement, it's fair to assume that doing so would come with no usability disadvantages.


A few reasons..overhead, screwups if my key got compromised and I switched to another one, follwoed by problems decrypting older mail, not wanting to muck around with keys.

While I'm very much in favor of anyone having the ability to easily encrypt if they see fit, I'm not sure how much value it really delivers for most people.


I think people are talking about encrypting while it's in transit, not in local storage. So you would want to not encrypt email for the same reasons you'd want to not encrypt wifi - ie none.


We already have server-to-server and client-server encryption via ssl/tls. We just have to turn off plaintext. If gmail/outlook/yahoo and most universities started tagging all mail received over plain smtp as insecure and dumped it in a "folder-of-shame, turning off plaintext might become a realistic option soon.

But it solves very few problems. For that sender-sender encryption is needed.

See also: http://hypertekst.net/misc/anon-remail/


Maybe - OTOH I figure a lot of people would like a low-friction way to encrypt so that if they were investigated by police or something their whole inbox wouldn't be open to anyone for the cost of getting a subpoena. Anyway, I do think it'd be good to engineer for encryption rather than trying to bolt it on afterwards as we do now. Sorry if my whimsical question was a derailment.


It would be a new standard so you could still use the former email standard anyway.


I think the problem is not so much email, but teaching people how to use email correctly. My company recently sent the entire office on a full day Outlook course. Going in everyone was thinking how this was such a waste of a day. Going out everyone was so greatful.

I personally though I was fairly proficient, what is this course going to teach me. I was placed in the more advanced group and really learnt a bunch. Techniques to optimise workload and reduce the impact of high email counts. I learn a bunch about the tasks feature, something I'd never given time to and now couldn't live without. And really liked the effect around the office to reduce the email spammers and get them using more effective lines of communication, or just shut up.

Given how used email is, I'm amazed more companies don't train people on this and general communication process. It's well worth the investment.


My problem with outlook is that many of the advanced features are only on their windows client. The OS X client is missing so many nice bits, it can almost be better to use the web client.


As long as these "hundred of services" are incompatible with each others, emails will still be useful. Can I call a skype contact from what's app or viber or app X W or Z ? no ? so don't expect me to install app X W or Z or even skype, i'll stick with emails. Sure there jabber and Co, but all these hip apps seem to reject any form of open protocols. The web is successful, emails are successful because both are based on open standards.


E-mail is also decentralized! This means anyone can join the network without a sign-up process or approval from an authority. But I see e-mail heading in a troublesome direction regarding this.

Maybe for a new messaging protocol, there need to be a computational cost, or blockchain for sending messages, to prevent fraud and spam.


What a strange question. Email is decentralized, has opt-in encryption, and is usable by anyone with access to the Internet. It might be frustrating to receive a lot of it, but I don't know what 90% of the people who use email would want to "improve". It seems to be a fairly solved problem as a protocol - the improvements are probably just to whatever client you use to access it.


I suspect that email is fine, but at present is fallong victim to an "engagement bubble." As newsletters proliferate, they will become less effective.


E-mail predates the Internet. It's been around for decades and will be around for many decades more.


Only thing annoying about emails is the long address. Other than that, how much simpler can it get? I don't see email addresses getting any shorter than they already are. They are somewhat easy to remember (a lot more so than a phone number) and they are somewhat descriptive. I don't see the form of email getting replaced by any other form. I do think there could be some underlying technical changes though.


Well, the address length depends on your domain.

I have an email address with 8 symbols.


I am not sure it will come to pass, but I would like to see the following features:

1. Email user and domain certification. For example, when I receive an email from john.doe@acme.com, there would be Email Certificate Authorities that would ensure the email was from John Doe and he works for Acme Inc. Or that johnnieD@jdoe.org is again John Doe and that jdoe.org is his personal domain.

2. Email archival services. These services would collect, store, and index email including all attachments. Would like legislation that would require all commercial Email providers to submit all of an individual's email to the archival service of the individual's choice.

3. Ability for email recipients to charge email senders an optional delivery fee. This will allow individuals to profit from being the target of spam email.


#1 already exists in the form of S/MIME, which uses the same kind of certificates as SSL and TLS do. Problem is, the certificates cost money (with the exception of StartSSL's) and basically all webmail clients don't support them.

(Aside: It does make sense why webmail clients don't support sending S/MIME email, but I'll never understand why they refuse to do something useful when they receive a S/MIME signed email. If they did, that could pave the way for something akin to what EV does for the Web, so that I could look for a green bar that says "this email is signed eBay International AG" and know I'm not being phished, for instance.)


In your opinion what will be the future for email?

I don't think email is going away. In fact, I expect quite the opposite: Email will expand as a platform for other not-exactly-realtime messaging.

For many years now we have had things like meeting invitations, electronic airline boarding passes, and concert tickets sent via email; I think we will see more things like this, and with a greater degree of integration so that for people with suitably "intelligent" user-agents, these messages will be automatically filtered out of the incoming email and processed separately -- much like we used to do with procmail, of course.


I agree with you. Just because it is decades old technology doesn't necessarily mean it has to be replaced with something. I have observed that the familiarity and usage of email among teens is alarmingly low. Then again, I don't see any better alternative to non-realtime, guaranteed delivery, suitable for both formal and informal communication and can-handle-all communication protocol like email. Perhaps todays teens will lead the way for building the alternative to email.


At Sonar (sendsonar.com), we're seeing SMS take e-mail's place for conversations. Of course, e-mail is great for longer-form information sharing. But for conversations, SMS is often the right channel.


> we're seeing SMS take e-mail's place for conversations.

Even with the 140 characters limits?


Even with the limits. The back-and-forth is fairly quick, and longer messages are just broken up into multiple messages. Like regular conversations though, people tend to keep it short and sweet.


But SMS is not free, right ? How do you deal with the ongoing operator costs?


Not free, but fairly inexpensive. Most US mobile plans provide unlimited SMS messaging to their customers, and many foreign ones provide free incoming messages.

For business, the value of reliable delivery, timely and increased customer engagement tends to far outweigh the costs.


That's interesting. I was going to ask a counter-point, such as WeChat or WhatsApp being more popular. Which I guess is the case in personal connections, but as SMS is, like email, federated, it makes sense for companies knowing messages get delivered (and is probably a lot more reliable than email in deliverability status reports), and there is a huge demand for that, not least regulatory and compliance (and regular customer service).


> For business, the value of reliable delivery, timely and increased customer engagement tends to far outweigh the costs.

Aren't there cases when phone networks get massively congested and SMS are not delivered until hours later? Such as New Year, Natural Catastrophes, etc... in that sense Email delivery is superior because it's fully decentralized.


We did receive inquiries from companies about being able to deliver SMS messages during recent natural disasters.

Turns out that people need to communicate during calamities and often prefer text and so do services that are delivering services to these people.


At least in the US, SMS can be up to 1600 characters on most carriers/handsets now:

http://en.wikipedia.org/wiki/Concatenated_SMS


From your homepage I guess I should read "conversations" as "advertising" (and related activities)?


Conversations as in 2-way messaging (customer service, sales, status updates etc..), rather than one-way advertising.


Email is pretty much here to stay. It is more that users and organizations need to "learn" how to manage emails better. Furthermore, email might not be the main way of communication with your customers anymore, but still will be one of the main pillars.

This is one of the reasons, why I started my 6th company called Helpmonks (http://helpmonks.com) in this space. It simply helps organizations to collaborate on emails. My company is not the only one in this space.


Hope people will stop send HTML-formatted emails.


Given that businesses can track when (and from what IP) recipients open those emails through tracking images, that's not likely to ever happen.

Although, of course, you can always choose not to open html emails as html.


That is a pretty serious bug in whatever email program allows tracking images to work in email. Seems unlikely anyone would use such an email program. Which email program are you talking about?


If your e-mail program sends a HTTP request for an image based on an "img" tag in a HTML-formatted e-mail, it can get tracked based on the URL.

Many e-mail clients will not show images from e-mail addresses that are not in your contacts list for this reason (for example, Thunderbird). They make the user click a button to make the decision to proceed with the image download an explicit action.


All of them that I use commonly. Outlook, Thunderbird, and Mail.App all do (though in each case, the user has some control over "download external content?", often on-click).


why?


I hoped to have seen more services built on top of email, especially IM. Products using email as a transport layer rather than the presentation layer per se. But I guess, its inherently slow and tough to scale with its default architecture, considering the overheads.


I feel the only "tool" to make email less painful is to teach people how to use it.


In the same way that fax and letter writing still exist, email will always exist. We still don't have any other system for global personalized store-and-forward that is remotely transparent (ie. bigcorp-independentish), much less free.


Probably a controversial opinion, but I feel Google Wave's model is going to be the future of Email. Not sure how far in the future, my best estimates are 5 years at lease.


Maybe this is the future.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: