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.

Now it's more of a huge resort super island filled with lots of other people where everyone perpetually rents everything.

Too cynical?

No, too romantic. E-mail was never good enough to be decentralized, much less at the "every man" level.

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.

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.

You might even be able to do it with some custom user-side CSS.

I have been and continue to be "that guy" who says "this is interfering with work, let's fix it", instead of that guy who doesn't say anything and instead just complains anonymously on social media. It works better this way.

There are private networks with hundreds of active users.

When a customer adds one member of my team to Slack and the flow of information is insane I charge the customer for a manager to follow the loop and leave developers focused.

Answered your own question - no way to make money off it for "disruptors".

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". ;)

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.

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.

The shared office concept was a mistake inspired by assembly lines. Sharing space with coworkers is good in factories because work is often dull and workers can talk to each other. For creative work, it's nothing but a hindrance.

My knowledge about this comes from a befriended work-psychologist who worked with both, offices and factories, since the 70ies.

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.

I like to think of email as the "ledger" or repository, while your IRC alternative is your working branch.

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.

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.

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.

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.

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.

Mind that that cost can be met by some spammers, as it's effectively how a number of present online systems work. But in general, spammers tend to be taken down, and you remove the fire, cram, and forget mechanism of mail blasters, or the sparse, wide botnet model, where a given node emits only a relatively small number of messages.

Adding reputation to the mix strikes me as the secret sauce though.

I'd really like to see a further exploration of the concept. djb's essay is still only a very rough outline.

If you're actually reading email off LKML, that's another story.

But seriously: mutt, pine, Emacs mail mode, or even graphical clients such as Evolution or Kmail, will work just fine. And can be used in conjunction with nontechnical (there's another phrase I'm avoiding using here) GUI mainstream email clients used for other tasks.

If you can't figure out how to install and use mail / mailx / mutt with git, you probably shouldn't be submitting kernel patches. Which in this case is a useful filter.

