[email is] nowhere near as difficult to use as people make it out to be…
My wife teaches high school. For the most part, many kids there don’t know how to use email, even just to send a message. Some don’t even know what email is. It they do use it, they put the entire message in the subject line. They are confused by the mail client on iOS. They are used to instant messaging. The notion of longer, quoted, asynchronous messaging is not something they grasp.
I’m approaching 50 years old and most of my friends no longer use email to stay in touch, despite my best efforts to get them to use it (since I like it and prefer it). These friends are all tech-savvy and are in my age group.
Email is a dying medium. Part of this is because mailing lists are so terrible. This is, in fact, why so many people I know don’t use it: they find it inferior for group chats compared to things like Facebook and Discourse. I have a core group of friends that only uses email because I do. Otherwise, they would avoid it. Their reluctance to use it can be directly attributed to the attitude exhibited in the article: that plain text and a terminal are the pinnacle of human computer interaction and therefore, does not require any improvement.
My wife teaches high school. For the most part, many kids there don’t know how to use email, even just to send a message. Some don’t even know what email is. It they do use it, they put the entire message in the subject line. They are confused by the mail client on iOS. They are used to instant messaging. The notion of longer, quoted, asynchronous messaging is not something they grasp.
Sadly for a lot of people, email is just something they use to get password reset and account activation emails that are basically little webpages addressed to them.
The thing is, people understand what they’re taught and introduced to. Introduce kids to email and they understand email. You can’t just put someone in front of something unfamiliar and then expect them to understand it immediately with no instruction. If you’ve only ever used Facebook Messenger then of course Email is going to seem odd. In the same way, my aunt has used email but when she tries to use Messenger she uses it like email (or snail mail): long messages starting with ‘Dear X,’ and ending with ‘See you soon, Y’. That’s just as ridiculous as putting the whole message in an email’s subject.
Email is a dying medium. Part of this is because mailing lists are so terrible. This is, in fact, why so many people I know don’t use it: they find it inferior for group chats compared to things like Facebook and Discourse. I have a core group of friends that only uses email because I do. Otherwise, they would avoid it. Their reluctance to use it can be directly attributed to the attitude exhibited in the article: that plain text and a terminal are the pinnacle of human computer interaction and therefore, does not require any improvement.
Well, it is inferior for group chats compared to things like Facebook. It’s not an instant messenger and trying to use it like one leads to stuff like “they put the entire message in the subject line”.
Discourse is a forum, right? I think forums and mailing lists serve different purposes and forums are generally superior for general meandering discussion while mailing lists are much better for focused topic-specific discussion, especially when it’s discussion about specific topics within a larger subject and you want to do things like transition freely between private small-group discussions on a topic and list-wide discussions. But mailing lists fail when they become forums, because general discussion forums and threads are a horrific combination (as you can see from reddit, HN, lobsters, etc., which only work well for news aggregation, while using reddit self threads as discussion forums is abysmal).
But email is much better than instant messengers or forums for stuff like sending family photos or organising something long-term (like an overseas trip) with family members, IMO. The ease of attaching tickets and photos and stuff like that is just unparalleled. And it’s definitely far superior for discussing patches for free software projects. How that’d work on a forum or instant messenger is beyond me.
If they do use it, they put the entire message in the subject line. They are confused by the mail client on iOS. They are used to instant messaging. The notion of longer, quoted, asynchronous messaging is not something they grasp.
Does this strike you as symptomatic of a problem? It does me; I think that developing the capacity to consider someone else’s thoughts, reflect and respond is pretty key.
Their reluctance to use it can be directly attributed to the attitude exhibited in the article: that plain text and a terminal are the pinnacle of human computer interaction and therefore, does not require any improvement.
Terminals could probably use some improvement, but written communication is more advanced than spoken, which is in turn more advanced than pointing and grunting. A mouse or touchscreen enables and extraordinarily primitive form of communication: pointing at things and ‘grunting’ at them.
With a keyboard, OTOH, one is capable of communicating every rational thought. Which is pretty remarkable.
I have some “pen palls” that I have discussions with over email, generally exchanging longer “letters” every few weeks or something like that. I like instant message and groups chats too, but it’s not quite the same. These are all tech people.
I’m really sure if there’s a good alternative for this kind of thing; I think there’s some space for future innovation here which preserves some of the good properties of email but avoids the various problems people experience.
SLOWLY is an interesting app here, although it just allows talking to strangers (and it’s mobile-only, which I don’t really like to type long letters on).
I’m not sure if I’ve yet seen a good e-mail client. Thunderbird is what I’m using right now, but it kind of sucks. All the webmail clients are ridiculously heavy, confusing, and have long loading times. Maybe Outlook is good.
Everyone, and every e-mail client, has a different idea of how e-mail works. Does the quoted text go at the bottom or the top? Is text hard or soft wrapped? If hard wrapped, is it wrapped at 80 or 72 columns? You end up with person A sending something with hard wrapping set to 80 columns, then person B quotes parts of that with 72 column hard wrapping, and you get alternating 72 and 8 column lines.
E-mail is a terrible medium for sending code. Most programmer types insist on hard wrapping, but e-mail clients configured to hard wrapping will break code by inserting newlines. Most people recommend hard wrapping at 72 lines; most code is wrapped at around 80-100 lines if at all.
E-mail is barely decentralized. Good luck hosting your own e-mail server without being overrun by spam and without being marked as spam by the big providers. Pray you don’t ever get your IP address globally blacklisted; pray your IP address has never been used for mail spam in the past.
An e-mail client is about as hard to implement as a web browser, since an e-mail client needs to parse and display HTML and CSS like a browser would (or at least like Outlook would).
E-mail discussion chains inevitably end up with a messy mix of hard wrapping at 80, hard wrapping at 72, HTML, plaintext, quoted text above the message, quoted text at the bottom of the message, and messages using symbols from proprietary Microsoft fonts.
Everyone, and every e-mail client, has a different idea of how e-mail works. Does the quoted text go at the bottom or the top? Is text hard or soft wrapped? If hard wrapped, is it wrapped at 80 or 72 columns? You end up with person A sending something with hard wrapping set to 80 columns, then person B quotes parts of that with 72 column hard wrapping, and you get alternating 72 and 8 column lines.
There’s format=flowed for that now. Mailing list etiquette ended up against top-posting, which means quoted text shouldn’t to go the bottom.
E-mail is a terrible medium for sending code. Most programmer types insist on hard wrapping, but e-mail clients configured to hard wrapping will break code by inserting newlines. Most people recommend hard wrapping at 72 lines; most code is wrapped at around 80-100 lines if at all.
You should use git send-email, not pasting git format-patch output into your mail client.
An e-mail client is about as hard to implement as a web browser, since an e-mail client needs to parse and display HTML and CSS like a browser would (or at least like Outlook would).
Email shouldn’t have gotten HTML support in the first place, thank Microsoft for that. Also, almost all HTML email is sent for advertisement. How often do you see an email from a person that actually needs HTML? I haven’t seen one yet.
Ah, that famously super well-supported feature which every e-mail client can use.
Mailing list etiquette ended up against top-posting, which means quoted text shouldn’t to go the bottom.
I don’t think I’ve used many e-mail clients which don’t default to putting quoted text at the bottom. When “mailing list etiquette” goes against most mainstream e-mail clients’ defaults, you guarantee that at least a large portion of the users won’t follow “mailing list etiquette”.
You should use git send-email, not pasting git format-patch output into your mail client.
Ah, so I can’t even use my preferred e-mail client to send patches.
Email shouldn’t have gotten HTML support in the first place, thank Microsoft for that.
Well, it’s here now. “E-mail sucks because Microsoft” isn’t a counter-argument to “e-mail sucks”.
Also, almost all HTML email is sent for advertisement.
Nope, I receive lots of HTML e-mail which isn’t advertisements.
How often do you see an email from a person that actually needs HTML?
Not many? Still, when I receive HTML e-mail, my client needs to support HTML.
Ah, that famously super well-supported feature which every e-mail client can use.
I don’t think I’ve used many e-mail clients which don’t default to putting quoted text at the bottom. When “mailing list etiquette” goes against most mainstream e-mail clients’ defaults, you guarantee that at least a large portion of the users won’t follow “mailing list etiquette”.
Ah, so I can’t even use my preferred e-mail client to send patches.
If your client can’t support basic features use a different one.
And of course you can use your preferred email client to send patches, as long as it’s able to be configured to send patches properly. git send-email is just much more reliable than arbitrary shitty client number 72.
Well, it’s here now. “E-mail sucks because Microsoft” isn’t a counter-argument to “e-mail sucks”.
Email with people that use shit Microsoft products is, like most interactions with those people, pretty crap. It doesn’t matter what communication method you use with Microsoft-using people, you’re still going to get proprietary formats of one kind or another. At least with Email there’s a nice smooth transition path away from Microsoft crap towards much more functional alternatives.
Nope, I receive lots of HTML e-mail which isn’t advertisements.
All HTML email I receive is in one of three categories:
Actual spam spam
“Spam” in the form of email advertisements from websites I’ve signed up to at one point or another, so not unsolicited but not really wanted
People using HTML email because their client defaults to it or because they want an image in their signature, where the email could easily have been in plain text with no loss of functionality
Is there a different kind of HTML email you receive? I’m interested to hear this because everyone I’ve spoken to is in the same situation I’m in with HTML email.
Not many? Still, when I receive HTML e-mail, my client needs to support HTML.
Your browser supports HTML. Why can’t your client just open the HTML email in a browser window? It could even be a browser window embedded in the client window if that’s your preference.
Email with people that use shit Microsoft products is, like most interactions with those people, pretty crap.
This sounds quite harsh to me. I don’t use windows or ms office or anything at home, but I have to useit all at work. Some purpl people don’t have a lot of choice.
Regular folks will typically buy a laptop with Windows and stiff pre-installed. How many consumer-laptops with lowprice with Linux pre-installed are there? Some people don’t have a choice in this as well.
My patience has slowly run out with people that choose to stick their head in the sand and ignore the bajillions of reasons that Windows is a harmful platform designed by harmful people to harm. It’s spyware, it’s anti-standards, it’s buggy, it’s just crapware. I don’t mean to be inflammatory, I’m just sick of it. I’ve spent enough time trying to explain the issues with Microsoft products to various family members over the years. They just don’t care about privacy. They don’t care about supporting an American defence contractor. They just don’t care. They’ll complain about the decline of local bookstores and use Amazon. They’ll complain about their local butchers and grocers closing while spending most of their disposable income at the supermarket. They’ll complain about the quality of their computer and about how much they hate computers and computing, all of it Microsoft-specific annoyances and bad UI, and they’ll just keep on giving money to Microsoft. “Regular folks” can deal with their privacy issues and crap spyware software themselves. People choose to be ignorant, to not explore alternatives, to not learn anything new or unfamiliar. I’ve had enough.
(The above link is just a random email I found when trying to see if navigating some mailing list arcives was as unintuitive as I remembered it to be. Conclusion: it is.)
It has readability issues sometimes for some HTML emails, but for personal communication I’ve found it to be a joy to work with. I’ve used it daily for nearly a year.
I really want aerc to replace mutt for me, but it’s missing some crucial features: pgp mail encrypt/decrypt and signing support, and email threads. I learned enough golang when aerc was first started to contribute a tiny number of patches, but implementing these things are beyond what I have time/patience for at the moment. I hope one day I can drop mutt for good, and use aerc full-time.
This is the actual killer feature of email for programming projects. A good client with threads and a mailing list is better than most web-based forums.
An additional problem is that you never know if someone is going to read your email in monospace or proportional fonts. If it’s the latter, then there’s no real way to send tabular data for example, or otherwise aligned text. Other than HTML of course, but some people are rabidly opposed to that as well, so you never know if that works for them, either 🤷♂️
Also, when you use email lists are the primary way to get in touch for bug reports an the like, you’re actually adding quite a barrier IMO. You often need to be subscribed and you’re spammed with emails you don’t care about. Even if you don’t need to subscribe, you may get CC’d for a long time and get emails you may not care at all about.
you never know if someone is going to read your email in monospace or proportional fonts. If it’s the latter, then there’s no real way to send tabular data for example, or otherwise aligned text. Other than HTML of course, but some people are rabidly opposed to that as well, so you never know if that works for them, either 🤷♂️
You send HTML with the tabular/code/etc. stuff in a <tt> block. (Except the editor will probably instead use an inline CSS style, but same difference.) The luddites will be reading the plain-text alternate body in a monospaced font anyway, so everyone’s happy.
Most non-terminal email clients display the text version as proportional, and there’s almost always an option to prefer the text version over HTML, so some people must be enabling that (perhaps not many, but not 0 either, especially among the tech crowd).
I actually enable it myself in FastMail, mostly so that I have a consistent experience reading text. I just enabled and went through some of my recent email conversations, and for some reason loads of email clients set weird fonts, colours, line-heights, and that kind of stuff on their outgoing emails. I don’t really mind HTML email as such but having the entire UI and my email in 14px fonts, and then getting an email with a huge 22px font does not exactly make for a great reading experience.
At least it looks like Outlook stopped sending their emails in fecking blue text by default, so that’s an improvement.
Outlook is awful and doesn’t implement email according to the specs or the way anyone else implements it. It’s just broken. It’s the classic ‘EEE’ strategy of Microsoft.
On quoting, I don’t know if it’s Gmail or Outlook or something else that started ruining it for everyone else by defaulting to this top-posting style but it’s wrong. Bottom-posting and eliding parts of the email you’re not replying to (interspersed quotes with your message) is standard, but to be honest most of the time you really don’t need to quote anything at all. When writing a letter you don’t photocopy or cut up parts of the original letter, paste them to the page and write your responses in between the bits of the original letter. You just reply. You say ‘in relation to X, I think [blah blah]’. I’ve been trying to get out of the habit of quoting posts I’m replying to on threaded forums, it’s really unnecessary when anyone can read the post I’m replying to directly above it. It’s mostly useful when you want to reply to a specific point.
For sending code, there are two options. You can attach code, or you can put the code inline. Inline, code shouldn’t be hard wrapped. It’s not hard to configure a client to not wrap code, and frankly if you can’t configure your client to do this it’s just a bad client and you should find a new one or someone should fix the old one. How many widely used non-webmail email clients are not free software? Outlook is the only one I can think of.
Email is super decentralised. It’s frankly just a myth that it’s hard to set up an email server that won’t get blacklisted or that you get heaps of spam. Spam filtering is really accurate these days.
If you want to look at HTML, use a web browser. Email clients are for reading and dealing with email. Open a web browser window, embed a web browser, whatever.
Stop having email discussion with people still using Outlook in 2020 and 99% of your issues with email disappear.
An e-mail client is about as hard to implement as a web browser, since an e-mail client needs to parse and display HTML and CSS like a browser would (or at least like Outlook would).
This is what eventually drove me to give up and use webmail (helped by fastmail actually having quite a good/fast webui with only a small number of mildly annoying bugs).
I have been using email clients that don’t display HTML at all beyond stripping out tags so it’s readable as plain text, and I haven’t been missing anything. The only HTML-only emails I get are spam. And because HTML is an attachment, if I really need to view it, I can open it in a browser.
The FastMail web UI is one of the few (non-trivial) SPA apps that I actually enjoy using. I think it got a lot of subtle things right that a lot of other SPAs didn’t.
One of the bigger pain points is that it’s almost unusable with email discussions: you get a lot of duplicate messages (including those that you sent) and there’s no threading. It was probably never designed with that use case in mind, so that’s okay. But it does go to show that “you can just use email client” isn’t exactly true: you can use “any email client with specific features to deal with mailing lists”, and a lot of those features seem quite unnecessary outside of mailing lists. I’ve happily used FastMail for 7 years and it works perfect for everything else.
I have a simple solution for this problem: don’t participate in mailing lists, which goes to show that things are perhaps not as easy and accessible and easy as claimed in this article.
I’ve used many different email client over the years: probably all of the mainstream webmail, GUI, and terminal ones; the first part of the mutt tagline is completely accurate IMO, the second part … meh. Again, this seems further evidence to me that email is not as easy as it made out to be here.
FastMail does threading if you enable it in the preferences. I subscribe to multiple mailing lists and use a single UI, fastmail, to read and manage the messages from all of the lists. A single inbox is the reason I prefer email to web forums.
I think you mean the message grouping? It’s nice, but not quite the same as threading shows threads within a conversation, whereas the message grouping just shows everything from old to new. IMO it doesn’t work very well for mailing lists beyond reading.
I’m not sure if I’ve yet seen a good e-mail client
Apple’s mail client (the macOS version, not the horrible iOS one) is pretty decent. It’s about the only Mac app I actually miss on other platforms. It handles a few tens of GBs of messages, searching is fast and works well, it does quoting sensibly, lets you reply to a part of a message the same way lobste.rs does (select the part you want to quote and hit reply), and so on. Thunderbird is just about okay. Both handle sending with multiple email addresses from the same account nicely (iOS mail doesn’t, for example). Thunderbird has slightly better threading support (Apple Mail renders threads as lists, not trees, so can be confusing for threads that split into subdiscussions).
Outlook really struggles with non-HTML mail (it uses a Rich Text control for editing and then strips the formatting, often in surprising ways such as removing the quote bars, Apple Mail uses leading >s for quoted sections but renders them as coloured bars). My favourite Outlook bug arising from this is that, if you set your default to plain text and hit the ‘Make Teams Meeting’ link, it puts rich text with links to join your meeting and then silently strips them when you send so the recipient has no idea what they’re supposed to do to join.
There are a few things that make email really bad. The first is archive storage. I have hundreds of MBs of LLVM mailing list archives. I keep my own copy because that’s the only way of being able to reply to or forward an old post easily. Dovecot avoids this by having a central IMAP folder for their mailing list history that anyone can subscribe to, but configuring that looks sufficiently annoying that I’ve never done it (I don’t want to add a new mail account to every mail client I use just to view it). Most of the time, I find posts on other projects from their web archives, but if I want to add a follow-on question then I have no mechanism to get that post in a form that I can hit reply to. Instead, I have to create a new thread and quote it, which breaks everyone else (and often doesn’t add the original sernders to the cc list correctly because most mailing list archives anonymise the sender addresses to avoid spammers harvesting them).
Email is fine for a project that I’m actively engaged with. It’s far more annoying for projects that I’m casually contributing to. Things like GitHub issues are far better for that. They’re archived by search engines and if I find the issue and have more questions / comments I can hit reply and add them in the same thread.
Running it in the address space of cloud VM providers is a bad idea indeed, but at a normal hoster it should be no problem. Maybe find one that is paid monthly and you can just cancel it.
If you can’t host with a VM provider (because their block is probably banned) and you can’t host on your own (because of residential IP address reuse), won’t hosting be very expensive?
that was not the question. I know people who wouldn’t trust their emails on a VPS/shared host anyway, so I’d say a good portion of people having their own mailserver do it on dedicated hardware anyway.
Also while sometimes whole blocks are banned, often it’s really just single IP addresses on the blacklist. Also maybe the same hoster has a different data center and then maybe a different block. As I said, if this is your concern you might not have success on the first try.
And that’s also the reason I have stayed with my current hoster, upgrading the same VPS contract with the same IP every few years, because I’ve been running my mailserver off of this IP for ~10 years and don’t have any of these problems.
The best discussion platform I’ve ever used was bbcode forums. Easy to extend, easy to organize, easy to search, easy to use. We need a modern take on those.
Forums are great but they’re very different to mailing lists, IMO. (Flat!!) forums are much better for meandering discussions and as a community hub. They’re much better for long-running threads. The osdev forums are a great example: each person can make their own thread for posting updates about their project, there are many threads that have run for years, etc.
But you couldn’t use a phpBB-style forum to discuss patches or something, it just wouldn’t work.
The right tool for the job is a mailing list. Code forges are appallingly bad for discussing patches because none of them make it at all easy to suggest changes in the form of a simple patch.
And there’s then a button to apply the change (or add it to a batch to apply) right there as a new commit in the PR. CI then runs automatically, without needing anyone to check out the code locally.
What is the mailing list workflow that is simpler than this?
Forums are considerably better. The thing is you could just as well us an email client to read and post to forum too. Forums have always been superior at presenting discussions compared to mailing list archives. There is certainly room for improvement (Discourse seems like a decent attempt), but when it comes to organizing and browsing past discussions, I’d take bbforum over Mailman.
Have you ever tried Zulip? The Lean prover community has one and it seems to suit them well (same for rust, these days). I like it a lot, best threading I’ve seen in any kind of messaging system, and it encourages longer form messages with embedded LaTeX and markdown.
Couldn’t disagree more with you. Bbcode forums are some of the worst designed interfaces that have ever existed. There abdundance of completely useless user information:
john is user since 1992-11-11, has 20 144 posts, 44 reputation point, 5 thank yous and half of a screen signature banner of a gif leopard eating a linux penguin
message #1004 last edited by john 2020-06-08 20:14:55 UTC+6 South East Asian Pacific Time.
From Russia, Moscow
Offline
A whole 5 page thread of bbcode forums could fit in a single old.reddit screen.
Fully agree. The convenience and efficiency of email is unmatched. I hate having to use Slack for work. The UI is so sluggish, I get pinged for the silliest of things (because they can!). Email makes people more thoughtful while communicating. You can’t delete a sent mail. And more importantly, email won’t go away. What’s to say Slack won’t “thank you for the incredible journey” when their VC funding stops?
Also agree and hate slack for work - have you tried Ripcord? I switched from the official client and it’s far quicker/calmer! Still won’t fix the expectation slack gives to colleagues sadly…
What’s to say Slack won’t “thank you for the incredible journey” when their VC funding stops?
I hope that is the case. Fortunately, my time using Slack was brief. When you give the users to option to ping people with ease they will, however, due to the nature of email (and email lists) they are normally more precise as they are only done when necessary.
I hate how little control I have over things sent through email. I want to like email, and I was thinking long about why email makes me uncomfortable instead. I think this is maybe my sore point. Things like:
Being able to verify what your message will look like on the receiver end. I use that pretty ‘Preview’ button here on Lobsters all the time. Plain text simplifies a bit, but stuff like git-send-email complicates this again.
Verifying your message was received the way you intended. Recent example was me sending some DNS records to a client’s technical contact. Except their virus scanner botched the records by transforming them like links, wrapping them with some link-scanner URL. Cue 6 extra mails back and forth until we found a working solution. (Ties in with lack of moderation and threading issues.)
Making editorial changes after the message was sent. How many more times do we have to deal with missing attachments already? (Cue 2 extra mails every time.) (Also applies to IRC, btw.)
Tools that take over sending from the regular MUA, like git-send-email, just make me wary. I want to know when something is going out in my name. I want ample confirmation, or at least the flow I’m used to.
And I can’t help but nod at all the other issues mentioned here. Email is kind of terrible.
Being able to verify what your message will look like on the receiver end. I use that pretty ‘Preview’ button here on Lobsters all the time. Plain text simplifies a bit, but stuff like git-send-email complicates this again.
There is a good argument that you shouldn’t worry about this. Not all people are going to look at your email. Some are going to hear it. Some are going to touch it. You should let people to read your email as they want.
Being able to verify what your message will look like on the receiver end. I use that pretty ‘Preview’ button here on Lobsters all the time. Plain text simplifies a bit, but stuff like git-send-email complicates this again.
Preview on lobsters shows what your comment will look like on your screen once you’ve clicked send. But it doesn’t tell you how it’ll look on someone else’s screen, which can be subject to:
Different resolutions
Arbitrary user scripts
Custom fonts
High contrast stylesheets
etc. The argument that these are less common on the web is probably an argument against the web, because people make these customisations for good reason, and being able to scale up fonts and use dyslexic-friendly fonts, etc. is an important accessibility concern.
Verifying your message was received the way you intended. Recent example was me sending some DNS records to a client’s technical contact. Except their virus scanner botched the records by transforming them like links, wrapping them with some link-scanner URL. Cue 6 extra mails back and forth until we found a working solution. (Ties in with lack of moderation and threading issues.)
A pain in the arse for sure, but ISPs and virus scanners have been known to do similar things to web pages too! I remember reading horror stories about ISPs inserting ads into web pages, for example. So it’s not just an email problem.
Making editorial changes after the message was sent. How many more times do we have to deal with missing attachments already? (Cue 2 extra mails every time.) (Also applies to IRC, btw.)
I think this is a good thing. It has tradeoffs, it can be annoying, but I quite like that once I’ve received an email the person sending it can’t go back and edit it later.
IRC you can just do
<mrr> I fuckign hate XML
<mrr> s/fuckign/fucking/
and you can even configure some clients to perform the replacement. :D
Tools that take over sending from the regular MUA, like git-send-email, just make me wary. I want to know when something is going out in my name. I want ample confirmation, or at least the flow I’m used to.
lol it would actually be difficult for me to find a post I disagree with more. The fact that email is an open platform is about the only thing I agree with the author about.
email isn’t that difficult to use
It really is. It’s reasonably easy to use if a thread remains linear, but if it branches at all (someone responds to a message that isn’t the latest one in a thread) it becomes almost impossible to follow.
no moderation tools is a good thing
Ok, this is wrong in two ways, one is that without moderation tools your mailing list becomes a mess and the other is that every mailing list platform I’ve used lets you block people from the list.
plain text is great
It may well be great but let’s face it, we lost the war on HTML email a long long time ago
email is federated
True! If I have a gmail account and you have an outlook account we talk just fine, however running your own mail server is an exercise in pain so that the big mail providers don’t put you on a spamlist
It’s reasonably easy to use if a thread remains linear, but if it branches at all (someone responds to a message that isn’t the latest one in a thread) it becomes almost impossible to follow.
I just responded to a message that isn’t the latest one in the thread. Do you find this difficult to follow?
Ok, this is wrong in two ways, one is that without moderation tools your mailing list becomes a mess and the other is that every mailing list platform I’ve used lets you block people from the list.
In Discord, you can get banned outright, that is you cannot participate in any community discussion. Can this happen in email? No.
It may well be great but let’s face it, we lost the war on HTML email a long long time ago.
What’s the last time you’ve seen an email that needs HTML features written by a human person for you? You don’t need HTML mail.
<marquee>TL;DR: HTML was expected to be mostly plain text.</marquee>
<p>Is this readable to you? It is what HTML email composed by human
<b>could</b> look like if the HTML formatters were working nicely</p>
<p>I doubt many people read HTML pages with curl, but for email it
might happen quite often if using a non-HTML client... Ok image looks
weird, <a href="https://example.org">links</a> are a bit obnoxious...
but HTML also stated simpliciyt as a goal.</p>
<p>That being said, I have <i>never</i> seen any HTML email formatted
with nincely flowed text, and I guess a text alternative part is used
instead of "readable HTML source"</p>
<p>This is not exactly a problem of email itself, but more generally
speaking HTML source</p>
I don’t, because I’m not using email. Reddit/lobsters or traditional forum software is so much easier to navigate
Because you’re used to it, I guess. I really clearly remember opening Reddit and being utterly perplexed as to how it was meant to work. Why were some messages half way across the screen? Why were all the messages over on the left? How could I centre the messages on my screen? How were the messages sorted?
If you have a gmail account, you are creating problems for everyone who doesn’t. GMail is the single biggest offender when it comes to false positives and silent loss of messages coming from independent servers.
It really is. It’s reasonably easy to use if a thread remains linear, but if it branches at all (someone responds to a message that isn’t the latest one in a thread) it becomes almost impossible to follow.
Do you really feel that way? Personally I hate threaded discussions for anything except mailing lists. They’re particularly odious on discussion forums, which is part of why using reddit as a discussion forum sucks so much.
But for discussing patches on a mailing list, for example, having multiple threads of discussions with different people all interlaced in a linear order seems much worse than threading. One person replies with some style suggestions, another with a functionality request and another with a bug. Do you really want those comments and their replies to be interlaced? All that’s going to happen is people are just going to quote the entire thing they’re responding to in the linear thread to emulate true threading. You see this on flat/unthreaded forums all the time.
Ok, this is wrong in two ways, one is that without moderation tools your mailing list becomes a mess and the other is that every mailing list platform I’ve used lets you block people from the list.
I think the point being made here is not about moderation on the mailing list level (which is fine, communities can and should moderate themselves) but on the platform level. If you use Slack or Discord then your use of the entire platform can be moderated away by the people that run those platforms.
About the only way you can moderated off ‘email’ as a platform is if you’re moderated off the entire internet in general. If you’re not literally the Daily Stormer you should be fine.
It may well be great but let’s face it, we lost the war on HTML email a long long time ago
In what way? People use HTML email, people use Discord, people use Facebook. Others using something doesn’t mean you have to use it. When I get HTML email, depending on context, I sometimes explain to people why it’s problematic (accessibility, privacy, etc.). I have emailed service providers asking that they send plain text and HTML email, or at least don’t send a “plain text” mime part that’s just got HTML in it, because it confuses my email client.
People will keep using HTML email. You don’t have to.
True! If I have a gmail account and you have an outlook account we talk just fine, however running your own mail server is an exercise in pain so that the big mail providers don’t put you on a spamlist
It’s honestly not that hard and even if you don’t want to, there are lots of reputable non-Gmail non-Outlook webmail providers like Fastmail etc.
And you can use those providers but not use their webmail client, just throw their IMAP/SMTP details into your email client.
While I agree with all that the author has said about the walled garden-ness of platforms like slack, I do think emails are highly unsuitable for having a proper discussion and conversation.
The neomutt image perfectly demonstrates it, as you can only see the subject line and the names of the responders without being able to scan through all the replies at once to see what’s going on. Most email clients that I know of do not handle discussions like this very well.
A better alternative would be to support the matrix standard that promises federation while giving modern features, rather than wrestling with email to make it work for you.
For the past 20 years there has been countless posts published on the internet saying X is best for Y and it boggles my mind that so many intelligent engineers didn’t yet conclusively conclude that such binary statements are useless. Because the only true comment here is “it depends”.
I’ve seen fantastic discussions on a classic forum system. I’ve seen brilliant discussions in an xmpp group chat. I had some of my best discussions through ICQ, Facebook comments, WhatsApp, Viber, Twitter. I had very efficient discussions via email as well.
And all of them require supporting all of the platforms up front.
I wish everyone coming up with a new protocol to take a deep thought on whether it could not have been done with the existing ones out there before to deploying it for everyone:
Could matrix not pick IRC or Signal protocol for client-server instead of yet-another-one?
Can the mumble wire protocol be upgraded to include the double ratchet so that other chat system use it?
Is SIP impossible to get running in a simple and secure (SRTP + ZRTP) way instead of “reinventing the wheel” by plugging a voice system to a chat app?
For instance, Jitsi uses XMPP (after using SIP in the past), yet I doubt it is possible to use a plain XMPP client to join a conversation (jicofo on the way).
I was tangentially involved in the efforts to unite instant-messaging systems starting around 1998. (I ended up co-building iChat, which supported two of them.)
The IETF had a working group that got into pathological bikeshedding and eventually churned out some turgid specs describing what they’d like such a system to do, without actually designing anything.
Meanwhile Jeremie Miller hacked together Jabber, which basically worked despite the near-fatal flaw of using XML.
Finally it turned out none of the instant-message providers would let their systems interoperate with the others, because it would hurt the revenue from their precious walled gardens and expose their precious social graphs.
The only reason federated protocols like SMTP and HTTP succeeded is because they emerged before Big Social got a stranglehold. The fully open communications channels of the future will be P2P, or nothing.
But P2P opens a big privacy can of worms. I don’t want everyone I’m chatting with to directly get my home/mobile IP addresses, and “everyone who cares about location privacy must use proxies/tunnels” is kind of a crap solution.
future will be P2P, or nothing
So not only End-to-End encryption, but also Peer-to-Peer at the network level? That requires settling the chat protocol with the network unfortunately, but https://tox.chat did it!
It uses strong (NaCl/libsodium) crypto, decouples identity verification from encryption (so that you can exchange the raw keys or use a nameserver of any kind), and is peer-to-peer including for video. And have a large range of clients around.
iChat, the IETF, XMPP, walled-garden, social graphs
Thank you for sharing that piece of history of what has become modern messaging!
In case anyone have links toward pages from these new messaging protocol makers, which explain how the previous protocol were limited and why they did not want to upgrade it, I am deeply interested! \o
A better alternative would be to support the matrix standard that promises federation while giving modern features, rather than wrestling with email to make it work for you.
Matrix currently still seems to be a bit too instant and online for me. One of the things I value about Email discussions is that you can take your time, writing your messages offline and sending them all at once if you don’t have a connection right now. Matrix, that mainly seems to be implemented via Riot often takes too long to start, longer to load, there’s no threading, and I don’t feel too comfortable when writing (compared to my Email setup using Emacs, where I get the full screen and can easily quote whatever paragraph, sentence or work I’m responding to). It’s ok (but still has to be improved) for regular discussions with friends and the like, but that’s still going to take a while.
One of the things I value about Email discussions is that you can take your time, writing your messages offline and sending them all at once if you don’t have a connection right now.
This is the killer feature for me. I do most of my work offline and only go online to download new references, get and send emails, and waste time.
Most email clients that I know of do not handle discussions like this very well
Yes, but I would argue this is an implementation problem. The benefit of mail is, you can set this up for all at once. If you have a problem with the github UI you can add a plugin for better view or use the API. If you later have the same problem with the gitlab UI your github config doesn’t work because the interface is different. On mail you can set this up for all projects.
I know most MUAs are horrible at this, but newer protocols have the same problem.
Sending patches via email is as simple and straightforward
I would say sending and receiving patches via email is currently one of the downsides. Yes it works but it could be far better. I would say this is the biggest benefits of github/gitlab/…
First problem the send is done by git itself. Therefore you have to add your email credentials to git. Also the send mail only gets to your outbox, if your MSA puts outgoing mails in there (not sure how common this is).
On the receiving side you have to get the mail itself, which is with most GUI MUA not that easy. To apply the patch you have to guess the parent. The patch itself don’t include any hint’s for that. Yes you could write this in the cover-letter, but this would be only human readable (or only in your private format).
To have multiple patches, git-send-email generates one mail per commit. This works fine if you only want to answer to one commit. But if you want to reference multiple commits in one mail you have to copy. Also only one mail is referenced[0]. Send them as attachments is a workaround. Then your MUA should be able to use the content of attachments in a reply. I don’t know with MUAs have this feature. I assume this isn’t implemented very often.
[0] A email could theoretical reference multiple emails, but this isn’t implemented. Mostly because it has rare use cases and it’s hard to implement.
To apply the patch you have to guess the parent. The patch itself don’t include any hint’s for that. Yes you could write this in the cover-letter, but this would be only human readable (or only in your private format).
If you use the --base argument to git format-patch it will say the base commit. You can also specify any prerequisite patches. --base=auto is probably what you want, you can enable it by default globally with git config --global format.useAutoBase true.
But if you want to reference multiple commits in one mail you have to copy. Also only one mail is referenced
It’s not clear to me why you’d want to reference multiple commits in one mail. It’s a bit confusing what you mean here. You want to send multiple unrelated commits in a single email? Or multiple related commits?
If you want people to be able to respond to the patch series as a whole they should respond to the cover letter.
you use the –base argument to git format-patch it will say the base commit
Thanks didn’t know that.
You want to send multiple unrelated commits in a single email? Or multiple related commits
Of cures related commits.
If you want people to be able to respond to the patch series as a whole they should respond to the cover letter.
How do I use the content of the commits? how do I annotate which commits I reference? Oh by manual copy. As receiver I than have to manual search. Why do I have a computer again?
I know you find a workaround for every problem I mention. But this is somehow the problems. You need these workaround, because the base concept don’t work properly.
How do I use the content of the commits? how do I annotate which commits I reference? Oh by manual copy. As receiver I than have to manual search. Why do I have a computer again?
You respond to those patches, surely? It’s not clear what the issue is here, to me. I mean if you want to respond to a patch series as a whole, “holistically”, you respond to the patch series, if you want to respond to a single patch, you respond to it directly, if you want to respond to multiple emails, you need a good client because most don’t support that. But having them split makes sense because usually you want to either address the whole patch series as a concept or you want to dig into the nitty gritty of individual patches. I think if you want to respond to the nitty gritty details of multiple patches in a single email then they probably shouldn’t be multiple patches but should be a single patch.
I know you find a workaround for every problem I mention. But this is somehow the problems. You need these workaround, because the base concept don’t work properly.
First problem the send is done by git itself. Therefore you have to add your email credentials to git.
Not that different from using usual mail clients. Git is just another one, that only sends.
Also the send mail only gets to your outbox, if your MSA puts outgoing mails in there (not sure how common this is).
You can add your address to CC.
To apply the patch you have to guess the parent.
Master, unless the patch specified otherwise. You can apply the patch on whatever commit you want if it applies cleanly, and if it doesn’t, there’s git am -3 for a 3-way merge.
The patch itself don’t include any hint’s for that.
You can add such hints under the commit message in the patch.
Yes, but I already have one. It’s set up how I want my mail work. Why do I need an other?
You can add your address to CC.
Yes but why should I, my MUA does that for me. Also then the mail goes to my inbox not my output. Of course I can move it to my outbox. Also I can create a filter rule to automate that, but again why should I create an workaround for something my MUA already does?
Master, unless the patch specified otherwise
This only works if you process the patch directly. If you find a patch after a few month you have no clue with commit was the HEAD at this time and you may have to manual merge it before you can work with the commit.
You can add such hints under the commit message in the patch
Yes but you then have to parse this by human, because there isn’t a format for this.
Don’t get me wrong. I would love to have a good way to send patches/commits over email. But git send-email is horrible. Attaching format-patches is better but still have big problems.
Yes, but I already have one. It’s set up how I want my mail work. Why do I need an other?
Well you don’t need another. You can use a competently written mail client to send patches. But most of them are horrible and so if you want to send patches you need to use git send-email. Really, send-email exists for people that don’t want to change their mail client.
Don’t get me wrong. I would love to have a good way to send patches/commits over email. But git send-email is horrible. Attaching format-patches is better but still have big problems.
Well you don’t need another. You can use a competently written mail client to send patches. But most of them are horrible and so if you want to send patches you need to use git send-email. Really, send-email exists for people that don’t want to change their mail client.
Only partly true. git assumes you can put raw diffs in a Mail. But this only works if your diff contains only ASCII and no lines longer then 998 chars (excluding CRLF). Also Lines should not be longer then 78 chars. So most MUA implement MIME (rfc 2045ff) to avoid these problems. The implementation and documentation of git format-patch and git am just ignore there is something what is called Content-Transfer-Encoding.
Even if my MUA wouldn’t add a transfer encoding for long lines the complete handling is horrible. git format-patch generates one file per commit. These are mboxs with exactly one mail. So I need to get the mail out of the mbox to properly send a patch. Then you have to generate a series of drafts which reference the first mail of it. Of course no MUA implements this, because why do you want to reference a mail you haven’t even send?
The implementation and documentation of git format-patch and git am just ignore there is something what is called Content-Transfer-Encoding.
Then what is the --transfer-encoding argument to git-send-email for? Specify the transfer encoding to be used to send the message over SMTP. You can specify 7bit, 8bit, quoted-printable or base64 (or auto). The latter won’t have an issue with lines longer than 998 characters.
Also Lines should not be longer then 78 chars.
That rule of email etiquette doesn’t apply to patches in my experience.
git format-patch generates one file per commit. These are mboxs with exactly one mail. So I need to get the mail out of the mbox to properly send a patch.
You can just put the mbox into your Drafts folder…
It’s funny how you seem to have all these problems with something that’s used successfully by tens of thousands of Linux kernel developers along with countless other communities and projects.
EDIT:
If given –thread, git-format-patch will generate In-Reply-To and References headers to make the second and subsequent patch mails appear as replies to the first mail; this also generates a Message-Id header to reference.
This only works if you process the patch directly. If you find a patch after a few month you have no clue with commit was the HEAD at this time and you may have to manual merge it before you can work with the commit.
In my experience, maintainers will just tell you to send another revision if your patch doesn’t apply cleanly.
One thing I continuously experience when I try to implement a mailing-list based discussion medium is that people break the threading all the time. No matter how often I say “please respond to the post you are actually replying to” or “please don’t hijack threads”, it does not matter. Specifically the habit of replying to the last email that came from the list with an entirely new topic is something I appear to be unable to successfully fight. I’d really like an automated solution on the list server that prevents that…
That being said, I’m a huge fan of email-based communication. For my own projects, I’m currently running Redmine with its e-mail interface for forum and bug tracking enabled as a compromise. This works, but it does not honour threading so in my mail client all mails look as if they are replies to the root post. Mailman 3 has a nice web interface (Hyperkitty), but it’s a hazzle to administrate. Redmine requires much less administrative care than Mailman 3, which I find surprising given that Redmine does so much more than just the forum functionality.
For email: https://kanmail.io/ (popped up lately in here) and all the other client you may have.
And every smartphone app you will find for both (the lot of ’em!).
In the end, it is up to who receive the open protocol (IRC, SMTP, IMAP, RFC822/3522 mail format) to choose how to consume the conversations.
The real concerns are encryption : PGP/GPG usability to be able to communicate with non-tech people without teaching them crypto 101 (I am a terrible electrician, but I can still charge my phone). IRC OTR did not really take-off as the OTR community is moving to jabber.
Although that is not a concern for collaborating openly on software.
I agree 100% with the author, and I would also add that email is probably the most energy efficient, and quite easy to setup on your own.
It is fair, it works, but sadly people are slowly forgetting it and that is honestly scary. Seriously, I hate when people say they care about whatever environment is, and then launch gigantic webapp just to send couple texts.
Regarding things like bolding and italicizing, people make do just fine using /italics/, underlines, or bolds.
Email has supported styled text for over 20 years. And not just through HTML; there is/was an earlier format called text/enriched IIRC, very simple markup that just supported a couple of semantic text styles.
Inline images too, ever since the first MIME specs in the 90s. (Multimedia Internet Mail Extensions!)
The problem with email seems to be twofold:
On the one hand it started off incredibly primitive, and a whole flurry of different standards got implemented to modernize it, with the result that supporting them all is super complex and everyone implements a different subset of them in incompatible ways.
On the other hand, email seems to arouse the passions of Luddites who despise all of those modernizations and just want 72-column hard-wrapped ASCII, the way god created it. I really don’t get this. If the same thing had happened to the Web we’d still be using Lynx, and downloading our images over FTP.
That being said, email is terrible for discussions because if you don’t keep every message forever you don’t have a record of the conversation; and while most lists have online archives they’re implemented with pathetic, ancient software like Mailman that makes it a miserable chore to navigate and read.
The only thing worse than email for discussions is everything else. Unfortunately.
email seems to arouse the passions of Luddites who despise all of those modernizations and just want 72-column hard-wrapped ASCII, the way god created it. I really don’t get this.
I’m sorry but this sounds incredibly snarky. Why do you spend so many words maligning people with different aesthetic tastes than you? Progress isn’t linear, and given a variety of hardware and tastes, I can see why folks would prefer TUIs.
Seems like it hit hard on you… I guess because their taste forces un-usability features on others who argue that maybe text wrapping whould be the job of the MUA.
Personally I totally agree with @snej, and I think that this retrograde bunch was the cause email stagnated, which let bigco take over.
Actually no it did not; I’ve never been a fan of hard-wrapped lines due to various reasons. That doesn’t mean you need to make insinuations.
I guess because their taste forces un-usability features on others who argue that maybe text wrapping whould be the job of the MUA.
This is one of the reasons why I disagree with hard-wrapping of lines, yes, but I’m not sure where “forces” comes into the picture.
Personally I totally agree with @snej, and I think that this retrograde bunch was the cause email stagnated, which let bigco take over.
I’m not familiar with this narrative or the invective used here. Is there some cultural touchpoint I’m missing? I always prefer to assume good faith in commenters and I hope others do as well.
but I’m not sure where “forces” comes into the picture.
[…]
I’m not familiar with this narrative or the invective used here. Is there some cultural touchpoint I’m missing?
Maybe you have heard about OpenBSD and its mailing lists, email “etiquette”. They are not unique, but one of the few still surviving mailing lists. The mailing list people with their netiquette, and hostile communication to anybody not honoring their line-printer inspired format in the 2000s (even if by not knowing the rites) are actually forcing their aesthetic on others prefering different aesthetic, or workflows.
The broken perl/C based mailing list managers and the hostility of these communities turned lots of people away.
The rejection of HTML mail (even if it had technical issues, which could have been addressed with dialogue instead of outright rejection, thus staying away from the discussion) led to many people instead using richer web based forums for discussions, eventually leading to the complete halt of (open source) innovation in email-space.
Microsoft did innovations in email, to meet user needs. The way they did it was part of their EEE strategy.
Google also did do innovation Gmail/Groups, but those eventually became parts of its own EEE strategy.
Opensource meanwhile kept yelling: 72 column line wrap! Plain Text! No need for images! No need for structured content! Meanwhile people doing a bit more cross-disciplinary work then Unix administration/C coding saw place for these usecases. Email decays because it failed to leave the milieu it was born in.
I’m personally very angry at these people, because this form of communication is dying for the sake of low-effort instant gimmicky social-media communication forms, largely because their total inflexibility.
To them, email seems like an archaic platform where you can’t embed images, it’s not completely synchronous, and… I honestly couldn’t think of a third thing…
No, the biggest is the “Subject” field. Organizing discussion in topics as opposed to around correspondents, is a strong signal encouraging people to actually organize their thoughts before sending anything. This is already a too high barrier for entry for too many.
As long as your email client supports plain text email, you can use whichever you like the most.
Therein lies the rub. I expect many more would be comfortable using email for discussions if they can whack reply, type in their HTML-formatted reply as a top-post, embed their inline image and go merrily on their way. This is exactly the same workflow people use when they email groups of people directly. There is nothing to change or learn.
The concept of a Mailing List comes with a tonne of ascetic and technocratic baggage that is never going to resonate with the Slack-and-Discord crowd. Users make their choices accordingly.
What I would like is a federated group chat with client applications supporting multiple server accounts simultaneously. It would have rooms for multi-user-chat and explicit topics within the rooms (no default topic or interleaving the topics). Something close to what Zulip does (except it interleaves by default, which sucks).
It’s somewhere between sync and async. You can easily catch up if you don’t follow just in time and can skip across topics without finishing reading them. Nowadays I try to direct everyone (at work) away from email towards Zulip, because it saves me a lot of time.
Seriously, no one knows how to use email and no one uses it correctly. Email has been ruined long time ago by signatures, quotes, CC’s and general clutter to the point where you need email processor to be able to follow any sort of long or multi-user discussions.
Can we restart email with strict rules?
Cheers,
Johny
<body>
Johny Johnson - Founder of Company™
<img>
Hey what do you think of email?
Cheers,
Johny
<body>
Johny Johnson - Founder of Company™
</body>
ERROR: Some contents of email could not be loaded: libssl.so SSL certification error.
My wife teaches high school. For the most part, many kids there don’t know how to use email, even just to send a message. Some don’t even know what email is. It they do use it, they put the entire message in the subject line. They are confused by the mail client on iOS. They are used to instant messaging. The notion of longer, quoted, asynchronous messaging is not something they grasp.
I’m approaching 50 years old and most of my friends no longer use email to stay in touch, despite my best efforts to get them to use it (since I like it and prefer it). These friends are all tech-savvy and are in my age group.
Email is a dying medium. Part of this is because mailing lists are so terrible. This is, in fact, why so many people I know don’t use it: they find it inferior for group chats compared to things like Facebook and Discourse. I have a core group of friends that only uses email because I do. Otherwise, they would avoid it. Their reluctance to use it can be directly attributed to the attitude exhibited in the article: that plain text and a terminal are the pinnacle of human computer interaction and therefore, does not require any improvement.
Sadly for a lot of people, email is just something they use to get password reset and account activation emails that are basically little webpages addressed to them.
The thing is, people understand what they’re taught and introduced to. Introduce kids to email and they understand email. You can’t just put someone in front of something unfamiliar and then expect them to understand it immediately with no instruction. If you’ve only ever used Facebook Messenger then of course Email is going to seem odd. In the same way, my aunt has used email but when she tries to use Messenger she uses it like email (or snail mail): long messages starting with ‘Dear X,’ and ending with ‘See you soon, Y’. That’s just as ridiculous as putting the whole message in an email’s subject.
Well, it is inferior for group chats compared to things like Facebook. It’s not an instant messenger and trying to use it like one leads to stuff like “they put the entire message in the subject line”.
Discourse is a forum, right? I think forums and mailing lists serve different purposes and forums are generally superior for general meandering discussion while mailing lists are much better for focused topic-specific discussion, especially when it’s discussion about specific topics within a larger subject and you want to do things like transition freely between private small-group discussions on a topic and list-wide discussions. But mailing lists fail when they become forums, because general discussion forums and threads are a horrific combination (as you can see from reddit, HN, lobsters, etc., which only work well for news aggregation, while using reddit self threads as discussion forums is abysmal).
But email is much better than instant messengers or forums for stuff like sending family photos or organising something long-term (like an overseas trip) with family members, IMO. The ease of attaching tickets and photos and stuff like that is just unparalleled. And it’s definitely far superior for discussing patches for free software projects. How that’d work on a forum or instant messenger is beyond me.
Does this strike you as symptomatic of a problem? It does me; I think that developing the capacity to consider someone else’s thoughts, reflect and respond is pretty key.
Terminals could probably use some improvement, but written communication is more advanced than spoken, which is in turn more advanced than pointing and grunting. A mouse or touchscreen enables and extraordinarily primitive form of communication: pointing at things and ‘grunting’ at them.
With a keyboard, OTOH, one is capable of communicating every rational thought. Which is pretty remarkable.
I have some “pen palls” that I have discussions with over email, generally exchanging longer “letters” every few weeks or something like that. I like instant message and groups chats too, but it’s not quite the same. These are all tech people.
I’m really sure if there’s a good alternative for this kind of thing; I think there’s some space for future innovation here which preserves some of the good properties of email but avoids the various problems people experience.
SLOWLY is an interesting app here, although it just allows talking to strangers (and it’s mobile-only, which I don’t really like to type long letters on).
I’m not sure if I’ve yet seen a good e-mail client. Thunderbird is what I’m using right now, but it kind of sucks. All the webmail clients are ridiculously heavy, confusing, and have long loading times. Maybe Outlook is good.
Everyone, and every e-mail client, has a different idea of how e-mail works. Does the quoted text go at the bottom or the top? Is text hard or soft wrapped? If hard wrapped, is it wrapped at 80 or 72 columns? You end up with person A sending something with hard wrapping set to 80 columns, then person B quotes parts of that with 72 column hard wrapping, and you get alternating 72 and 8 column lines.
E-mail is a terrible medium for sending code. Most programmer types insist on hard wrapping, but e-mail clients configured to hard wrapping will break code by inserting newlines. Most people recommend hard wrapping at 72 lines; most code is wrapped at around 80-100 lines if at all.
E-mail is barely decentralized. Good luck hosting your own e-mail server without being overrun by spam and without being marked as spam by the big providers. Pray you don’t ever get your IP address globally blacklisted; pray your IP address has never been used for mail spam in the past.
An e-mail client is about as hard to implement as a web browser, since an e-mail client needs to parse and display HTML and CSS like a browser would (or at least like Outlook would).
E-mail discussion chains inevitably end up with a messy mix of hard wrapping at 80, hard wrapping at 72, HTML, plaintext, quoted text above the message, quoted text at the bottom of the message, and messages using symbols from proprietary Microsoft fonts.
E-mail is a terrible discussion platform.
There’s
format=flowedfor that now. Mailing list etiquette ended up against top-posting, which means quoted text shouldn’t to go the bottom.You should use
git send-email, not pastinggit format-patchoutput into your mail client.Email shouldn’t have gotten HTML support in the first place, thank Microsoft for that. Also, almost all HTML email is sent for advertisement. How often do you see an email from a person that actually needs HTML? I haven’t seen one yet.
Ah, that famously super well-supported feature which every e-mail client can use.
I don’t think I’ve used many e-mail clients which don’t default to putting quoted text at the bottom. When “mailing list etiquette” goes against most mainstream e-mail clients’ defaults, you guarantee that at least a large portion of the users won’t follow “mailing list etiquette”.
Ah, so I can’t even use my preferred e-mail client to send patches.
Well, it’s here now. “E-mail sucks because Microsoft” isn’t a counter-argument to “e-mail sucks”.
Nope, I receive lots of HTML e-mail which isn’t advertisements.
Not many? Still, when I receive HTML e-mail, my client needs to support HTML.
If your client can’t support basic features use a different one.
And of course you can use your preferred email client to send patches, as long as it’s able to be configured to send patches properly. git send-email is just much more reliable than arbitrary shitty client number 72.
Email with people that use shit Microsoft products is, like most interactions with those people, pretty crap. It doesn’t matter what communication method you use with Microsoft-using people, you’re still going to get proprietary formats of one kind or another. At least with Email there’s a nice smooth transition path away from Microsoft crap towards much more functional alternatives.
All HTML email I receive is in one of three categories:
Is there a different kind of HTML email you receive? I’m interested to hear this because everyone I’ve spoken to is in the same situation I’m in with HTML email.
Your browser supports HTML. Why can’t your client just open the HTML email in a browser window? It could even be a browser window embedded in the client window if that’s your preference.
This sounds quite harsh to me. I don’t use windows or ms office or anything at home, but I have to useit all at work. Some purpl people don’t have a lot of choice.
Regular folks will typically buy a laptop with Windows and stiff pre-installed. How many consumer-laptops with lowprice with Linux pre-installed are there? Some people don’t have a choice in this as well.
Rant incoming, be forewarned:
My patience has slowly run out with people that choose to stick their head in the sand and ignore the bajillions of reasons that Windows is a harmful platform designed by harmful people to harm. It’s spyware, it’s anti-standards, it’s buggy, it’s just crapware. I don’t mean to be inflammatory, I’m just sick of it. I’ve spent enough time trying to explain the issues with Microsoft products to various family members over the years. They just don’t care about privacy. They don’t care about supporting an American defence contractor. They just don’t care. They’ll complain about the decline of local bookstores and use Amazon. They’ll complain about their local butchers and grocers closing while spending most of their disposable income at the supermarket. They’ll complain about the quality of their computer and about how much they hate computers and computing, all of it Microsoft-specific annoyances and bad UI, and they’ll just keep on giving money to Microsoft. “Regular folks” can deal with their privacy issues and crap spyware software themselves. People choose to be ignorant, to not explore alternatives, to not learn anything new or unfamiliar. I’ve had enough.
You can use more than one client. Some are better at some things than others.
I haven’t seen any mail client that wouldn’t send text when sending HTML alternative. Only time I’ve seen HTML emails without text is advertisements.
Which basically nothing supports.
Really? How sad. It’s dead simple to implement. I know Apple Mail has supported it since 2000.
FastMail wrote an article detailing why they don’t support it: https://fastmail.blog/2016/12/17/format-flowed/
Wow.
I used to think so too, until I found out even Theo de Raadt seems to have given up on bottom-posting:
https://marc.info/?l=openbsd-misc&m=159128694514674&w=2
(The above link is just a random email I found when trying to see if navigating some mailing list arcives was as unintuitive as I remembered it to be. Conclusion: it is.)
I’ve been extremely happy with aerc: https://aerc-mail.org/
It has readability issues sometimes for some HTML emails, but for personal communication I’ve found it to be a joy to work with. I’ve used it daily for nearly a year.
I really want aerc to replace mutt for me, but it’s missing some crucial features: pgp mail encrypt/decrypt and signing support, and email threads. I learned enough golang when aerc was first started to contribute a tiny number of patches, but implementing these things are beyond what I have time/patience for at the moment. I hope one day I can drop mutt for good, and use aerc full-time.
This is the actual killer feature of email for programming projects. A good client with threads and a mailing list is better than most web-based forums.
I’ve never missed email threads (although I’ve never used Mutt so I can’t compare), but I agree that PGP is a big missing feature. Currently, it’s WIP: https://todo.sr.ht/~sircmpwn/aerc2?search=label:%22pgp%22
An additional problem is that you never know if someone is going to read your email in monospace or proportional fonts. If it’s the latter, then there’s no real way to send tabular data for example, or otherwise aligned text. Other than HTML of course, but some people are rabidly opposed to that as well, so you never know if that works for them, either 🤷♂️
Also, when you use email lists are the primary way to get in touch for bug reports an the like, you’re actually adding quite a barrier IMO. You often need to be subscribed and you’re spammed with emails you don’t care about. Even if you don’t need to subscribe, you may get CC’d for a long time and get emails you may not care at all about.
You send HTML with the tabular/code/etc. stuff in a
<tt>block. (Except the editor will probably instead use an inline CSS style, but same difference.) The luddites will be reading the plain-text alternate body in a monospaced font anyway, so everyone’s happy.Most non-terminal email clients display the text version as proportional, and there’s almost always an option to prefer the text version over HTML, so some people must be enabling that (perhaps not many, but not 0 either, especially among the tech crowd).
I actually enable it myself in FastMail, mostly so that I have a consistent experience reading text. I just enabled and went through some of my recent email conversations, and for some reason loads of email clients set weird fonts, colours, line-heights, and that kind of stuff on their outgoing emails. I don’t really mind HTML email as such but having the entire UI and my email in 14px fonts, and then getting an email with a huge 22px font does not exactly make for a great reading experience.
At least it looks like Outlook stopped sending their emails in fecking blue text by default, so that’s an improvement.
Ironically the luddites are the ones using Outlook and Gmail and other useless wrong-by-default email clients.
A random historical note, since I think the community will appreciate it:
The Luddites were not anti-technology (other than machines that harmed them by existing).
The closest analogue to the Luddites I can think of today are the people deliberately feeding bad data into adtech.
Outlook is awful and doesn’t implement email according to the specs or the way anyone else implements it. It’s just broken. It’s the classic ‘EEE’ strategy of Microsoft.
On quoting, I don’t know if it’s Gmail or Outlook or something else that started ruining it for everyone else by defaulting to this top-posting style but it’s wrong. Bottom-posting and eliding parts of the email you’re not replying to (interspersed quotes with your message) is standard, but to be honest most of the time you really don’t need to quote anything at all. When writing a letter you don’t photocopy or cut up parts of the original letter, paste them to the page and write your responses in between the bits of the original letter. You just reply. You say ‘in relation to X, I think [blah blah]’. I’ve been trying to get out of the habit of quoting posts I’m replying to on threaded forums, it’s really unnecessary when anyone can read the post I’m replying to directly above it. It’s mostly useful when you want to reply to a specific point.
For sending code, there are two options. You can attach code, or you can put the code inline. Inline, code shouldn’t be hard wrapped. It’s not hard to configure a client to not wrap code, and frankly if you can’t configure your client to do this it’s just a bad client and you should find a new one or someone should fix the old one. How many widely used non-webmail email clients are not free software? Outlook is the only one I can think of.
Email is super decentralised. It’s frankly just a myth that it’s hard to set up an email server that won’t get blacklisted or that you get heaps of spam. Spam filtering is really accurate these days.
If you want to look at HTML, use a web browser. Email clients are for reading and dealing with email. Open a web browser window, embed a web browser, whatever.
Stop having email discussion with people still using Outlook in 2020 and 99% of your issues with email disappear.
This is what eventually drove me to give up and use webmail (helped by fastmail actually having quite a good/fast webui with only a small number of mildly annoying bugs).
I have been using email clients that don’t display HTML at all beyond stripping out tags so it’s readable as plain text, and I haven’t been missing anything. The only HTML-only emails I get are spam. And because HTML is an attachment, if I really need to view it, I can open it in a browser.
The FastMail web UI is one of the few (non-trivial) SPA apps that I actually enjoy using. I think it got a lot of subtle things right that a lot of other SPAs didn’t.
One of the bigger pain points is that it’s almost unusable with email discussions: you get a lot of duplicate messages (including those that you sent) and there’s no threading. It was probably never designed with that use case in mind, so that’s okay. But it does go to show that “you can just use email client” isn’t exactly true: you can use “any email client with specific features to deal with mailing lists”, and a lot of those features seem quite unnecessary outside of mailing lists. I’ve happily used FastMail for 7 years and it works perfect for everything else.
I have a simple solution for this problem: don’t participate in mailing lists, which goes to show that things are perhaps not as easy and accessible and easy as claimed in this article.
I’ve used many different email client over the years: probably all of the mainstream webmail, GUI, and terminal ones; the first part of the mutt tagline is completely accurate IMO, the second part … meh. Again, this seems further evidence to me that email is not as easy as it made out to be here.
FastMail does threading if you enable it in the preferences. I subscribe to multiple mailing lists and use a single UI, fastmail, to read and manage the messages from all of the lists. A single inbox is the reason I prefer email to web forums.
I think you mean the message grouping? It’s nice, but not quite the same as threading shows threads within a conversation, whereas the message grouping just shows everything from old to new. IMO it doesn’t work very well for mailing lists beyond reading.
Apple’s mail client (the macOS version, not the horrible iOS one) is pretty decent. It’s about the only Mac app I actually miss on other platforms. It handles a few tens of GBs of messages, searching is fast and works well, it does quoting sensibly, lets you reply to a part of a message the same way lobste.rs does (select the part you want to quote and hit reply), and so on. Thunderbird is just about okay. Both handle sending with multiple email addresses from the same account nicely (iOS mail doesn’t, for example). Thunderbird has slightly better threading support (Apple Mail renders threads as lists, not trees, so can be confusing for threads that split into subdiscussions).
Outlook really struggles with non-HTML mail (it uses a Rich Text control for editing and then strips the formatting, often in surprising ways such as removing the quote bars, Apple Mail uses leading >s for quoted sections but renders them as coloured bars). My favourite Outlook bug arising from this is that, if you set your default to plain text and hit the ‘Make Teams Meeting’ link, it puts rich text with links to join your meeting and then silently strips them when you send so the recipient has no idea what they’re supposed to do to join.
There are a few things that make email really bad. The first is archive storage. I have hundreds of MBs of LLVM mailing list archives. I keep my own copy because that’s the only way of being able to reply to or forward an old post easily. Dovecot avoids this by having a central IMAP folder for their mailing list history that anyone can subscribe to, but configuring that looks sufficiently annoying that I’ve never done it (I don’t want to add a new mail account to every mail client I use just to view it). Most of the time, I find posts on other projects from their web archives, but if I want to add a follow-on question then I have no mechanism to get that post in a form that I can hit reply to. Instead, I have to create a new thread and quote it, which breaks everyone else (and often doesn’t add the original sernders to the cc list correctly because most mailing list archives anonymise the sender addresses to avoid spammers harvesting them).
Email is fine for a project that I’m actively engaged with. It’s far more annoying for projects that I’m casually contributing to. Things like GitHub issues are far better for that. They’re archived by search engines and if I find the issue and have more questions / comments I can hit reply and add them in the same thread.
To be fair, you don’t have to pray, you can query the spam databases.
Yeah, but there’s usually not that much you can do if you find your IP address in a spam database.
You could simply switch your instance or server.
Running it in the address space of cloud VM providers is a bad idea indeed, but at a normal hoster it should be no problem. Maybe find one that is paid monthly and you can just cancel it.
If you can’t host with a VM provider (because their block is probably banned) and you can’t host on your own (because of residential IP address reuse), won’t hosting be very expensive?
that was not the question. I know people who wouldn’t trust their emails on a VPS/shared host anyway, so I’d say a good portion of people having their own mailserver do it on dedicated hardware anyway.
Also while sometimes whole blocks are banned, often it’s really just single IP addresses on the blacklist. Also maybe the same hoster has a different data center and then maybe a different block. As I said, if this is your concern you might not have success on the first try.
And that’s also the reason I have stayed with my current hoster, upgrading the same VPS contract with the same IP every few years, because I’ve been running my mailserver off of this IP for ~10 years and don’t have any of these problems.
The best discussion platform I’ve ever used was bbcode forums. Easy to extend, easy to organize, easy to search, easy to use. We need a modern take on those.
Forums are great but they’re very different to mailing lists, IMO. (Flat!!) forums are much better for meandering discussions and as a community hub. They’re much better for long-running threads. The osdev forums are a great example: each person can make their own thread for posting updates about their project, there are many threads that have run for years, etc.
But you couldn’t use a phpBB-style forum to discuss patches or something, it just wouldn’t work.
You don’t need to. Right tool for the job: to discuss patches, use Phabricator, GitLab, GitHub, etc. (Anything other than Gerrit.)
The right tool for the job is a mailing list. Code forges are appallingly bad for discussing patches because none of them make it at all easy to suggest changes in the form of a simple patch.
In GitHub PRs, I can just write:
```suggestion{my proposed change}```And there’s then a button to apply the change (or add it to a batch to apply) right there as a new commit in the PR. CI then runs automatically, without needing anyone to check out the code locally. What is the mailing list workflow that is simpler than this?
Forums are considerably better. The thing is you could just as well us an email client to read and post to forum too. Forums have always been superior at presenting discussions compared to mailing list archives. There is certainly room for improvement (Discourse seems like a decent attempt), but when it comes to organizing and browsing past discussions, I’d take bbforum over Mailman.
Discourse is the closest I have seen. A pig to host, though, and extension is via http api (your bot also needs hosting etc).
Have you ever tried Zulip? The Lean prover community has one and it seems to suit them well (same for rust, these days). I like it a lot, best threading I’ve seen in any kind of messaging system, and it encourages longer form messages with embedded LaTeX and markdown.
Couldn’t disagree more with you. Bbcode forums are some of the worst designed interfaces that have ever existed. There abdundance of completely useless user information:
A whole 5 page thread of bbcode forums could fit in a single old.reddit screen.
Fully agree. The convenience and efficiency of email is unmatched. I hate having to use Slack for work. The UI is so sluggish, I get pinged for the silliest of things (because they can!). Email makes people more thoughtful while communicating. You can’t delete a sent mail. And more importantly, email won’t go away. What’s to say Slack won’t “thank you for the incredible journey” when their VC funding stops?
Also agree and hate slack for work - have you tried Ripcord? I switched from the official client and it’s far quicker/calmer! Still won’t fix the expectation slack gives to colleagues sadly…
Ripcord won’t build on OpsnBSD, sadly. I’ve spoken to the dev about it. For now, I use wee-slack, which sucks less.
I hope that is the case. Fortunately, my time using Slack was brief. When you give the users to option to ping people with ease they will, however, due to the nature of email (and email lists) they are normally more precise as they are only done when necessary.
I hate how little control I have over things sent through email. I want to like email, and I was thinking long about why email makes me uncomfortable instead. I think this is maybe my sore point. Things like:
Being able to verify what your message will look like on the receiver end. I use that pretty ‘Preview’ button here on Lobsters all the time. Plain text simplifies a bit, but stuff like git-send-email complicates this again.
Verifying your message was received the way you intended. Recent example was me sending some DNS records to a client’s technical contact. Except their virus scanner botched the records by transforming them like links, wrapping them with some link-scanner URL. Cue 6 extra mails back and forth until we found a working solution. (Ties in with lack of moderation and threading issues.)
Making editorial changes after the message was sent. How many more times do we have to deal with missing attachments already? (Cue 2 extra mails every time.) (Also applies to IRC, btw.)
Tools that take over sending from the regular MUA, like git-send-email, just make me wary. I want to know when something is going out in my name. I want ample confirmation, or at least the flow I’m used to.
And I can’t help but nod at all the other issues mentioned here. Email is kind of terrible.
There is a good argument that you shouldn’t worry about this. Not all people are going to look at your email. Some are going to hear it. Some are going to touch it. You should let people to read your email as they want.
Preview on lobsters shows what your comment will look like on your screen once you’ve clicked send. But it doesn’t tell you how it’ll look on someone else’s screen, which can be subject to:
etc. The argument that these are less common on the web is probably an argument against the web, because people make these customisations for good reason, and being able to scale up fonts and use dyslexic-friendly fonts, etc. is an important accessibility concern.
A pain in the arse for sure, but ISPs and virus scanners have been known to do similar things to web pages too! I remember reading horror stories about ISPs inserting ads into web pages, for example. So it’s not just an email problem.
I think this is a good thing. It has tradeoffs, it can be annoying, but I quite like that once I’ve received an email the person sending it can’t go back and edit it later.
IRC you can just do
and you can even configure some clients to perform the replacement. :D
git config sendmail.confirm alwayslol it would actually be difficult for me to find a post I disagree with more. The fact that email is an open platform is about the only thing I agree with the author about.
It really is. It’s reasonably easy to use if a thread remains linear, but if it branches at all (someone responds to a message that isn’t the latest one in a thread) it becomes almost impossible to follow.
Ok, this is wrong in two ways, one is that without moderation tools your mailing list becomes a mess and the other is that every mailing list platform I’ve used lets you block people from the list.
It may well be great but let’s face it, we lost the war on HTML email a long long time ago
True! If I have a gmail account and you have an outlook account we talk just fine, however running your own mail server is an exercise in pain so that the big mail providers don’t put you on a spamlist
I just responded to a message that isn’t the latest one in the thread. Do you find this difficult to follow?
In Discord, you can get banned outright, that is you cannot participate in any community discussion. Can this happen in email? No.
What’s the last time you’ve seen an email that needs HTML features written by a human person for you? You don’t need HTML mail.
I don’t, because I’m not using email. Reddit/lobsters or traditional forum software is so much easier to navigate
Well my mom emails me regularly with inline images and rich text, so…
Because you’re used to it, I guess. I really clearly remember opening Reddit and being utterly perplexed as to how it was meant to work. Why were some messages half way across the screen? Why were all the messages over on the left? How could I centre the messages on my screen? How were the messages sorted?
If you have a gmail account, you are creating problems for everyone who doesn’t. GMail is the single biggest offender when it comes to false positives and silent loss of messages coming from independent servers.
I keep holding on, but yes, this is sadly true
Do you really feel that way? Personally I hate threaded discussions for anything except mailing lists. They’re particularly odious on discussion forums, which is part of why using reddit as a discussion forum sucks so much.
But for discussing patches on a mailing list, for example, having multiple threads of discussions with different people all interlaced in a linear order seems much worse than threading. One person replies with some style suggestions, another with a functionality request and another with a bug. Do you really want those comments and their replies to be interlaced? All that’s going to happen is people are just going to quote the entire thing they’re responding to in the linear thread to emulate true threading. You see this on flat/unthreaded forums all the time.
I think the point being made here is not about moderation on the mailing list level (which is fine, communities can and should moderate themselves) but on the platform level. If you use Slack or Discord then your use of the entire platform can be moderated away by the people that run those platforms.
About the only way you can moderated off ‘email’ as a platform is if you’re moderated off the entire internet in general. If you’re not literally the Daily Stormer you should be fine.
In what way? People use HTML email, people use Discord, people use Facebook. Others using something doesn’t mean you have to use it. When I get HTML email, depending on context, I sometimes explain to people why it’s problematic (accessibility, privacy, etc.). I have emailed service providers asking that they send plain text and HTML email, or at least don’t send a “plain text” mime part that’s just got HTML in it, because it confuses my email client.
People will keep using HTML email. You don’t have to.
It’s honestly not that hard and even if you don’t want to, there are lots of reputable non-Gmail non-Outlook webmail providers like Fastmail etc.
And you can use those providers but not use their webmail client, just throw their IMAP/SMTP details into your email client.
While I agree with all that the author has said about the walled garden-ness of platforms like slack, I do think emails are highly unsuitable for having a proper discussion and conversation.
The neomutt image perfectly demonstrates it, as you can only see the subject line and the names of the responders without being able to scan through all the replies at once to see what’s going on. Most email clients that I know of do not handle discussions like this very well.
A better alternative would be to support the matrix standard that promises federation while giving modern features, rather than wrestling with email to make it work for you.
For the past 20 years there has been countless posts published on the internet saying X is best for Y and it boggles my mind that so many intelligent engineers didn’t yet conclusively conclude that such binary statements are useless. Because the only true comment here is “it depends”.
I’ve seen fantastic discussions on a classic forum system. I’ve seen brilliant discussions in an xmpp group chat. I had some of my best discussions through ICQ, Facebook comments, WhatsApp, Viber, Twitter. I had very efficient discussions via email as well.
I’d say, don’t fight the horse. Ride it.
Which one? :P
The only four APIs that unite all chat systems are :
And all of them require supporting all of the platforms up front.
I wish everyone coming up with a new protocol to take a deep thought on whether it could not have been done with the existing ones out there before to deploying it for everyone:
For instance, Jitsi uses XMPP (after using SIP in the past), yet I doubt it is possible to use a plain XMPP client to join a conversation (jicofo on the way).
I was tangentially involved in the efforts to unite instant-messaging systems starting around 1998. (I ended up co-building iChat, which supported two of them.)
The IETF had a working group that got into pathological bikeshedding and eventually churned out some turgid specs describing what they’d like such a system to do, without actually designing anything.
Meanwhile Jeremie Miller hacked together Jabber, which basically worked despite the near-fatal flaw of using XML.
Finally it turned out none of the instant-message providers would let their systems interoperate with the others, because it would hurt the revenue from their precious walled gardens and expose their precious social graphs.
The only reason federated protocols like SMTP and HTTP succeeded is because they emerged before Big Social got a stranglehold. The fully open communications channels of the future will be P2P, or nothing.
But P2P opens a big privacy can of worms. I don’t want everyone I’m chatting with to directly get my home/mobile IP addresses, and “everyone who cares about location privacy must use proxies/tunnels” is kind of a crap solution.
It uses strong (NaCl/libsodium) crypto, decouples identity verification from encryption (so that you can exchange the raw keys or use a nameserver of any kind), and is peer-to-peer including for video. And have a large range of clients around.
Thank you for sharing that piece of history of what has become modern messaging!
In case anyone have links toward pages from these new messaging protocol makers, which explain how the previous protocol were limited and why they did not want to upgrade it, I am deeply interested! \o
Matrix currently still seems to be a bit too instant and online for me. One of the things I value about Email discussions is that you can take your time, writing your messages offline and sending them all at once if you don’t have a connection right now. Matrix, that mainly seems to be implemented via Riot often takes too long to start, longer to load, there’s no threading, and I don’t feel too comfortable when writing (compared to my Email setup using Emacs, where I get the full screen and can easily quote whatever paragraph, sentence or work I’m responding to). It’s ok (but still has to be improved) for regular discussions with friends and the like, but that’s still going to take a while.
This is the killer feature for me. I do most of my work offline and only go online to download new references, get and send emails, and waste time.
Yes, but I would argue this is an implementation problem. The benefit of mail is, you can set this up for all at once. If you have a problem with the github UI you can add a plugin for better view or use the API. If you later have the same problem with the gitlab UI your github config doesn’t work because the interface is different. On mail you can set this up for all projects.
I know most MUAs are horrible at this, but newer protocols have the same problem.
I would say sending and receiving patches via email is currently one of the downsides. Yes it works but it could be far better. I would say this is the biggest benefits of github/gitlab/…
First problem the send is done by git itself. Therefore you have to add your email credentials to git. Also the send mail only gets to your outbox, if your MSA puts outgoing mails in there (not sure how common this is).
On the receiving side you have to get the mail itself, which is with most GUI MUA not that easy. To apply the patch you have to guess the parent. The patch itself don’t include any hint’s for that. Yes you could write this in the cover-letter, but this would be only human readable (or only in your private format).
To have multiple patches, git-send-email generates one mail per commit. This works fine if you only want to answer to one commit. But if you want to reference multiple commits in one mail you have to copy. Also only one mail is referenced[0]. Send them as attachments is a workaround. Then your MUA should be able to use the content of attachments in a reply. I don’t know with MUAs have this feature. I assume this isn’t implemented very often.
[0] A email could theoretical reference multiple emails, but this isn’t implemented. Mostly because it has rare use cases and it’s hard to implement.
If you use the
--baseargument togit format-patchit will say the base commit. You can also specify any prerequisite patches.--base=autois probably what you want, you can enable it by default globally withgit config --global format.useAutoBase true.It’s not clear to me why you’d want to reference multiple commits in one mail. It’s a bit confusing what you mean here. You want to send multiple unrelated commits in a single email? Or multiple related commits?
If you want people to be able to respond to the patch series as a whole they should respond to the cover letter.
Thanks didn’t know that.
Of cures related commits.
How do I use the content of the commits? how do I annotate which commits I reference? Oh by manual copy. As receiver I than have to manual search. Why do I have a computer again?
I know you find a workaround for every problem I mention. But this is somehow the problems. You need these workaround, because the base concept don’t work properly.
You respond to those patches, surely? It’s not clear what the issue is here, to me. I mean if you want to respond to a patch series as a whole, “holistically”, you respond to the patch series, if you want to respond to a single patch, you respond to it directly, if you want to respond to multiple emails, you need a good client because most don’t support that. But having them split makes sense because usually you want to either address the whole patch series as a concept or you want to dig into the nitty gritty of individual patches. I think if you want to respond to the nitty gritty details of multiple patches in a single email then they probably shouldn’t be multiple patches but should be a single patch.
I just don’t think these are problems at all.
Not that different from using usual mail clients. Git is just another one, that only sends.
You can add your address to CC.
Master, unless the patch specified otherwise. You can apply the patch on whatever commit you want if it applies cleanly, and if it doesn’t, there’s
git am -3for a 3-way merge.You can add such hints under the commit message in the patch.
Yes, but I already have one. It’s set up how I want my mail work. Why do I need an other?
Yes but why should I, my MUA does that for me. Also then the mail goes to my inbox not my output. Of course I can move it to my outbox. Also I can create a filter rule to automate that, but again why should I create an workaround for something my MUA already does?
This only works if you process the patch directly. If you find a patch after a few month you have no clue with commit was the HEAD at this time and you may have to manual merge it before you can work with the commit.
Yes but you then have to parse this by human, because there isn’t a format for this.
Don’t get me wrong. I would love to have a good way to send patches/commits over email. But git send-email is horrible. Attaching format-patches is better but still have big problems.
edit: formating
Well you don’t need another. You can use a competently written mail client to send patches. But most of them are horrible and so if you want to send patches you need to use
git send-email. Really,send-emailexists for people that don’t want to change their mail client.It’s completely fine.
Only partly true. git assumes you can put raw diffs in a Mail. But this only works if your diff contains only ASCII and no lines longer then 998 chars (excluding CRLF). Also Lines should not be longer then 78 chars. So most MUA implement MIME (rfc 2045ff) to avoid these problems. The implementation and documentation of git format-patch and git am just ignore there is something what is called Content-Transfer-Encoding.
Even if my MUA wouldn’t add a transfer encoding for long lines the complete handling is horrible. git format-patch generates one file per commit. These are mboxs with exactly one mail. So I need to get the mail out of the mbox to properly send a patch. Then you have to generate a series of drafts which reference the first mail of it. Of course no MUA implements this, because why do you want to reference a mail you haven’t even send?
Then what is the
--transfer-encodingargument togit-send-emailfor? Specify the transfer encoding to be used to send the message over SMTP. You can specify 7bit, 8bit, quoted-printable or base64 (or auto). The latter won’t have an issue with lines longer than 998 characters.That rule of email etiquette doesn’t apply to patches in my experience.
You can just put the mbox into your Drafts folder…
It’s funny how you seem to have all these problems with something that’s used successfully by tens of thousands of Linux kernel developers along with countless other communities and projects.
EDIT:
Does this solve your issue?
In my experience, maintainers will just tell you to send another revision if your patch doesn’t apply cleanly.
One thing I continuously experience when I try to implement a mailing-list based discussion medium is that people break the threading all the time. No matter how often I say “please respond to the post you are actually replying to” or “please don’t hijack threads”, it does not matter. Specifically the habit of replying to the last email that came from the list with an entirely new topic is something I appear to be unable to successfully fight. I’d really like an automated solution on the list server that prevents that…
That being said, I’m a huge fan of email-based communication. For my own projects, I’m currently running Redmine with its e-mail interface for forum and bug tracking enabled as a compromise. This works, but it does not honour threading so in my mail client all mails look as if they are replies to the root post. Mailman 3 has a nice web interface (Hyperkitty), but it’s a hazzle to administrate. Redmine requires much less administrative care than Mailman 3, which I find surprising given that Redmine does so much more than just the forum functionality.
Plain text might still be “rich content” through parsing of links.
And every smartphone app you will find for both (the lot of ’em!).
In the end, it is up to who receive the open protocol (IRC, SMTP, IMAP, RFC822/3522 mail format) to choose how to consume the conversations.
The real concerns are encryption : PGP/GPG usability to be able to communicate with non-tech people without teaching them crypto 101 (I am a terrible electrician, but I can still charge my phone). IRC OTR did not really take-off as the OTR community is moving to jabber.
Although that is not a concern for collaborating openly on software.
I agree 100% with the author, and I would also add that email is probably the most energy efficient, and quite easy to setup on your own.
It is fair, it works, but sadly people are slowly forgetting it and that is honestly scary. Seriously, I hate when people say they care about whatever environment is, and then launch gigantic webapp just to send couple texts.
What a weird times we live in.
If you mean a client, I sort of agree. If you mean a server, I think you are dismissing a whole lot of evidence to the contrary.
I said quite about the server. It is not something impossible, but it is a task that will take day or two for a proficient person.
… followed by a lifetime of keeping the blasted thing patched and up to date with anything remotely resembling best practices, as those evolve.
Well that’s true for hosting anything.
Except for the thousands of CPU-years spent on Perl interpreting SpamAssassin code all over the world ;)
Email has supported styled text for over 20 years. And not just through HTML; there is/was an earlier format called text/enriched IIRC, very simple markup that just supported a couple of semantic text styles.
Inline images too, ever since the first MIME specs in the 90s. (Multimedia Internet Mail Extensions!)
The problem with email seems to be twofold:
That being said, email is terrible for discussions because if you don’t keep every message forever you don’t have a record of the conversation; and while most lists have online archives they’re implemented with pathetic, ancient software like Mailman that makes it a miserable chore to navigate and read.
The only thing worse than email for discussions is everything else. Unfortunately.
I’m sorry but this sounds incredibly snarky. Why do you spend so many words maligning people with different aesthetic tastes than you? Progress isn’t linear, and given a variety of hardware and tastes, I can see why folks would prefer TUIs.
Seems like it hit hard on you… I guess because their taste forces un-usability features on others who argue that maybe text wrapping whould be the job of the MUA.
Personally I totally agree with @snej, and I think that this retrograde bunch was the cause email stagnated, which let bigco take over.
Actually no it did not; I’ve never been a fan of hard-wrapped lines due to various reasons. That doesn’t mean you need to make insinuations.
This is one of the reasons why I disagree with hard-wrapping of lines, yes, but I’m not sure where “forces” comes into the picture.
I’m not familiar with this narrative or the invective used here. Is there some cultural touchpoint I’m missing? I always prefer to assume good faith in commenters and I hope others do as well.
Maybe you have heard about OpenBSD and its mailing lists, email “etiquette”. They are not unique, but one of the few still surviving mailing lists. The mailing list people with their netiquette, and hostile communication to anybody not honoring their line-printer inspired format in the 2000s (even if by not knowing the rites) are actually forcing their aesthetic on others prefering different aesthetic, or workflows.
The broken perl/C based mailing list managers and the hostility of these communities turned lots of people away.
The rejection of HTML mail (even if it had technical issues, which could have been addressed with dialogue instead of outright rejection, thus staying away from the discussion) led to many people instead using richer web based forums for discussions, eventually leading to the complete halt of (open source) innovation in email-space.
Microsoft did innovations in email, to meet user needs. The way they did it was part of their EEE strategy. Google also did do innovation Gmail/Groups, but those eventually became parts of its own EEE strategy.
Opensource meanwhile kept yelling: 72 column line wrap! Plain Text! No need for images! No need for structured content! Meanwhile people doing a bit more cross-disciplinary work then Unix administration/C coding saw place for these usecases. Email decays because it failed to leave the milieu it was born in.
I’m personally very angry at these people, because this form of communication is dying for the sake of low-effort instant gimmicky social-media communication forms, largely because their total inflexibility.
No, the biggest is the “Subject” field. Organizing discussion in topics as opposed to around correspondents, is a strong signal encouraging people to actually organize their thoughts before sending anything. This is already a too high barrier for entry for too many.
Therein lies the rub. I expect many more would be comfortable using email for discussions if they can whack reply, type in their HTML-formatted reply as a top-post, embed their inline image and go merrily on their way. This is exactly the same workflow people use when they email groups of people directly. There is nothing to change or learn.
The concept of a Mailing List comes with a tonne of ascetic and technocratic baggage that is never going to resonate with the Slack-and-Discord crowd. Users make their choices accordingly.
Email definitely has issues, but it + IRC over Slack/etc any day.
What I would like is a federated group chat with client applications supporting multiple server accounts simultaneously. It would have rooms for multi-user-chat and explicit topics within the rooms (no default topic or interleaving the topics). Something close to what Zulip does (except it interleaves by default, which sucks).
It’s somewhere between sync and async. You can easily catch up if you don’t follow just in time and can skip across topics without finishing reading them. Nowadays I try to direct everyone (at work) away from email towards Zulip, because it saves me a lot of time.
Email is the best discussion platform for delta chat.
Yes - https://delta.chat/ - https://www.coi-dev.org/
I. Hate. Email.
Seriously, no one knows how to use email and no one uses it correctly. Email has been ruined long time ago by signatures, quotes, CC’s and general clutter to the point where you need email processor to be able to follow any sort of long or multi-user discussions.
Can we restart email with strict rules?
Cheers, Johny <body> Johny Johnson - Founder of Company™ <img>
What email platforms can you use to host discussions so everyone can see