8 ms·

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is ex

by nxc18 10y ago

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never understood this - slack and GitHub have a lot more distraction with their social media components. I see the day coming soon when in order to work with other people I'll need to find and install one of the x tens of IM clients. The day when I can't find anything because it is in a million places and its real hard to search 10 years of conversation when messages don't have basic metadata like a subject. :(

digi_owl 10y ago
The pups always goes for the new shiny (get off my lawn)...
dredmorbius 10y ago
Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-rest, email remains an exceptionally poor choice for private communications, and there's been little real progress on addressing this, in large part because of vendor reluctance at both client and server / system level. E.g., Microsoft, Google, Yahoo, and AOL. 3. Users. Systems which work well with email rely strongly on compliance by users, which relies strongly on enforcement by communications managers or moderators. For LKML, that would be the kernel mailing list etiquette. Battles over header formats, quoting styles, and quote before vs. after exist because these strongly impact workflow and efficiency of groups as a whole. Failure to acculturise hampers the group, and acculturisation rates limit group size and growth. Much of Linus's noted "personality problems" come from the task of having to corral a group of people over which he has little if any formal control, a decidedly limited-bandwidth social communications channel (e.g., no tone, expression, voice, facial gestures, etc. signals), and the necessity TO BE UNAMBIGUOUSLY CLEAR when someone is transgressing norms. (Yes, I'm aware of HN's norms on ALL CAPS.) 4. File formats. Both a blessing and a curse: you can send anything. This means any given group can specify its preferences, but also raises the problem that there are few global preferences given. Kernel development works well with email by having specific tools and formats, from coding style to patch and git tools which create workable code fragments, to conventions for list discussion. This is strongly linked to #3 above. 5. The directory. In thinking about how email compares with other proposed alternatives, one key is that email lacks the concept of a central directory. Or at least, not a formal one (spammers may trade in same). On Twitter, or Facebook, or HN, every individual user is uniquely identified within a global directory. In Email, by contrast, what exist are addresses, which is to say, <user>@<domain>, where the domain has its own sub-directory. But there's no guarantee that domain1 would know that user1 is some valid directory entry at domain2. At best, domain1 knows how to reach domain2, and attempt delivery, via DNS, generally though not necessarily through MX records. This becomes more of a problem with ... 6. Spam and spoofing. Because there's no global directory, the validity of an email from <user2>@<domain2> cannot be assessed. In fact, there's no requirement that that even be a valid address, though as a convention it's generally considerate and useful. There've been numerous hacks to add increasing levels of authentication to email (SPF, DKIM), but the protocols remain weak. There's a much broader problem of metadata leakage. Deriving from this: 7. Reputation. Much of the spam problem derives from poor tools and support for establishing, assessing, sharing, and acting on the reputation of specific senders -- whether individual originators, email hosts, domains, or IP ranges. Changes to how the Internet is being used, including very large aggregated email providers (e.g., Google, Microsoft, Yahoo, AOL), and point-of-origin masking systems such as Tor make formerly useful concepts of IP and domain-based reptuations of limited reliability. And a consequence is that the assurance of getting messages through to any one person are becoming quite low. The more users are added to a system, the higher the noise level. Email was designed for a friendly, unencrypted, lightly used system of mostly known and fairly trusted users numbering in the thousands. It's scaled remarkably well, by roughly six orders of magnitude. But it's become exceptionally creaky.
- digi_owl 10y ago
  I do wonder if we could get XMPP to adopt store-and-forward messaging...
  - dredmorbius 10y ago
    How do you mean on that?