[ed: never mind, my assumption was wrong:

https://news.ycombinator.com/item?id=12620790 ]

git-am and git-send-email are used by some people. Submitting patches using those tools is just a matter of setting up the necessary parameters (email server and authentication information). But you can use any email client to participate in discussions about a patch series regardless of whether or not it mangles text (since review comments or further discussion obviously do not need to be applied to one's local copy of the code).

If you want to reach a team, email [email protected]. When you join a team, email [email protected], or maybe your hr/sysadm will add you to [email protected]. If you want to reach [email protected] - if you're part of the same company, your client does an ldap lookup. Or you have a look at https://example.com/employees.html or contact.html.

It might at times be difficult to find a random person's email - if you know nothing other than the name - but it's generally very easy to find a contact email for a Dev/security team for a project or company?

I have ... well, not quite nothing, but little against the concept of email lists. They're useful. I've used them extensively. They don't, of and by themselves, address numerous other problems with email. And they can and do insert a few of their own.

Regards lists and directories, I'm not entirely sure what your argument is, but I can interpret your comment at least two ways:

First, an email list is a directory. Yes, it is. It is not, however, a global one. In the right contexts, a list can address the question of discoverability, but that's somewhat secondary. There's the question of what mail is or isn't allowed on-list (e.g., is it open to all senders, or subscribers only?). Service lists -- the effective utilisation of addresses such as postmaster@ or webmaster@ -- typically have to be fairly widely open. This creates some well-known issues, mostly having to do with spam, but also of privacy and organisational confusion over who should or shouldn't be receiving such messages, or how they ought respond. For many corporate distributions, the names of such lists are not generally advertised outside an organisation, though likely targets include "all@", "sales@", "engineering@", etc. Again, this can be useful or not.

The other point you seem to be making is that an organisation can automatically manage its own lists through directory systems. Again, this is addressing the concept of a directory of directories, and any one of the (sub)directories might choose to expose or conceal elements to specific entities. Nothing in any of this is required or constrained by what I've written above.

More generally, you seem to be addressing the question of discoverability, which is a general one. The idea that organisations with their own individual entities might have or conceal means of reaching or contacting people is an old one. I'd call it the introductions problem.

An anecdote from personal experience. At various times, I've had an interest in contacting specific people at organisations. Two come to mind -- an IBM director over a matter somewhat concerning the company, and an issue involving spam transiting a Microsoft-run service. My general biases are that I'm favourably inclined toward IBM, and unfavourably toward Microsoft.

In each case, I found a general switchboard phone number and called, asking for the individual by name.

In the case of Microsoft, the operator said "just a moment", connected me through, the director picked up on the first ring, we had a brief conversation where I described the problem (about five minutes or less), he said he'd get me in touch with the person I needed to talk to, took my number, and within fifteen minutes I was talking to the manager in charge of the unit. We worked on the issue (I had better information than him) for a few months whilst they resolved it, quite measurably.

In the case of IBM, I was connected to an administrative assistant who said, and I think I'm quoting directly, "You can't talk to him, he's a director".

I'm struck by the difference to this day. Much as I don't care for Microsoft, my impression is that they know how to run a business and to transmit information. On the other hand, IBM may have its reasons for sheltering its upper-level management. I suspect otherwise.

If we're assuming pervasive use of mobile devices, with no fixed static IP addresses, and quite possibly dynamic IPs even for stationary devices, several of the avenues to establishing reputation, identity, and routing get difficult.

If the idea is to offer a very large number, rather than a small number, of messaging hubs (equivalent to, though offering more services than, an email server), then issues of reputation, configuration, and administration come into play. You want something that's simple, bulletproof (not in the spam-friendly sense), robust, and useful.

Many erstwhile email replacements are premised on a single global directory. I don't think this can work, nor is it on the whole desireable, though it's certainly simpler to get started.

For point-to-point messaging, especially if we're including realtime protocols (chat and voice/video, not just text/files), you need a system in which either scheduled contacts can be made, or in which at least certain trusted/whitelisted parties can reach a given device, regardless of location, within seconds, or at the outside, a few minutes, so long as both parties are online.

Avoiding central peering and routing structures should be part of the system, for privacy and resilience reasons.

Addressing a few of the other issues I mentioned above, including standards for comms and the like, should also be supportable.

1. Clients (and some servers) mangle email. This isn't a complaint about email; it's a complaint about bad software in general. It's also not my problem; I don't use such clients or servers and it's up people who use them to work around these flaws.

2. Privacy. Real privacy is achievable via email with PGP; everything else is no different than literally any other form of communication. Privacy will always be between Alice and Bob. The transport layer is just a transport layer. With email, those who want it know where to get it. Sure, it's not simple, but if it were simple it would not work. With other solutions, it's frequently not even almost an option. I don't get to audit Whatsapp's server logs; who knows what agencies have access.

3. Users. All systems of communication rely on compliance by users. Just about none of your thoughts on this topic are specific to email. There is no 'go fmt' for human expression, and whenever someone tries, human expression is no longer present. Always speak to your audience, even in an email. It's up to you to decide if a given audience is important enough to acculturate to their norms.

4. File formats. You can send anything -- thank god.

5. The directory. This has no place in the layer. It's like complaining that they didn't build the concept of a web sitemap into TCP/IP. Twitter, Facebook, and HN are one-to-many communications platforms, some of which have hacky ex-post-facto one-to-one mechanisms. Email has been n-to-n from day one. Pretending that it is universally desirable to map addresses to individuals and vice versa is incredibly naive. I not only have several email addresses for different roles, but I have several phone numbers and several postal addresses for different roles. On twitter, facebook, and HN, I would have to jump through hoops to achieve this, and on some services it's even against the TOS. This lack of outside force regarding how I handle email messages is its greatest strength -- I can trivially set up a mailing list, which is nigh impossible on, for instance, twitter, and utterly impossible on hacker news.

6. Spam and spoofing. Absolutely a problem. Will remain a problem until solutions get specific buy-in from multiple interested parties -- and that last part makes all the difference. Each time some SV megacorp institutes a real-name policy, or a captcha, or or or... another class of users is sidelined, disenfranchised, or otherwise excluded from the communications process. Email does not have that, because there are standards to adhere to, and some random project manager does not (quite yet) have the power to shove new standards down our throats. Thank God.

7. Reputation. This is now and will continue to be the universal problem across all of the internet. Solving this problem by trusting a third party service provider to do all of your vetting for you will fail, because all they do is push that problem downhill to the users. Joe Random wants to be friends on Facebook. Now I have to do casework to decide if I want Joe to access my inbox, and if Joe is even Joe. Susan User would like to add me to her professional network on LinkedIn. Same problem. The only difference is that when I run an email server I maintain agency to manage the entire scope of these decisions, instead of trusting that Facebook or LinkedIn is reasonably sure that Joe might actually be Joe, or that Susan is not in fact a ten-year-old Martian girl mining my profile for password recovery answers.

Is email perfect? No, of course not. But it and IRC are the closest things we have to level playing fields for someone willing to do the work to take their place as a first-class citizen of the internet. They will only ever be replaced by standards; no proprietary product will ever unseat them.

Mail clients written in the eighties can still work today. Mail stores created then are still readable by today's clients. The protocols and processes involved have definitely changed, but they've _evolved_, rather than getting thrown in the trash and replaced with version 2.0, then 3.0, etc, ad infinitum, ad nauseam.

Given the choice between an evolving collaboration and reliance upon the goodwill of some stranger I can't even name, my choice will always be the former.

I disagree with some of your points, but also want to note that what I gave as email's weaknesses are frequently also strengths. I'll try to clarify the distinction.

1. Clients: There are cases in which functions which ought be standardised aren't. These are particularly problematic where archives of email from multiple systems are presented. References, quoting, and reply styles are three long-standing friction points. Various conventions for noting changes in documents -- GUI client users relying on word colour won't play well with those using text-oriented platforms. Including now a great many mobile email clients, not just mutt and pine users.

Standardisation is what makes more complex interactions possible, whether you're talking messaging formats, file formats, or nuts and bolts sizing. This makes for an interesting though likely side conversation. My point is that the lack of agreement across major families of email clients makes more complex email interactions quite painful, something I've noted for decades.

The biggest problem I'm seeing is that client tool vendors simply aren't addressing numerous areas of concern, such as those I've listed here, or working in the least toward interoperability. This is for quite understandable reasons (gaming and abusing standards for selfish gain is an old trick), but it doesn't make the resulting situation any more desirable.

2. PGP/GPG doesn't address metadata privacy at all. It's not supported by many clients (see above), and has posed very long-standing issues by way of key management and web-of-trust issues. Moxie Marlinspike is among the voices suggesting PGP may have to be swapped for something else. I'm not sure I agree with his assessment, but his isn't a voice to be trifled with.

Without encryption at the transport layer, and on a guaranteed basis, privacy protections simply don't exist. The level of concentration of email services leads to other massive concerns. Much of that is due to a lack of sufficient trust mechanisms built in at the peering level, so one problem (spam + trust) feeds another (privacy).

3. The issues of user idiosyncracies is amplified by other factors, including the client issues above. Tools to standardise formats, or convert to/from various standards, might help. My primary issue is that problems in one area of the messaging world amplify those in others. It's a mess, and neither users nor tools are helping much.

I'm aware that people aren't robots. Not all of them, at least. Providing tools that make it harder to do the wrong thing would help considerably. That's not what we have now.

4. File formats: again, it's a matter of standards. Negotiation of what is/isn't permitted, and/or required, on a given conversation, for example, might go a long ways to addressing this.

More generally, email as with the Web operates as an error condition: http://deirdre.net/programming-sucks-why-i-quit/

5. The directory. Addressed elsewhere. More a characteristic / non-characteristic of email as a whole, though one many proposed replacements get on the wrong side of (trying to provide a total global directory).

6. Ties in to clients, security, authentication, privacy, and a mess of other factors. It's a problem, but it's a problem grounded in virtually every other part of the email system.

7. Reputation: see above. Though I agree that it's not something that can be addressed through a central agency. Another much longer discussion.

Again: the point in my list is to note where email fails most egregiously. I like email. I've used it for thirty years. I've defended it, strongly, against numerous previous criticisms. But I've come to change my mind, in that several of the fundamental premises and capabilities of it are now fatally flawed. It needs a massive refresh.

(I'm also a fan of IRC.)