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?
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.
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'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).
many people still use XMPP and magnitudes more use XMPP and don't even know it.
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".
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.
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
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.
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... ]
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.
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 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.
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.
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.
email is a fan-fucking-tastic protocol stack BTW. It's detractors all want to do something the user doesn't want or need.
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.
Ping me at sethjgore@gmail.com if interested.
I would have to replace my email client to use your social networking app? That's a problem.
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...).
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.
You distribute public keys. That's what people do for PGP nowadays, and you have repositories of public keys you can access.
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).
As long as we're talking about a hypothetical replacement, it's fair to assume that doing so would come with no usability disadvantages.
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.
But it solves very few problems. For that sender-sender encryption is needed.
See also: http://hypertekst.net/misc/anon-remail/
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.
Maybe for a new messaging protocol, there need to be a computational cost, or blockchain for sending messages, to prevent fraud and spam.
I have an email address with 8 symbols.
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.
(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.)
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.
Even with the 140 characters limits?
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.
Turns out that people need to communicate during calamities and often prefer text and so do services that are delivering services to these people.
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.
Although, of course, you can always choose not to open html emails as html.
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.