- kijin 10y ago
  I think you're trying to have your cake and eat it too. Wouldn't a global directory of email addresses be the antithesis of privacy? The greatest difference between email and all of today's proprietary alternatives is that your email identity doesn't need to be vetted by any central authority. Of course this makes spam harder to deal with, but it's part of the cost of decentralization and one that we must learn to deal with. Fortunately, most of the email services I use are pretty good at filtering spam, as well as making sure that my emails don't get marked as spam by other email services.
  - dredmorbius 10y ago
    My inclusion of directory as a downside of email was a poor choice on my part -- I occasionally get swept up in writing something, and the thought's been kicking around my head for a few days that email is NOT based on a global directory, but a directory of directories, possibly hierarchical. This means that if you want to get something somewhere, as with routing and DNS, you kick it off first in the right general direction -- someone who knows more about such things than you do, at a minimum. So, you're right, the fact that email doesn't have a global directory is a feature. It's a feature that's underappreciated by a great many folks who've suggested alternatives to email that do rely on grand central unified directories. Which suggests that an email alternative which has a similar directory-of-directories concept might stand a better chance. I've been thinking along lines of clustered hierarchies of users, with various trust bases within them. If you wanted clusters of no more than about 50 neighbors (well within a Dunbar exhange), then a hierarchy 6 layers deep gets you to coverage of all of Earth's population (15.6 billion individual nodes). Deeper, cross-linked, or other structures could offer greater depth of address use for individuals. I've also been wondering if perhaps national postal systems ought to take over electronic messaging. I can hear the screaming already, but with privacy-supporting protocols (including metadata), much of the risk might be mitigated. In particular, I'm interested in addressing the "who are you?" question -- identity, and re-establishing it, is difficult. I'm thinking that a good reputation system, and perhaps a poll-and-fetch method, rather than a straight delivery, could make email much more resistant to spam. Under poll-and-fetch, a sender would indicate that it has a message for another party. That party would then fetch the message, should it be interested. Fully vetted senders would have their content fetched automatically. Spam senders would have to sit on their spools and wait for (and support) many individual incoming fetch requests. Spammers identified as such would be identified through reputation systems. Granularity of reputation might be at IP space, domain, mail host/peer, or individual sender basis. For many sender/recipient pairs, a strong and clearly positive or negative relation would be established early. The hump is to become known as a trusted sender, for which some sort of trust seed or reputation vouching system might work. I'm still hazy on what might work there.
deckard1 10y ago
> I'll need to find and install one of the x tens of IM clients. Only one? :) It got so bad at my company, that at one time we were having conversations on 3 platforms. And, of course, no one emails anything! Because it's all done on Slack or whatever now. So everyone is 100% out of the loop at all times. I'm up to about 20 Slack channels. I'm constant switching between things to see if I need the information. We have Github integration (and 10 other things) into everything, so it's a constant stream of garbage. And stupid gif animation integration. God forbid you take time off work. Good luck catching up on all that mess. People like to shit on IRC today. But at least I got to choose the client I wanted, and log to an actual file that I could actually grep on. And timestamp on. And organize. And block all the stupid nonsense. First thing on the cutting block would be ignore all Github.
- dfinninger 10y ago
  Man, your Github notifications are mixed into Chat? We have a #{{projcet}}-dev channel for talk and #{{project}}-admin for JIRA/Github/etc. Also, in Slack you can have it auto-close all expansions. You choose the Gifs you wanna see.
  - michaelt 10y ago
    Unfortunately, slack doesn't allow you to block users - not even bots or webhooks. And even if you have expansions turned off, they're still there in collapsed form. So if you're not an administrator, and some genius has set up a bot that posts a cute puppy every time a message includes /pup, and it triggers practically every line in a discussion about puppet, slack doesn't give you the option to do anything. Well, apart from "complain to your boss and ask him to stop your co-workers' fun". As a professional, I don't want to be wasting my boss's time with trivial shit I ought to be able to fix myself.
    - rtpg 10y ago
      I don't get how your pup situation doesn't get solved with a conversation with a co-worker.
meowface 10y ago
It's apples and oranges. Email, phone, IRC/Slack/Lync/Hipchat/Discord. They all have their own purposes. I don't think many companies are trying to replace email; just provide an alternative for times when email would be unnecessary and bulky. I like to think of email as the "ledger" or repository, while your IRC alternative is your working branch.
gaius 10y ago
Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard Answered your own question - no way to make money off it for "disruptors".
- austincheney 10y ago
  Perhaps the "disruption value" is not in media/advertising/content (as in the web) but instead in an enhancement that could erode certain attention from the web. Here is a potential example that will probably never see the light of day http://mailmarkup.org/ http://mailmarkup.org/
