Hacker News Reader

Comment by ocdtrekkie | Hacker News Reader

Bron, I am so happy to see a blog from you guys about this... I was actually planning to ask.

In the light of Google being a monopoly-scale actor, I understand that you may need to support AMP. But if I might offer a note of implementation suggestion, if you add AMP: Make sure AMP, like remote images, is off by default. Perhaps allow the user to whitelist certain services or addresses to show AMP content without the extra click. That way, if AMP provides me a benefit in the way I use emails from a particular provider, I can turn that on... but my email client is never assuming I want to load their dynamic content.

I can see interesting use cases, as someone who pipes all my notifications at my email. I'd love to Favorite and Retweet right from my Twitter notifications, for example, without leaving FastMail. But I definitely don't ever want dynamic content loading from the latest marketing email from a store I've bought stuff from.

View on HN

We definitely would do something like that with address-book whitelisting or other controls! I expect everybody will. Remote content, even via a proxy, can still identify exactly who has opened the email (also when, unless content is cached - but the whole point with content that might change is that you can't cache the resources and still be dynamic)

It's also going to mess pretty badly with offline mode when we get to that, unless we pre-fetch resources when downloading data for offline.

Can you freeze or un-AMP emails? Have your servers pre-download stuff or even strip it (somewhat akin to a browser's reader mode)?

text/x-amp-html is intended as an optional enhancement over an email that other clients will still be able to cope with. So un-AMP-ing is mostly just called using the text/html part instead of the text/x-amp-html part.

Pre-downloading or proxying content is theoretically quite possible with AMP (its limitations make that possible where it would not be readily possible with freeform JavaScript), but some modes of doing so will probably play hob with its interaction models. But it’s too early to reasonably review that aspect of it—better to wait until we can see what people actually do with AMP.

Make no mistake: AMP is all about making emails applications instead of static messages. That is its raison d’être.

Wasn’t text/html intended as an optional enhancement too? But most of the emails I receive are only text/html - no text/plain alternative, which would be displayed if available.

I fully expect text/x-amp-html only emails in the future, and so should you.

FastMail, please give me a way to permanently block AMP only emails. Just throw them away with a Mailer Demon reply. If there’s other versions, strip away the AMP version.

"most" (of the mail you want to read/reply to) sounds a bit extreme - afaik both Google and outlook/exchange/office365 will supply a semblance of a text part unless you go out of your way to avoid it. As we as most real mail clients.

You could always just bounce mail w/o a sensible text part...

>bounce mail w/o a sensible text part

Hmm... I’d like to, but I’m not sure how I’d do that on FastMail.

Eventually I may host my own emails, but until that day, I can’t really do much about this problem.

Maybe I could have an IMAP client on a server that is constantly connected to FastMail and looks at incoming emails to file them into an “HTML only” mailbox if they don’t contain a text/plain version?

I can read those emails from the FastMail Web Interface

I've not used sieve, but afaik fastmail supports sieve, and according to this: https://tools.ietf.org/html/rfc5173

It might be possible to match on non-empty text/plain?

> But most of the emails I receive are only text/html - no text/plain alternative

Care to elaborate on that? Virtually every email I get has a plain text version (I can't even see HTML email). I don't think the email I get is particularly selective. The only pure HTML email that I ever get is spam.

Sorry for the delay in replying, I don’t check my comments very frequently. Usually only in the morning.

I use mutt for emails, so believe me — I know when I get a text/html only email as mutt can’t display the text/plain version. Most emails I get from friends and so on are in text/plain as mail clients do a decent enough job at including that.

However most of my mail isn’t from people I know, it’s from newsletters and notifications. A lot of it is text/html only, either because the programmer who created and sent that email didn’t want (or know) to include a text/plain version, or didn’t care to.

Why does it matter if email content changes, if that's the intention the author?

Clearly one of the biggest benefits of email is that it's the only medium that's acceptable for memorializing agreements / decisions / roadmaps / plans / etc. At the same time, I don't really care if some clothing company's monthly marketing email changes if they run out of something, as long as it's clearly marked as ephemeral.

"as long as it's clearly marked as ephemeral" - yep, you hit the nail on the head there. The ecosystem danger is that ephemeral becomes the default. Who doesn't love the ability to silently fix mistakes.

And when it becomes the cultural norm to send editable email, then people will do it because it's a nice experience as a sender if you have the choice. I sure enjoy being able to edit my posts on HN when I get something wrong. I'd love to be able to take back and "fix" emails that I've sent too!

But having to stand by exactly what you sent when it comes to email is really a valuable part of how email works. If you made a mistake, you send a correction, but the recipient still has your original mistake too. They don't see it, then have it disappear when they go back to look at it again.

I, for one, cannot wait until someone is able to alter a few words to a contract I've signed after I've signed it.

FWIW, this is effectively what tech companies already do with the Terms of Service. They state that you must agree to them to use their product, and then state that they can amend them at any time, often without notifying you.

Had that happen to me. I'd "electronically signed" a PDF of a contract, and returned it to the other party with some minor questions.

The other party marked up the PDF I had signed with some changes, based on my questions. All of the changes were agreeable to me (or not worth fighting about, I can't recall). But I still insisted we start with the changes made to an unsigned PDF, and then I signed that PDF with the changes.

My thought was that socially/culturally green-lighting "after signature" contract changes was a path to madness and misunderstanding.

AMPHTML Email is designed to sit beside the text/plain and text/html parts as just another alternative, with type text/x-amp-html. So in theory, any senders of AMPHTML Email should also include a regular HTML part that is semantically equivalent, and any client that doesn’t support text/x-amp-html should simply get the less fancy version.

In practice, if something gets popular enough then the alternative that is supposed to work properly side-by-side gets neglected. (Some email senders cop out on text/plain these days, leaving it out, or worse, empty, as in Dropbox Paper’s document update notifications.)

But I don’t think AMPHTML Email is likely to be sufficiently broadly supported that this becomes a problem. (It’s only likely to happen at all if all the major providers and major email clients support it.) If at any point we do end up supporting AMPHTML Email, any remote content will be handled like remote images.

Yes, this might become an embrace, extend, extinguish like scenario, which is scary.

Google did the same thing with XMPP and Google Talk. They adopted an open standard when it was cool for them. When they gained mass adoption, they switched to Hangouts and the whole Allo mess. And before that they crippled XMPP federation.

While I don't like regulations too much, it might be desirable to penalize these behaviors as they are monopolistic.

Google Talk never gained mass adoption. Google was punished by their competitors by adopting open standards, like XMPP and OpenID, when some competitors implemented "one way" interoperabilility to siphon off users.

I favor federated open standards, but let's not rewrite history. Google Talk was never mass adopted or a market leader, MSN, Yahoo Messenger, AOL Messenger always had way more market share.

I mean, good lord, you're calling for regulations to penalize Google over failed messaging products, why don't you call on regulations to force Apple and Facebook who own the world's most popular messaging platforms, to open up their protocols to federation?

If you want to propose legislation to require Apple and Facebook to allow interoperability, I will get it in front of federal legislators.

I've been pondering this for a while. The standard thinking is if everyone federated (e.g. XMPP in Facebook, Gmail) it would be good. But look at it from another perspective. Then your main account, your identity would be permanently tied to one provider (Facebook, Google) as your JID would end with @facebook.com.

The only true solution is to use your own domain and then, if possible, delegate to hosted server. If the provider does something that you don't like you just change provider or host your own. And one's @gmail.com address will always be hosted by Google.

how exactly does one siphon users by implementing one-way federation in XMPP?

The same way iMessage siphons from SMS. You embrace-and-extend, crafting a proprietary protocol closed service with a bridge to an open one. You gain users by allowing people to inter operate with friends outside your proprietary service: normally a "cost" and impediment to your users, all the while creating incentives to onboard their friends. Once they're onboarded, they become locked in, and gradually you can reduce interoperability with the federation.

Well, I would say that applies to open protocols themselves, like SMS and XMPP - in fact Google did it also. But when two service providers interoperate and build more features to entice users to move to their platform, I would call it fair competition not siphoning; there is no "one way" aspect, you either federate or not.

What I want to say is that killing XMPP federation was a deliberate stab against a competitive market, not some reasonable defense against being taken advantage of, it's exactly the final "reduce interoperability" step you talk about. Unless competition regulators disagree, it's fair game for Google, but the consumers certainly stand to lose.

I get marketing emails all the time where the HTML part carries the message and the text/plain part... is last month's message. Or last year's. Or lorem ipsum.

I used to tell companies about this problem, but it turns out that of the thirty or so I contacted, only one was interested in fixing it. Now I just mark them as clueless.

I get emails where the text/html part is fully fleshed out, and then the text/plain part is just the string, "Can't see the formatting? Click here!" where the last two words presumably lead to an HTTP served version of the email text.

Hey, I can see the formatting. I just choose not to. If you, on the other hand, can't even attempt say what you want to say with plain text, it's probably not something I care about anyway...

Ah, this explains why that text is so often the preview in Gmail. I always wondered why I couldn't see that text in the mail itself.

The more time spent on optimizing for one email client, the less time spent on optimizing for an other.

Hands up if you (like me) have skipped coding the text/plain part of an email template and sent out multipart emails with no or empty text/plain.

Developers are lazy, but business minded people will push amphtml because they think it's an edge. If it becomes a thing, people will create webpages instead of emails and skip proper testing. (Again, myself probably included).

We've done the opposite. After ten years in operation we've only just begun to add html parts to our emails. Its just easier to render plain text, and no one has the time to be spending hours templating and testing emails, we've got better things to do.

And the really amusing aspect of that is that text-focused emails (be they text/plain or deliberately simple and barely styled text/html) tend to get better engagement than fancy branded emails—the data I’ve seen from a variety of sources is quite conclusive about that.

I wish more people published data about it.

I like everything about plain text emails except for hard wrapping, which looks awful on screens that are too small or too wide.

To a large extent, hard wrapping is a combination of choices made by the sender (to hard wrap the text, because it doesn’t trust clients to soft-wrap properly) and receiver (to soft-wrap or not).

There was a standard to handle it nicely, format=flowed; sadly, it didn’t make it: https://blog.fastmail.com/2016/12/17/format-flowed/

But even without that, the quoted-printable content-transfer-encoding means that the hard wrapping isn’t actually necessary—you can have lines as long as you like. Some email clients do thereby send text/plain with arbitrarily long lines, which will cause overflow in some clients (typically where plain text is shown in a monospace font), and be wrapped in others (most, these days, I think; these are typically where plain text is shown in a proportional font).

Then too, some email clients ignore the 78 character limit (it is, after all, only a SHOULD [1]) and write longer lines in the MIME message. (Not sure what they do after 998, which the spec says they MUST not exceed [1].)

But the inability to specify the desired semantics of proportional-with-wrapping versus monospace is probably the part of text/plain email that makes me saddest.

[1]: https://tools.ietf.org/html/rfc5322#section-2.1.1

I co-founded a business, specifically around email testing, largely for the reason you mentioned. When developing we often skipped things like plain text, and usually only did a cursory glance over other aspects, very much less did we automate anything. It came back to bite us so many times (presumably countless times that we weren't alerted too also).

Obviously I'm entirely biased, but to your point on business-minds pushing for edge I'm even more convinced that manual testing alone is never going to cut it going forward.

Shameless plug at the bottom as it's rare that email testing gets limelight on HN :) https://mailosaur.com

HTML email is supposed to be just another part alongside plain text as well. Anybody who uses a plain-text email client knows that nowhere near 100% of HTML emails are sent with a sane plaintext part. A fair portion of the time, there just is no plaintext part, other times there claims to be but it is just the HTML source stuffed into it. I've even seen some marketing mails (Delimiter promotional emails are the ones I'm thinking of, but there are others) where the plaintext part is just a completely different older message, apparently because they forgot to update that part before sending it out.

Now, I know plaintext users are in the majority, but I don't think you can reasonably expect the same not to happen to AMP for emails if they ever become widespread.

Reply on news.ycombinator.com