End-to-end encryption, large attachments, managing group messages (aka "reply all" problem), changing message subject, quoted messages when replying, HTML/CSS formatting, sorting/labeling/folders, tracking protections, sending messages over websocket, heck even basic message threading. None of this works consistently across different clients.
That is the problem. The protocol doesn't dictate how prior messages in a thread should be included or referenced. So any given thread is a hodgepodge of different solutions, making for an ugly, unreadable mess. Some clients try to clean this up, but it's basically an impossible task when you have no way of knowing what other clients will do.
Yes we should, but people have been trying for 20 years and it hasn't happened yet. The wheel has been successfully reinvented already.
The biggest reason for it is that in practice email isn't as open and decentralized as people like to think. For most of its history all advancements were controlled by Microsoft, AOL and Yahoo, and today it is controlled by Microsoft and Google.
I don’t understand how your client can solve for someone else sending you top-quoted replies, or word-html-engine compatible HTML designed to work in outlook. Or eighty other people hitting reply all on the email chain you’re on. The clients other people use can behave completely differently, because the protocol leaves so many decisions up to clients.
You're adding things not in the OP list I was responding to so I didn't claim that. But let's try:
Reformatting top-quoted replies. This is possible with email because you can pipe the messages through any preprocessing you want. Inserting custom processing into the delivery pipeline is generally impossible with all proprietary systems, but easy with an open standard like email.
HTML formatting: Again, easy due to customizable preprocessing and/or viewers.
Eighty people responding to a thread: This is threading, handled natively by most good email clients. Gmail makes a mess of it though, so I get why it'd be painful if you use gmail. Don't use gmail.
> because the protocol leaves so many decisions up to clients.
I feel like this is a misunderstanding. The clients have nothing to do with the protocol (SMTP), that's the job of the MTAs (mail transport agents).
The client provides the UI/UX interaction part. It is an immense strength of standards like email that there are tons of clients. You may want a completely different UX with your email than me, so you're free to have it exactly the way you want and so am I. And we can still message each other. This is impossible with proprietary walled gardens.
Client support for the features you’re talking about has everything to do with the protocol. How are you threading if not based on SMTP headers? What SMTP headers are meaningful for threading? What does SMTP have to say on the subject? Nothing - because it only talks about MTA behavior not clients.
Slack threads are the worst possible UI ever, so that's not something to aspire to.
Email threading is trivial, nothing magical about it. Most every decent email client will properly thread conversations. Gmail will not, so yes gmail is super painful for long threads. Use a better client.
Isn't the "reply all" problem a user issue? If people used BCC instead of a bunch of To's, we'd never hear about it. Heck, I would think email clients would prompt if you tried to sent more than a dozen people without BCC.
I agree with everything else and think "managing group messages" has other issues. For example, it's nice that I can duck out of an iMessage group, but can't duck out of a text message group or email chain.