cel1ne 10y ago
> There is this weird myth that Email magically kills productivity while Slack and GitHub don't. Yes. I really can't abide chat for work. If I have time and need synchronous communication, I make a phone call. Email forces me to think my communication through, and I can explicitly CC/BCC other people if I feel that they need to read my letter. PS: I find it telling that the product is actually called "Slack". ;)
- douche 10y ago
  I can't abide ad-hoc phone calls, unless somebody is bleeding out or the server rack is bursting into flames. If I'm trying to work on something, hitting me in the back of the head with a claw-hammer would be scarcely more disruptive than an unsolicited phone call.
  - TeMPOraL 10y ago
    I can't abide ad-hoc synchronous communication, not just phone calls. It's the reason I'm almost constantly wearing headphones, whether I'm listening to something or not. I sometimes hear that a cow-orker is talking to me, but I ignore it on purpose, pretending not to notice. Then they usually figure out they need to attract my attention somehow, so they come over / wave their hands / throw an object at me. I respond politely, but with very visible annoyance. This quickly trains them to use IM instead. IM, for which I often have notifications turned off. Avoiding distractions at workplace is a hard work in itself.
    - woah 10y ago
      Sounds like you're a real easy guy to work with.
      - TeMPOraL 10y ago
        I am. I just have one simple rule - respect when somebody is trying to focus to do their job. I give it to all, but I also expect it too.
    - 10y ago
austincheney 10y ago
> Email is an amazing tool. I don't understand the rush to get rid of it. I would say that Email has its strengths, but there are still learned opportunities for improvement. Email is a text based format. I mean this literally as in there is literally no convention to email aside from a couple specified fields in the message header, which often get auto-reproduced into the message body. We can do better on this front to increase accessibility, internationalization, and understandability. There is greater AI potential from email than from the web. Email chains tend to represent conversations with the necessary networking information that both computers and humans similarly understand. This is absolutely missing from HTTP and requires a lot of custom assistance in the formatting of the output to make sense to either computers or humans on the web. Email is less centrally managed than the web. The end points on email are message authors while the server is a glorified application router. On the web though the server is the end point, which is far more primitive.
noufalibrahim 10y ago
Another interesting thing is that email gets through most firewalls into most networks which makes it very easy to send data through.
ms4720 10y ago
So was NNTP
stirner 10y ago
Email is tremendously complex, uses multiple protocols to accomplish different tasks (or even the same task), and is fundamentally vulnerable to spam and can only be patched with further complex hacks like SPF. Almost everyone now uses HTML email, an ill-defined and insecure idea, adding to the complexity of implementations. If you think that email is a good system, trying setting up postfix, dovecot, sendmail, and whatever other hacks are required to make email usable.
- aisofteng 10y ago
  My company provides my email access. As all companies do.
  - stirner 10y ago
    The complexity of email isn't a problem for the average end user who uses someone else's mail server (like me). It's a problem because anyone who wants to interface with email directly takes on the burden of the complexity, meaning fewer and lower-quality implementations of the protocol(s) and less innovation overall.
wodenokoto 10y ago
Email requires all participants to play nice and write their emails with subjects and quotes in a manner that other people and their mail clients can work with, read and understand. However, many clients have different defaults and many people have different preferences. Do I quote above or below? Does the subject line start with RE:, RE:RE:RE:? Maybe my client is setup in a different locale and the reply is prepended with SV: or what have you. Maybe a participant hates RE: and removes them from the subject line, or write the subject line as the main point of the reply. I've never been able to setup a client to show me what is going on on a mailing list or show me nice tree structures that could help me follow the different branching a discussion goes off in. I often get mails in the middle of a discussion and can't trace it back, and read the thread from the beginning. And it is every client for himself and I'm the idiot for not having everything setup nicely and everybody else is smug about it. The nice thing about closed standards is that all clients follow the same rules. When you click reply, you are replying to that message, no matter what you write in your subject line.

