Hacker News Reader

Comment by chrismorgan | Hacker News Reader

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.

View on HN

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.

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'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.

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

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

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

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