by nxc18 10y ago

digi_owl 10y ago

The pups always goes for the new shiny (get off my lawn)...

dredmorbius 10y ago

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-rest, email remains an exceptionally poor choice for private communications, and there's been little real progress on addressing this, in large part because of vendor reluctance at both client and server / system level. E.g., Microsoft, Google, Yahoo, and AOL. 3. Users. Systems which work well with email rely strongly on compliance by users, which relies strongly on enforcement by communications managers or moderators. For LKML, that would be the kernel mailing list etiquette. Battles over header formats, quoting styles, and quote before vs. after exist because these strongly impact workflow and efficiency of groups as a whole. Failure to acculturise hampers the group, and acculturisation rates limit group size and growth. Much of Linus's noted "personality problems" come from the task of having to corral a group of people over which he has little if any formal control, a decidedly limited-bandwidth social communications channel (e.g., no tone, expression, voice, facial gestures, etc. signals), and the necessity TO BE UNAMBIGUOUSLY CLEAR when someone is transgressing norms. (Yes, I'm aware of HN's norms on ALL CAPS.) 4. File formats. Both a blessing and a curse: you can send anything. This means any given group can specify its preferences, but also raises the problem that there are few global preferences given. Kernel development works well with email by having specific tools and formats, from coding style to patch and git tools which create workable code fragments, to conventions for list discussion. This is strongly linked to #3 above. 5. The directory. In thinking about how email compares with other proposed alternatives, one key is that email lacks the concept of a central directory. Or at least, not a formal one (spammers may trade in same). On Twitter, or Facebook, or HN, every individual user is uniquely identified within a global directory. In Email, by contrast, what exist are addresses, which is to say, <user>@<domain>, where the domain has its own sub-directory. But there's no guarantee that domain1 would know that user1 is some valid directory entry at domain2. At best, domain1 knows how to reach domain2, and attempt delivery, via DNS, generally though not necessarily through MX records. This becomes more of a problem with ... 6. Spam and spoofing. Because there's no global directory, the validity of an email from <user2>@<domain2> cannot be assessed. In fact, there's no requirement that that even be a valid address, though as a convention it's generally considerate and useful. There've been numerous hacks to add increasing levels of authentication to email (SPF, DKIM), but the protocols remain weak. There's a much broader problem of metadata leakage. Deriving from this: 7. Reputation. Much of the spam problem derives from poor tools and support for establishing, assessing, sharing, and acting on the reputation of specific senders -- whether individual originators, email hosts, domains, or IP ranges. Changes to how the Internet is being used, including very large aggregated email providers (e.g., Google, Microsoft, Yahoo, AOL), and point-of-origin masking systems such as Tor make formerly useful concepts of IP and domain-based reptuations of limited reliability. And a consequence is that the assurance of getting messages through to any one person are becoming quite low. The more users are added to a system, the higher the noise level. Email was designed for a friendly, unencrypted, lightly used system of mostly known and fairly trusted users numbering in the thousands. It's scaled remarkably well, by roughly six orders of magnitude. But it's become exceptionally creaky.

digi_owl 10y ago
I do wonder if we could get XMPP to adopt store-and-forward messaging...
- dredmorbius 10y ago
  How do you mean on that?
kijin 10y ago
I think you're trying to have your cake and eat it too. Wouldn't a global directory of email addresses be the antithesis of privacy? The greatest difference between email and all of today's proprietary alternatives is that your email identity doesn't need to be vetted by any central authority. Of course this makes spam harder to deal with, but it's part of the cost of decentralization and one that we must learn to deal with. Fortunately, most of the email services I use are pretty good at filtering spam, as well as making sure that my emails don't get marked as spam by other email services.
- dredmorbius 10y ago
  My inclusion of directory as a downside of email was a poor choice on my part -- I occasionally get swept up in writing something, and the thought's been kicking around my head for a few days that email is NOT based on a global directory, but a directory of directories, possibly hierarchical. This means that if you want to get something somewhere, as with routing and DNS, you kick it off first in the right general direction -- someone who knows more about such things than you do, at a minimum. So, you're right, the fact that email doesn't have a global directory is a feature. It's a feature that's underappreciated by a great many folks who've suggested alternatives to email that do rely on grand central unified directories. Which suggests that an email alternative which has a similar directory-of-directories concept might stand a better chance. I've been thinking along lines of clustered hierarchies of users, with various trust bases within them. If you wanted clusters of no more than about 50 neighbors (well within a Dunbar exhange), then a hierarchy 6 layers deep gets you to coverage of all of Earth's population (15.6 billion individual nodes). Deeper, cross-linked, or other structures could offer greater depth of address use for individuals. I've also been wondering if perhaps national postal systems ought to take over electronic messaging. I can hear the screaming already, but with privacy-supporting protocols (including metadata), much of the risk might be mitigated. In particular, I'm interested in addressing the "who are you?" question -- identity, and re-establishing it, is difficult. I'm thinking that a good reputation system, and perhaps a poll-and-fetch method, rather than a straight delivery, could make email much more resistant to spam. Under poll-and-fetch, a sender would indicate that it has a message for another party. That party would then fetch the message, should it be interested. Fully vetted senders would have their content fetched automatically. Spam senders would have to sit on their spools and wait for (and support) many individual incoming fetch requests. Spammers identified as such would be identified through reputation systems. Granularity of reputation might be at IP space, domain, mail host/peer, or individual sender basis. For many sender/recipient pairs, a strong and clearly positive or negative relation would be established early. The hump is to become known as a trusted sender, for which some sort of trust seed or reputation vouching system might work. I'm still hazy on what might work there.

deckard1 10y ago

> I'll need to find and install one of the x tens of IM clients. Only one? :) It got so bad at my company, that at one time we were having conversations on 3 platforms. And, of course, no one emails anything! Because it's all done on Slack or whatever now. So everyone is 100% out of the loop at all times. I'm up to about 20 Slack channels. I'm constant switching between things to see if I need the information. We have Github integration (and 10 other things) into everything, so it's a constant stream of garbage. And stupid gif animation integration. God forbid you take time off work. Good luck catching up on all that mess. People like to shit on IRC today. But at least I got to choose the client I wanted, and log to an actual file that I could actually grep on. And timestamp on. And organize. And block all the stupid nonsense. First thing on the cutting block would be ignore all Github.

dfinninger 10y ago
Man, your Github notifications are mixed into Chat? We have a #{{projcet}}-dev channel for talk and #{{project}}-admin for JIRA/Github/etc. Also, in Slack you can have it auto-close all expansions. You choose the Gifs you wanna see.
- michaelt 10y ago
  Unfortunately, slack doesn't allow you to block users - not even bots or webhooks. And even if you have expansions turned off, they're still there in collapsed form. So if you're not an administrator, and some genius has set up a bot that posts a cute puppy every time a message includes /pup, and it triggers practically every line in a discussion about puppet, slack doesn't give you the option to do anything. Well, apart from "complain to your boss and ask him to stop your co-workers' fun". As a professional, I don't want to be wasting my boss's time with trivial shit I ought to be able to fix myself.
  - rtpg 10y ago
    I don't get how your pup situation doesn't get solved with a conversation with a co-worker.

meowface 10y ago

It's apples and oranges. Email, phone, IRC/Slack/Lync/Hipchat/Discord. They all have their own purposes. I don't think many companies are trying to replace email; just provide an alternative for times when email would be unnecessary and bulky. I like to think of email as the "ledger" or repository, while your IRC alternative is your working branch.

gaius 10y ago

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard Answered your own question - no way to make money off it for "disruptors".

austincheney 10y ago
Perhaps the "disruption value" is not in media/advertising/content (as in the web) but instead in an enhancement that could erode certain attention from the web. Here is a potential example that will probably never see the light of day http://mailmarkup.org/ http://mailmarkup.org/

cel1ne 10y ago

> There is this weird myth that Email magically kills productivity while Slack and GitHub don't. Yes. I really can't abide chat for work. If I have time and need synchronous communication, I make a phone call. Email forces me to think my communication through, and I can explicitly CC/BCC other people if I feel that they need to read my letter. PS: I find it telling that the product is actually called "Slack". ;)

douche 10y ago
I can't abide ad-hoc phone calls, unless somebody is bleeding out or the server rack is bursting into flames. If I'm trying to work on something, hitting me in the back of the head with a claw-hammer would be scarcely more disruptive than an unsolicited phone call.
- TeMPOraL 10y ago
  I can't abide ad-hoc synchronous communication, not just phone calls. It's the reason I'm almost constantly wearing headphones, whether I'm listening to something or not. I sometimes hear that a cow-orker is talking to me, but I ignore it on purpose, pretending not to notice. Then they usually figure out they need to attract my attention somehow, so they come over / wave their hands / throw an object at me. I respond politely, but with very visible annoyance. This quickly trains them to use IM instead. IM, for which I often have notifications turned off. Avoiding distractions at workplace is a hard work in itself.
  - woah 10y ago
    Sounds like you're a real easy guy to work with.
    - TeMPOraL 10y ago
      I am. I just have one simple rule - respect when somebody is trying to focus to do their job. I give it to all, but I also expect it too.
  - 10y ago

austincheney 10y ago

> Email is an amazing tool. I don't understand the rush to get rid of it. I would say that Email has its strengths, but there are still learned opportunities for improvement. Email is a text based format. I mean this literally as in there is literally no convention to email aside from a couple specified fields in the message header, which often get auto-reproduced into the message body. We can do better on this front to increase accessibility, internationalization, and understandability. There is greater AI potential from email than from the web. Email chains tend to represent conversations with the necessary networking information that both computers and humans similarly understand. This is absolutely missing from HTTP and requires a lot of custom assistance in the formatting of the output to make sense to either computers or humans on the web. Email is less centrally managed than the web. The end points on email are message authors while the server is a glorified application router. On the web though the server is the end point, which is far more primitive.

noufalibrahim 10y ago

Another interesting thing is that email gets through most firewalls into most networks which makes it very easy to send data through.

ms4720 10y ago

So was NNTP

stirner 10y ago

Email is tremendously complex, uses multiple protocols to accomplish different tasks (or even the same task), and is fundamentally vulnerable to spam and can only be patched with further complex hacks like SPF. Almost everyone now uses HTML email, an ill-defined and insecure idea, adding to the complexity of implementations. If you think that email is a good system, trying setting up postfix, dovecot, sendmail, and whatever other hacks are required to make email usable.

aisofteng 10y ago
My company provides my email access. As all companies do.
- stirner 10y ago
  The complexity of email isn't a problem for the average end user who uses someone else's mail server (like me). It's a problem because anyone who wants to interface with email directly takes on the burden of the complexity, meaning fewer and lower-quality implementations of the protocol(s) and less innovation overall.

wodenokoto 10y ago

Email requires all participants to play nice and write their emails with subjects and quotes in a manner that other people and their mail clients can work with, read and understand. However, many clients have different defaults and many people have different preferences. Do I quote above or below? Does the subject line start with RE:, RE:RE:RE:? Maybe my client is setup in a different locale and the reply is prepended with SV: or what have you. Maybe a participant hates RE: and removes them from the subject line, or write the subject line as the main point of the reply. I've never been able to setup a client to show me what is going on on a mailing list or show me nice tree structures that could help me follow the different branching a discussion goes off in. I often get mails in the middle of a discussion and can't trace it back, and read the thread from the beginning. And it is every client for himself and I'm the idiot for not having everything setup nicely and everybody else is smug about it. The nice thing about closed standards is that all clients follow the same rules. When you click reply, you are replying to that message, no matter what you write in your subject line.