AMP and why emails are not (and should never be) interactive | Hacker News Reader

AMP and why emails are not (and should never be) interactive

buttondown.com

222 pointsmaguay165 comments

To me the most important objection is that an email is a record of something, and needs to be self-contained and immutable for that reason.

When I get an email, I want to know that I can always come back to that exact email for reference, and that there's no way that it can have changed, or that the important information is externally referenced (and therefore also subject to change).

I think this is one important reason that more and more emails are just links to some website with the information on it (often with a login required as well). It allows the company sending you the email to retain control of that information. If you email me a text or PDF invoice, I can always come back to it for my own reference. If you send me a link to one, there's no guarantee I can still access it later.

> I think this is one important reason that more and more emails are just links to some website with the information on it (often with a login required as well).

I hate this with all of my being. It's awful. Send me an email that tries to tell me how important the information is without actually giving me the information... and I won't read it, fuck you. You don't get to decide which information I find important.

I agree wholeheartedly -- it's like getting a postcard saying "You have an important message from your doctor, go visit the doctor's office to find out what."

I respect that some of this is ass-covering because of overreaching regulation (or in many cases probably overly-conservative readings of the vague regulations) especially with respect to HIPAA and Euro-style "Privacy" legislation, but personally I'd prefer to opt-out of all types of nanny-ism trying to 'protect my privacy' by sending me content-free email with links, that then require that I 'click to view' and then, 90% of the time now, return to my fucking email to retrieve a stupid code.

My doctor does it ("you have one new notification, log into our system to see it"), financial systems do it ("something something happened on your credit report, log into our system to see it"), legal systems do it ("you have something something communication, log in to download it"), etc. It's utterly infuriating.

Some of these places are between a rock and a hard place. HIPAA or other rules may prevent a doctor from using email to send you personal medical information such as test results. For any of them, email isn't "secure" and they don't want to be accused of "leaking" personal or confidential information.

GPG exists, but it's been a non-starter for the average user the entire time, so no reason to expect that it will suddenly become workable now.

Ironic, because it's assumed your email is insecure and visible to more than just you, but it's used as a password reset and/or 2FA mechanism for almost everything.

It would be nice if sites had a checkbox that allowed you to affirm that your email is secure and private, so then detailed emails were sent.

There's no way to guarantee that. SMTP is not a secure protocol. Your message could be read by any intermediary along its delivery route.

It is possible to deliver emails IFF the receiving server presents a valid TLS connection and cert. I don't think I've seen anyone actually enforce that though.

Yes but the server itself has full visibility on the message while it is handling it. It can scan it for viruses, parse it for ad insertion, feed it to train an LLM, just keep a copy of everything, whatever.

yeah... that's why it's important to be able to trust your email provider... I assumed you meant anyone passing along the message, like a router, or rogue ISP. I was more going for the idea that you can make SMTP secure from sender domain to destination domain. If you don't trust your host, nothing else really matters, in all cases.

SMTP can use intermediate relays. TLS doesn't guard against the middlemen.

When I suggested using TLS, signed by a trusted cert authority; and you're imagining some system, where a message sender connects to some 3rd party middleware box to relay the message, and this middleware box has a cert for the destination domain?

I recognize that that is part of the protocol's design, but how common is that in practice on the modern Internet? If I'm using say, Outlook, or even some personal home server, and I have mail for example @ gmail.com, I would expect two things:

1. Microsoft, or my server, would look up the MX for gmail and send the email directly there, where I'd presume it's safe from maliciousness (obviously Google itself has access to it, I admit)

2. The only server that would accept mail from my server and relay it for me would be someone I'm paying, and they probably would accept it over TLS right?

> HIPAA or other rules

Sure, sure, rules, yeah.

But there are plenty of reasons that are as numerous as reasons to build a walled garden.

If they’re storing your records, then they control the audit trail. They detect every time you, or someone, visited that site, logged in, viewed pages, downloaded or viewed a document, changed settings, updated profile, added contact info, deleted contact info.

They control the expiration and retention periods. They control the file formats. They control the uptime and the downtime. They control the horizontal and the vertical. Oh wait, that’s on T.V.

There will be increasing gauntlets to run and obstacles and hurdles to the consumer getting our hands on documents and information. Until we really need that proprietary online viewer to open the file at all. Or at least their mobile app. Or you could pay fees for records access. It costs them to store it all, does it not?

Absolutely those things are all valid concerns. But even if they are not doing those things, email is problematic for delivering confidential information.

If physical post is acceptable for such things, i see no reason why email cannot be held to the same level.

Often the postal mail is required by regulations, such as when your bank sends a notice or disclosure, or some creditor sends you a bill, or a government agency sends something in the mail. Whether or not you’ve gone “paperless” matters not, when they are legally required to send a paper letter. And it drives me crazy, because it never fails that the most important and most informative letters are not even backed-up by an electronic copy, and so these days, the onus is on me to scan the letter into Google Drive or OneDrive, and I've been using my smartphone to do it, one page at a time. And that's the only way I can keep a searchable, accessible record of the most important communications, by scanning them back in from the paper.

But here's what the email situation looks like, with a USPS analogy: you receive a letter from the tax office that says they have a message for you. And the letter has arrived at 5:30 p.m. on a Friday evening.

So on Monday, you get your ID and you drive down to the tax office. Except you can't immediately drive, because you don't own a car, so you walk to the library to borrow a car. The library says that you can borrow a car, but they need another household bill that you didn't bring with you. So you walk back home, and you get the documentation the library needs, and you walk back to the library, and you borrow a 1995 car, and you drive to the tax office, and the tax office says that the message for you says that they need a check from your bank.

So you go home, because it was already late in the day. And then you walk back to the library, and you borrow another car, and it’s a different car, so you learn how to use this car, and you drive to the bank. And you ask the bank for a check. And the bank needs additional ID, so you go home, and you gather all the ID that the bank needs, and then you drive back to the bank, and you ask them for a check again, and then the teller says that they can give you a check, but the checks are issued in a different branch. So they give you a voucher token for your money, and then you have to go drive to the other bank branch across town to get your money.

So you arrive at the bank branch that has the money, and after 15 days you have the correct ID and all the documentation and you also have the voucher and the token to take the money out and get the check. So you obtain the check, and then you take it home and return your library car, because it's late in the day.

And then you wait over the weekend, because it was a holiday weekend. And then you gather your ID again and you put your tax check in your pocket, and you go walk back to the library, and you borrow a third car, and then you drive to the tax office, and then you try to show them your check. And the responsible person at the tax office isn't there because they're a short staffed. And there's a sign on the door that says to go drive downtown to the main tax office, and that's where you’ll be able to drop off your check.

So you arrive at the main tax office, and there's a queue 2 hours long, and there's a security guard who pretends not to recognize your ID. And you get in a rigmarole with the security guard for a while, and a second security guard comes along and they have a nice extended discussion over whether your ID is from a Cracker Jack box.

And so eventually they escort you to a disused lavatory in the sub basement and it's got a sign that says “beware the leopard”, and the bureaucratic functionary at the desk accepts your check, and then you go outside to the downtown parking lot that cost $12, and your car has broken down because it was a library car and library cars are always the most unreliable ones.

So this is what it's like online, using email and online cloud services to retrieve documents because “email is insecure”.

It could also be that they want to know when some communication has been received (by the real person, not the email server) and that's not possible with email. I still maintain that I hate that practice because I just don't want anyone to have that information, I want to be invisible.

I would happily go into my bank or medical provider and upload my pgp public key for them to encrypt emails with…

Email is an incredibly important communication database and I expect my important communications to be there and be searchable.

I believe this is exactly correct. Email is a 'paper trail' and being able to change that paper trail ex-post facto benefits the sender waaaaaaaaaaay more than it does the receiver. I met an engineer from Google who quit when they insisted on "dogfooding" this.

They used the example, you send an email that says lets meet for dinner tonight at 6. You arrive and after 30 minutes begin to wonder, go back to your email and now it says meet "tommorow night" at 6. Are you crazy? Did you misremember? Or did the sender change the email after they sent it and you read it? How could you complain?

As I understand it, it was met internally with "that isn't what we mean." But the ability to send HR important announcements and then change them after the fact is a capability that is just too tempting for HR to resist at some point.

> They used the example, you send an email that says lets meet for dinner tonight at 6. You arrive and after 30 minutes begin to wonder, go back to your email and now it says meet "tommorow night" at 6. Are you crazy? Did you misremember? Or did the sender change the email after they sent it and you read it? How could you complain?

This is a calendar invite. And this is a completely valid use case, but it's useless if I don't have an edit log. It's crazy how many people miss that last part.

In current email you get ANOTHER email that says the invite has been updated. While it changes "automagically" on your Calendar. That second email is critical.

when i was forced (thankfully, briefly) to use outlook (web version), one of the big surprises was that rsvp'ing on the invite deleted the message.

several times i came looking for that invite and felt gaslighted not to have it in my inbox.

That's just a setting, turned on by default annoyingly

It's probably going to be even worse than that - HR (and everyone else) will probably then have to implement process and procedure and storage mechanisms to prove that emails have not been changed. This might mean storing emails in a document control system. Email is bad enough but now we're all going to have to keep a mirror in SharePoint or something like that.

i do this with email from my financial institutions that i care about. i login to their “secure messaging “ portal and grab pdf export of the web page.

Absoutely agree,

Gmail started scraping all emails a decade ago. Amazon responded by removing all product and pricedetails from Order confirmation and Order shipping emails. We consumers lost out -- we dont have our own copy and archive of what we ordered. If Amazon links perish to link rot and we lose access to Amazon login, our past order and spend information is gone.

When reconciling my budget (with YNAB) I often use gmail as my way to connect items to transactions [0]. I've found that I can just search for the amount that my card was charged in my email and find the Amazon email that relates to that order. Then, normally from the body, there is just barely enough information for me to know what I bought.

That got annoying enough that I just wrote a chrome extension to scrape Amazon orders/transactions and auto-match and update my YNAB memo line with a summary of the items.

That's a bit of a tangent just to say: yes, they nerfed their emails but not completely.

[0] Yes, YNAB recommends that you enter transactions right as you make them, but that's not how I use it.

Amazon has a "Transactions" tab in the payments section of your account that makes this easier (YNAB user here)

FWIW, as far as I'm aware, it wasn't gmail scraping that was the cause of Amazon pulling that information. It was third-party plugins that read people's inboxes to provide them with coupons, discounts, etc., and those companies would sometimes sell the pricing data. I assume Amazon wasn't thrilled about that, but there wasn't anything they (or gmail) could do about it as long as the user was granting them access to their inbox.

But also - I just ordered something off of amazon and I noticed that the confirmation had the item that I ordered in it, albeit in a shortened/summarized way? So maybe they brought it back, figuring that with just part of the name, there's not much someone can do with the pricing information? Or maybe they just don't care anymore?

(disclosure: I work at google, but not on this, but worked adjacent to the gmail team for a few years and am going off of my memory. I'll also tap the sign that Google doesn't mine your gmail for ads, for both consumer AND paying customers).

Shopify in particular launched an app with the option of scraping your inbox.

Gmail has always scraped emails. That was in the TOS from day one. Your data was the price for the free service.

They stopped doing that in 2017.

> more and more emails are just links to some website with the information on it (often with a login required as well)

And a 2FA SMS sent to your phone.

> If you email me a text or PDF invoice, I can always come back to it for my own reference. If you send me a link to one, there's no guarantee I can still access it later.

Download it. It sucks having to do that and maintaining your own archive instead of trusting your mailbox, but I guess there's some advantages to that as well.

Sure, I can download it if they send it as an attachment. Not so easy when it's an external reference. I guess I could login to the website and download... the web page? Well anyway I'm not going to.

> immutable

I swear years ago I had a mail client where you could type into a received message and alter it. Maybe sun mail or early apple mail?

they finally made the message pane immutable.

I remember AOL email to AOL email had an "unsend" feature for a while.

Does anyone remember PlutoMail[1], the client that let you send self destructing and editable emails?

[1]: https://techcrunch.com/2014/06/18/pluto-mail/

> I think this is one important reason that more and more emails are just links to some website with the information on it (often with a login required as well).

That's an unfortunate requirement these days.

For one, in Europe concerns around GDPR: e-mail is not guaranteed (!) to be encrypted or protected against modification in transit so it might get snooped up on its way, which makes it a no-go for sensitive stuff such as healthcare information or other highly protected classes of PII, unless PDF encryption or other ways of encryption are used... but these have the issue that UX around many of them is horrible. A link to a portal however? Easy, and provides automatically the guarantee that the other person is who they claim to be.

The second problem is deliverability: more than enough email providers still have laughably low limits (sometimes < 3MB), virus scanners don't like PDFs or ZIPs that they can't read (because they don't know the password, obviously), and on top of that come the usual anti-spam concerns.

IMHO, the best way to go would be an extra header field, think like "X-External-Attachments: https://foo.com/<uuid>.pdf <hash-alg> <hash-value>"... this could be used by MUAs to prompt the user if they wish to download and store the file, provide cryptographic checks of the file, and sidestep the issue of dumbass middleboxes yeeting password-protected files, as the files can be scanned on the endpoint side.

I hate these EU requirements. They do nothing to help real users, and really make everything worse. Like, is it helpful that every single website now has an added banner that we have to click, but which still nobody reads and doesn't really help anything? All to avoid cookies, which are not really the source of the problem these laws were meant to address? ARRRGHHH!

As far as the file size - does that critically important message need to be embedded in a 10MB PDF? Maybe we should go back to 50k limits and force them to put that one-liner in plain text in the email. ARRRGHHH!

And get off my lawn! ARRRGHHH

I think so.

I click on “reject all”, and at worst “manage settings” and disable a bunch of stuff.

I didn’t have that option before.

The second problem is deliverability: more than enough email providers still have laughably low limits (sometimes < 3MB)

What are you sending that 3MB for an email is "low"? The Bible is a little over 4MB of plain text.

> What are you sending that 3MB for an email is "low"?

A single picture from a somewhat decent camera can easily be >> 3 MB in size and yet there's a lot of providers that yank everything above that limit.

But with remotely loaded img tags (automated emails don’t send images as static base64) that email is far from an immutable paper trail like how a PDF is.

I agree, the ship sailed a long time ago. I have been archiving my emails since the 90s. Sometime around 2010 all the remotely loading emails came along, and since then I've several times gone back to look at an invite or announcement and find nothing but an html tag. I guess an archiver that would need print all my emails to a pdf or image file to preserve it, like the emails that show up in litigation. The tools I was using, gmvault or google's takeout, aren't made for this path we're on.

I'm commenting on this way way too late for anybody to read it except for jasonfarnon, but:

Doesn't gmail prefetch / proxy img srcs, in order to not give away tracking/open information to the sender? Or is that something they did a while back but then turned off... Anyway, it would be so lovely when you do a takeout of your gmail data, if they could give you both the original and also a version that had the src rewritten to either a base64-encoded copy of the image or a local file that's included in the takeout dump.

Yeah that would be cleaner than print to PDF. Basically a simplified version of the "Save webpage (complete)" option in modern browsers. As to the state of email tracking I'm not sure where that stands now, either.

Yes, of course, and that's why it's best not to put the important information into and image. Of course, many senders do this anyway, but at least it requires them to send me an image. No different really than sending me a link to the important information as I mentioned in my post.

But let's not make this even easier or default please. It's bad enough as-is.

A nice improvement would be for prominent clients like gmail to default to NOT display images. This would force bulk-senders (including legitimate ones) to stop putting the important info in images most of the time.

Ditto with links - maybe the clients should stop making them clickable, forcing the user to copy-paste the link. Not sure about this one...

There's been a recent trend to add animated gifs into email, where the gif is a never ending stream. It's often a timer/countdown to the end of a sale or something.

This would be so that even if the server remotely fetched the gif, it would never end, and thus either consume the available resources on the server, or they give up.

While I agree with this article's conclusion, I think it conflates political/market objections to AMP (i.e. abuse of monopoly power) with technical concerns.

For a time, I tech-led the creation of the AMP site for a major news publisher. The technical choices of AMP, excluding the CDN-aspect, are I think a great fit for publishing websites with tens-hundreds of developers who are all tempted to write bespoke JS and in so doing create performance and maintenance hell. In many respects, philosophically, I think AMP was not far of HTMX. In AMP, developers are able to construct relatively sophisticated dynamic/interactive features using simple markup (and pre-built JS components). The page is managed through a single JS runtime which helps manage performance issues. As components have a standard HTML interface, it is possible to migrate the backend to different rendering technologies partially over time unlike (for example), isomorphic JS which forces a large-scale rewrite down the line.

I tried to advocate for an in-house AMP-like solution for our main website, but it was ultimately re-written in React -- a process which took several years and resulted in a codebase of much greater complexity. (Performance was better than the old website but I'm not sure React really contributed to the gains here.)

While AMP is rightly dead, I think the technical choices it made live on (or at least, they should).

AMP seemed like a great technology that ended up being used for user-hostile purposes.

If you swap out AMP for ${generic_tech} this statement seems to describe the latest 15 years of software development.

It was never user-hostile. It was definitely publisher hostile but that isn't the same thing.

Of course it was user-hostile. I can't tell you how many times I would get linked to an AMP version of a page on desktop, with text spanning the entire width of the screen, and no way to get back to the 'normal' version.

Perhaps I'm just being dense, but I really don't see the point of AMP. If you want to build a non-bloated website, you don't need special branding from Google to do so, you just need to care about the quality of your work. Websites like HackerNews, SourceHut, and Pinboard, are living proof.

The Wikipedia article does a very poor job, in my opinion, of explaining what AMP even is. [0] It emphasises use of CDN caching to improve performance, but this can be done for any static website. What does AMP contribute? Where's the innovation?

[0] https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages

AMP is a set of rules for people who are unable to stop themselves from making bad decisions. It has nothing to do with technical superiority. AMP is a deal under which, if an adopter stops acting like a jackass, they receive better search ranking. There is nothing that stops you from creating an AMP-like experience if you are naturally not a jackass.

> AMP is a deal under which, if an adopter stops acting like a jackass, they receive better search ranking.

You mean, jackassery like, not running ads from Google's ad platform(s)?

AMP has no relationship to Google Ads, does not require Google Ads, and does not require using Google's CDN. There are dozens of ad networks that support(ed) AMP.

Google Ads has integrations for AMP. AMP does not require Google Ads.

Perhaps not directly, but from the article:

> AMP required allowing any AMP CDN to cache your pages. Visitors might be served your page from a Google domain instead of your own, or the ad tech and other scripts on your site might be incapable of running on your AMP site (handily, it seemed, for Google, who might prefer you to use their ad tech instead).

Part of that statement is correct, part of it is misleading.

> AMP required allowing any AMP CDN to cache your pages.

Sort of correct: this is true if and only if you wanted the rank boost for Google search. If you just wanted to serve AMP and have snappy page, not entirely correct.

> other scripts on your site might be incapable of running on your AMP site

Correct, because that's the entire point of AMP. It is a straightjacket intended to make it technically impossible for your "other scripts" to run, because actual users hate your "other scripts" and they make users' phones overheat etc.

Exactly this. AMP was not a technological concern so much as a "contract": I won't act like a jackass and do anti-user things on my site and you will convey that to your readers/searchers.

Doesn't seem to prevent AMP sites promoted on Android/Google/Gemini assistant from using dick moves like hijacking the back button to prevent you from leaving. I can't fathom why Google doesn't drop the hammer on that behavior.

It wasn't innovative or intended to be, it was a solution to a collective action problem. It's easy to make the case for "we have to do it this way to avoid being penalized in search rankings".

Doesn't Google already penalise websites for poor performance though? Why not just intensify that penalty, rather than develop and promote a new framework intended to forcibly prohibit bloat?

Sure but people won't always respond to incentives. It's like asking why AA exists when the cops will already throw you in jail for being drunk in public.

Google will rank results partially based on page performance and behavior. It is possible to improve your ranking by improving page experience. AMP is the complement: a tech stack that makes it impossible to not do those things.

When nearly every site has horrible performance IDK if it would make a difference to intensify those penalties, as they'd apply about equally for instance to every news site, every blog, every e-commerce site, etc.

But that's the same with AMP. If every site doesn't have AMP, penalizing them for not having AMP changes nothing.

In both cases it's an unstable equilibrium. The first site to be fast will get all the clicks. Or the first site to use AMP.

That was the replacement mechanism after AMP, yes

With AMP, Google could preload and pre-render sites, so things like swiping through a carousel between search results was instant.

That’s not possible without building an AMP page since it requires being able to safely serve off of google’s domain.

Thanks, that sounds like a neat feature. Regrettable than neither the Wikipedia summary, nor the Google Search AI overview, nor Google's own official summary page for AMP, [0] make this clear.

[0] https://developers.google.com/amp

The innovation is that the page can be prerendered from cache without any privacy or analytics concerns. AMP is an open standard replacement for Facebook Instant Articles and Apple News Format.

https://en.wikipedia.org/wiki/Facebook_Instant_Articles

https://developer.apple.com/documentation/applenewsformat

Prerendering was old-school back then, too.

Edge caching might not have been as prevalent but was hardly new technology.

> without any privacy or analytics concerns

Uhm, yeah, no. Less bloated JS usually means less concerns but privacy violations and tracking of visitors can very much happen on AMP. Some of that risk isn't removed, just shifted.

> Uhm, yeah, no. Less bloated JS usually means less concerns but privacy violations and tracking of visitors can very much happen on AMP. Some of that risk isn't removed, just shifted.

Um, yeah, yes. The whole point of AMP (and competing proprietary formats like FBIA and ANF) is that the preloading happens from a cache owned by the link aggregator, so the publisher doesn't get your details just because its page was prerendered in the background. The link aggregator obviously already knows that you're browsing over the article link, so there is zero privacy loss.

With AMP, you basically get guard-rails to prevent your team of junior engineers from making your mobile pages too slow in exchange for increasing The Google's monopoly power. :D If I remember correctly, with AMP, you have to use their web components, and you have to pass their validator or pages won't be listed or cached at all. AMP is not really innovative in the slightest. One can easily serve pages faster than an average AMP page if they wanted to. The businesses that see engineering as a necessary evil are not properly incentivized to care about page performance, and are sometimes only prodded into doing so if a giant like The Google tells them to. Management tells their programmers that they read an article about AMP and that it makes pages load faster and reaches a wider search audience by caching and cutting out unnecessary crap; the more seasoned programmers think "Yeah, no shit – I've been trying to tell you... but I'll spend time rebuilding pages for AMP because I get paid the same either way."

> One can easily serve pages faster than an average AMP page if they wanted to

This is incorrect. You cannot beat prerendered. It does not make sense to implement AMP for people visiting your website directly. AMP is for link aggregators like search engines, news aggregators, and social media websites.

The point of AMP was to force publishers to build non-bloated websites, because they weren't doing it of their own free will.

AMP is dead

> ...it conflates political/market objections to AMP (i.e. abuse of monopoly power)...

It never occurred to me that AMP is an initialism for "Abuse of Monopoly Power". It's deliciously fitting.

It's "accelerated mobile pages" but I love the abuse version.

Well yes, obviously Google didn't actually name it for Abuse of Monopoly Power.

Not publicly, at least.

They've put some seriously dumb admissions in writing before.

https://www.techemails.com/p/sergey-brin-irate-call-from-ste...

They learned from this and now just have periodic arbitrary layoffs to depress salaries and keep the workers scared and in line in a deniable way instead of in an explicit way.

I like AMP conceptually, would make a good app platform for alot of types of websites and such.

I wish it was easier to fork, honestly. There's some good ideas within, though some questionable choices as well.

Unfortunately the project is rather opaque in a number of ways

How would forking work? The whole point of AMP is that a cache can validate that it is safe to prerender. If you added your own stuff, the caches would just reject it.

AMP is both a Javascript framework, and a wider page contract that facilitates CDN inclusion.

I believe the parent is referring to the Javascript framework, which itself has many nice properties for interactivity and performance.

Yea and I will say I don’t think it would be terribly hard replicate the benefits of the CDN on something like Cloudflare Workers

The point of AMP is that the link aggregator owns the cache, not the publisher. You would have to convince Google, Bing, and all the other link aggregators to use your implementation for their AMP caches. That's why it has a standards body. If you don't understand why, you don't understand the problem that AMP solves. https://news.ycombinator.com/item?id=43733809

Yeah, while I basically loathed AMP for all the control and monopolization issues, I do see what Google was trying to accomplish, at least at first.

Any front end dev has had to deal with the onslaught of asks from various marketing and sales teams: "Can you add this tag library?", "We need to integrate this affiliate broker!", etc. etc. And lots of devs would push back with stuff like "At this point we load 247 3rd party tags and JS libraries and it takes 53 seconds for our page to load, we have to stop this madness!" but the problem was that for any individual marketing team ask, the impact was small and of course that team had some KPIs to hit this quarter. It was basically a sort of Tragedy of the Commons situation.

So AMP came along and essentially gave front-end devs a technical reason why they couldn't add some shitty, slow, buggy affiliate broker JS library to the code base, so when marketing came with an ask, they could simply say "Sorry, not supported in AMP, and without AMP we get downranked in Google". AMP essentially became a technical hack to align short term incentives ("We need to add some marketing feature X!") with longer term goals of faster, lighter-weight pages.

Yep. I totally see why they did it. It’s a user focus, not developer focus. Users just want faster webpages. The end.

>without AMP we get downranked in Google

Whether a site used AMP did not affect ranking in Google.

Ranking is a closely held secret. Non AMP COULD have a negative impact. Let marketing try and get confirmation from Google that it does not.

You're either uninformed or splitting hairs about what "downranked" means. Google required AMP in order to be featured in the "Top Stories" carousel that was (unsurprisingly) at the top of the results page. Google ended this requirement in mid 2021, https://www.theregister.com/2021/06/28/google_amp_core_web_v...

I'm talking about search rankings and not what appears in the OneBox.

Doesn't really matter. Google directed clicks to the AMP sites in various ways, including the OneBox. Most sites which need ad revenue had no choice but to adopt AMP.

Why couldn't they just directly downrank pages based on their size or load time?

AMP is a misplaced principle, because it says “due to the constraints of mobile, web pages should be lightweight, not overdo it on interactivity, and load fast."

Instead they should have said, "Web pages should be lightweight not overdo it on interactivity, and load fast."

Email and SQL: two technologies that people keep saying are out of date and need replacing, but they keep rolling on whilst attempted replacements wither on the vine, with their dust eventually blowing away on the winds of time.

Meanwhile, many people don’t send personal emails anymore and people have switched to a variety of chat apps instead. And a lot of businesses use chat internally, such as Slack.

It’s mostly business use that’s keeping email alive, either business-to-consumer or business-to-business.

Yeah, this whole argument falls down when email is for junk mail, sending files, and password resets, and 6 digit codes. It's by every measure a failure by "product released after 2000" standards.

So frustrating when people complain about Google trying to save dying technologies like email and the web. I'm glad that email is working for you but over here in the real world I don't know anyone who still uses it.

remember google wave?

When AMP was about to be released, I was the engineer in my company in charge of deciding whether to implement it. I discarded the idea, but months later we realized Google was not joking about the SEO boost, and we had to backtrack very quickly in order to not lose to the competition. I regretted saying no because I missed the opportunity, but I was still convinced it was a bad idea overall.

Now that it's gone, I could not be happier. Not only did AMP made the internet worse, but it was a pain to implement, a bad experience for users, and a bad deal for media companies.

I was on the opposite side. When AMP4email came out, I worked at a publisher of email newsletters. I pushed our CTO to implement it. He was less than enthusiastic. We ultimately decided it wasn't worth the effort and now that looks like a smart idea.

AMP was a boon to all crap sites built by S Asian newspapers etc. even FT, guardian at some point had individual pages that were about 50x larger than it's AMP equivalent. Yes, for the rich AMP is monopoly etc. for poor like me - I prefer less data usage.

This is a weird thing to write about in 2025. AMP emails didn't really take off / get any kind of adoption did they. And HTML emails, annoying and problematic as they are have come a long way from the mess of client support and complete hack-job coding to where they are now thanks to standards and largely the popularity of web-based clients and the benefits those bring for email reading. GIFs inside emails unthinkable and ridiculous ten years ago. Today, not a big deal really for a good chuck of audiences. Etc.

I do remember using WorkMarket a long time ago and experiencing the bizarreness of their emails as they were one of the very few AMP users.

They'd send out emails about work opportunities and leveraged AMP to be able to go back into the email and tell you if it's still available to apply for or not in realtime, so you wouldn't have to click through and be disappointed it was already taken.

I'm surprised more people don't use images for this kind of thing. You could put an image with a green checkmark next to every live job posting, and change it to a red X once the job is no longer available. I worked for a publisher of email newsletters and we ran a bunch of tests into the caching behavior of email clients to see how viable this kind of thing would be. Turns out it's pretty easy to implement and works just about everywhere.

On the contrary. The only place you get a standards-based email is Apple Mail on Mac and iOS. Gmail's web client is absolutely terrible for web standards. Outlook, on the web or app, is almost as bad.

I think it was a great idea, useful in many cases (confirmations, approvals, votes, unsubscribes, forms, up-to-date flights and bookings info etc etc. I for sure admire that I can accept meeting invites right inside email in Gmail. Email must stay the same - it has HTML/text parts, these will stay same and can be accessed in 5 years. If someone really wants to include dynamic info in email they will do anyway- either link to webpage or dynamic image.

Netscape tried dynamic email with Communicator in the 90s…somehow I still have the sample "Airius Airway's 401k Contributions Worksheet" with JavaScript embedded (Gmail obviously ignores it). IIRC no one, and I mean no one, took advantage of it.

Google Wave (ca 2009) also claimed that it would replace email. Expect the next email replacement from Google in 2029.

I came looking for this comment. One wonders if AMP-in-email was a project of the same team scaling back their original ambitions... but 10 years is a long time at the revolving door of Google.

I was so disappointed this failed, and for what seemed like such an incredibly obvious reason.

They tried to use the same viral "invitation only" system that had worked for Gmail for Wave, but apparently completely overlooked the key difference: Gmailers could send and receive emails to people who didn't have Gmail. Wave was only usable with other people who had Wave. And with only a handful of invitations, it was virtually impossible to grow your network fast enough for it to be useful.

If they had made it possible to send regular emails to and from Wave (even just by integrating the existing Gmail account!), but then also let you "upgrade" your message to send a Wave when the recipient already had Wave, I really think people would have been willing to use it long enough for their Wave networks to grow big enough to replace email.

IMO any standard pushed by the great internet gatekeepers (Google, Cloudflare etc) is best avoided.

And don't tell me Cloudflare does no evil, that goes for now, and that went for Google some time in the past too.

"Interactive email" is basically Slack.

We should make Slack a new internet protocol and application standard, and use that going forward to replace e-mail, texting, and the various isolated islands of "secure chat" solutions (WhatsApp, Signal, Telegram, etc). Allow us to retain and control our own data, while also enabling all of the features and functionality we've come to want from modern tools, and be compatible with other solutions.

IRC and e-mail are both old and busted. 99% of the world wants to communicate and share information with more interactive tooling than ASCII text in a console or static HTML in a mail reader. There are alternatives to Slack, but like every networked application created in the last 10 years, none of them define an interoperable standard. They are all their own vendor-lock-in islands.

Even Mattermost, the most polished "open-source" alternative, is not a standard, it's an application. Applications change all the time. Standards don't. Applications lose backwards compatibility, change their licenses, have closed ecosystems of servers. Standards don't. There's a reason that actual standard network protocols continue to work for 40 years, while applications made just a few years ago are dead and buried. Standards last. They enable interoperability in an ecosystem of supported technology. They give us flexibility, choice, competition, portability. The world is better when we have solid standards to build on.

Replace it all with a standard. Let anyone implement the standard, implement a client, a server, etc. And let people choose the tooling they want - but while being interoperable with everyone else's.

(Note that I'm not talking about federated social networks. E-mail and IRC are not social networks, they are communication tools, private by default, and have to be directed at specific individuals or groups)

I think that you just described XMPP and Matrix, which are both standards.

Comparing XMPP/Matrix to Slack is like comparing Telnet to Chrome. Yes, they both display text, they're both interactive. But the latter has about 5,000x more features, which is why we all use it.

Yet with Slack, it doesn't use a standard. Could you build an app like Slack that includes XMPP/Matrix along with a whole lot of other stuff? Sure. But without the whole kitchen sink, you still don't have a standard other apps will follow. You have a proprietary app plus XMPP. Other apps won't be compatible with it. Which is the case with Slack's competitors.

Think of a web browser. It's larger than a kernel. It's probably the biggest, fattest, meatiest, most feature-rich application in the world. (And it should be, because it's a freakin' application platform at this point.) But it all runs on.... standards! Every part of it. I'm saying, do that, but for the massively feature-rich, complex, large, almost unwieldy, but insanely productive, communications platform that is Slack.

I get that a lot of people don't really understand what the big deal about Slack is. A lot of people thought the same thing about web browsers back in the day. But once they started using them a lot, they got it. It's not just a document viewer, just like Slack isn't just chat.

So what features does Slack have that Matrix doesn't? Maybe huddles? But Matrix has persistent Voice/Video Rooms for that, which work just as well.

Everything else, from bots and embeds over threads and spaces to reactions and emoji works the same.

Slack is basically irc with some bells and whistles, sorry :)

It really, really isn't.

And anyone who claims that it is misunderstands both IRC and Slack.

You want THE communication standard to be owned by Salesforce?

> Replace it all with a standard. Let anyone implement the standard, implement a client, a server, etc. And let people choose the tooling they want - but while being interoperable with everyone else's.

Slack is chat, and chat is not email. Email has important properties that are lost in a chat protocol/UI.

Email and chat are identical in the modern age. The only difference is the coat of paint. Once chat could send attachments, do replies, persist history, have group chats, it supplanted email and has continued to do so for more than a decade. Chat even ate email's lunch in the one area it had a cultural advantage, conducting business.

I don't want most of my vendors sending me messages on Slack or Teams. If there's an issue that requires attention, please send me a thoughtful email with the relevant information.

XMPP exists as a standard, and Google Chat was built on it. Then Google+ came along and needed more features, and instead of adding these features to a standard that supports federation (like XMPP or now Matrix), Vic Gundotra (I assume) did the expedient and stupid thing of building Hangouts Chat like Facebook Messenger, commencing the parade of throwaway Google communications products to come.

I think IRC and plain text email (especially if it does not use Unicode) are not so bad. NNTP is not so bad either.

And, standards should not be made excessively complicated or badly designed; even if there is some complexity they should be optional when possible.

I didn't know amp was a thing in email. Glad it died before I knew about it.

I've never viewed an amp site either. Actively avoided them, went out my way to view the actual content. Easy to do when you don't have JavaScript enabled by default. I hate it when I can't view textual information on a site without JavaScript.

> Four years earlier, the search giant had come for the mobile web with AMP—accreted mobile pages.

typo in third line of the post.

should i feel warm and fuzzzy knowing that this was not run through an LLM?

or is it a hallucination artifact of that very thing.

I've never received an AMP email but it looks like based on the format [1] one could search the body for cdn.ampproject.org and either REJECT, DISCARD in Postfix or quarantine it if using some anti-spam platform.

    # grep body main.cf
    body_checks = regexp:/etc/postfix/body_checks

    # grep ampproj /etc/postfix/body_checks
    /ampproject/    REJECT AMP IS NOT SUPPORTED ON THIS SERVER

[1] - https://amp.dev/documentation/guides-and-tutorials/learn/ema...

The worst part about AMP was that it didn't even feel particularly fast. Not sure how they managed to fail at literally their main design goal.

I worked on AMP and AMP email for a while at Google, but these are just my thoughts. HN always pulled out the pitchforks on this topic, I'm not surprised to see the same again. I disagree with a number of things this article claims:

> Build an AMP site, and you’d get preferential placement in search results ... The implicit stick, though, was that without an AMP page, your site wouldn’t rank as highly as it may have previously. And

There was an AMP news carousel that would appear at the top news results. The web result order however didn't prefer AMP. Depending on how you looked at it, this was preferential or it wasn't. The "wasn't" perspective is that this carousel was much like showing image or video results - it was a different format and there was a result spot reserved for some docs of that format if the query warranted it.

Interestingly, when Google first started rolling out carousels for images or videos in normal results, website owners protested as well as it was competition for visibility. I don't hear that argument as much any more.

Regardless, the AMP carousel has been gone for a while AFAIK.

> “We are here to make the web great again,” said Google’s vice president of news, Richard Gingras in 2015, only months after Donald Trump brought that phrase into the vernacular

Yeah, that aged poorly.

> [AMP] brought back the dynamics of the mobile versus the desktop web, for one. Instead of the same web for everyone, you now had one page on mobile, another page on desktop

That was a website owner choice. AMP pages could be responsive and work just fine on desktop. Many sites did exactly that, though you often never realized they were AMP pages. The goal of the project was always to optimize mobile performance, but it worked well for desktop too. Search provided a mechanism where you could choose to pair an amp and non-amp page, only showing AMP for mobile. I suspect sites did this because non-amp allowed all of the bespoke javascript they wanted on desktop, including things that were kinda terrible for user experience but improved ROI. Super heavy javascript, ads that were difficult to dismiss, all sorts of jank.

> And, more critically, it lessened your control over your site. ... ad tech and other scripts on your site might be incapable of running on your AMP site

AMP is a subset of HTML plus some javascript libraries. The subset thing means you had a limited API. That was the point though, the limited API was restricted to the set of things that could be forced to be performant. That is "control" in some sense, but it wasn't control in the common sense of limiting content or ad networks or whatnot. Virtually every ad network had a library for running on AMP.

> AMP required allowing any AMP CDN to cache your pages.

You can and always could create amp pages that are not served by AMP CDNs. The tradeoff is that search results couldn't preload the page for the user, as there is a hard privacy constraint that the user can't initiate network traffic to the publisher until they indicate intent with a click. So without the CDN, it wasn't quite as fast, but it was still typically pretty fast.

> As Ray Tomlinson, who implemented and sent the first email from ARPANET in 1971 said about adding formatting to email: “That’s too complicated: we just want to send messages to people.”

This is a valid perspective on what email is or should be. I don't feel strongly that it's the only perspective, but it's certainly valid. The argument however is really against HTML email, not AMP email in particular. I think most of the rest of the arguments apply pretty equally to both.

If you look at HTML email in webmail clients, clients all work on the principle of sanitization. Take arbitrary HTML, modify it to remove anything dangerous, and then render the rest. "anything dangerous" requires removing all javascript, most or all CSS, large swaths of the HTML tag space, rewrite all image URLs, etc.

This would result in pretty garbled results except senders have adapted to only send the subset of HTML that won't be garbled. However, it's not easy to do. Take a look at https://templates.mailchimp.com/resources/email-client-css-s... which shows what each email client accepts. It's much much worse than browser incompatibility, though you also have to handle browser differences too.

In a sense, this limited HTML API is similar conceptually to AMP. AMP just was able to add back some of the interactive functionality stripped away. And AMP had the possibility of becoming a open-source standard compatibility API for webmail clients. One that was open source, had maintained validators that could be tested against, etc.

I think it had the chance to really make HTML email better. Of course, if your perspective is that HTML email is fundamentally bad, then that's not really a win.

> You’d need to authenticate your domain with DKIM, DMARC, and SPF—good ideas, regardless. You’d also need to send a sample email to both Google and Yahoo!, and register your domain with each of them. Then, if you were lucky, within 5 days you’d be approved to start sending AMP emails.

I think the plan was always originally to expand this to a general availability format. However, AMP email launched in 2019 and Google largely shifted away from AMP shortly thereafter, so the project never got enough momentum to get to that state, sadly IMHO.

> AMP is a subset of HTML plus some javascript libraries. The subset thing means you had a limited API. That was the point though, the limited API was restricted to the set of things that could be forced to be performant. That is "control" in some sense, but it wasn't control in the common sense of limiting content or ad networks or whatnot. Virtually every ad network had a library for running on AMP.

Javascript libraries that MUST be loaded from one specific Google CDN.

If I load the exact same libraries from my own domain, suddenly it's not "valid" AMP anymore.

It's not a standard if it only works with one specific implementation.

> It's not a standard if it only works with one specific implementation.

IMO, that's sort of what a standard is, but the words is not strictly defined.

I think you are trying to argue that it's not open. The source is on github, and does accept contributions, but effectively Google controls who can commit to it. Depending on your definition of open, that's a valid argument.

You can load those libraries from other locations, but Google search results won't be able to cache it because of the privacy concerns I mentioned in my top level comment. It's not "valid", but the only consequence of the invalidity is no caching, and that consequence is unavoidable given the privacy constraint. It still shows up in search results.

The Google javascript library URL serves with no cookies, is publicly cacheable, and is an identical file to what you can build from source on github.

This article misses the point of why emails were made interactive in the first place - to satisfy the demands of marketers. 90% of the emails you get are marketing-related. If you get an email that says "4 days left for our holiday sale", that counter will need to be updated if the email is not read on the same day. It's a small, maybe frivolous-sounding use case, but a lot of feature bloat starts out this way.

You can do much more with AMP, not only marketing related stuff. Indeed, countdown timers can be done much easier with many tools (Nifty Images, Sendtric etc) without AMP.

AMP as described in this article provides a wrapper for some templated kinds of JS functionality. My comment wasn't specific to AMP, it was to the article's main point about "interactive emails" being unnecessary.

You don't need interactivity for this, you just need "<img src="" />"

Which still isn’t perfect as images get cached at different stages depending on the email client.

Or can be blocked or are opaque to visually impaired.

Everything Google has done in the last 20 years has made the web worse.

This is just obviously false. If you want to claim that Google's impact has been on balance negative we can certainly argue about that, but some clearly positive things include:

* Massive security improvements, including encryption (pushing HTTPS throughout the stack, funding Let's Encrypt, trackers on HTTPS adoption), site isolation, Project Zero, certificate transparency, pushing CSPs, authentication standards.

* Large speed improvements, including V8, HTTP/2, HTTP/3, Brotli.

* Web standards, including work on HTML5, JS standardization, web assembly, CSS flexbox and grid, webrtc.

(Disclosure: I worked on web stuff at Google 2012-2022)

> pushing HTTPS throughout the stack

Barriers to entry for self hosted sites. Easier to host with Google now.

> Large speed improvements, including V8, HTTP/2, HTTP/3, Brotli.

HTTP/whatever was done only for Google's benefit.

> Web standards, including work on HTML5, JS standardization, web assembly, CSS flexbox and grid, webrtc.

If they're so standard why do people develop for Chrome and ignore other browsers?

> Barriers to entry for self hosted sites. Easier to host with Google now.

Let's Encrypt (which Google helped fund) is the opposite of a barrier to entry. Free domain-validated fully automated HTTPS cert distribution wasn't a thing, and now it is. It makes it way easier to self host in a post-PRISM world.

Also, Google does a tiny fraction of overall web hosting.

> HTTP/whatever was done only for Google's benefit.

Your claim is that everything Google has done has been worse for the web, so you don't get to pick individual tech that's clearly good (ex: V8) and ignore it. And whether things were done for Google's benefit is also irrelevant: the claim is about outcomes.

On the specific question of HTTP/2 and HTTP/3, these have made large improvements in end-to-end loading times across the web, including when Google is at neither end of the connection, and especially for high latency connections like mobile.

> If they're so standard why do people develop for Chrome and ignore other browsers?

All of the things I listed are widely supported and fully standardized.

There are other parts of the web platform that aren't, and that does push people to Chrome, but that's not what we're talking about.

Again, if you'd like to claim Google's impact has been bad on net that's much more arguable, but your claim is way stronger than that.

> Free domain-validated fully automated HTTPS cert distribution wasn't a thing, and now it is.

Free compulsory ...

It is not compulsory. The browser may warn about lack of HTTPS, but that's about it.

And I won't visit such HTTP-only site since it indicates the site owner does not care to protect my (meta)data, but they probably don't want my clicks.

And would you think this way if they didn't spam the "accept the risk and continue" scareware?

Why is it phrased as the risk is coming from the web site, when the risk actually comes from the backbone and whoever is able to intercept your communications?

(paraphrasing from memory because it's a while since I've seen it)

> Your connection is insecure. Information you send could be intercepted by attackers. Accept the risk and continue?

Explains the problem in simple terms. Calls out the website for being lazy and careless. Gives you the option to proceed if you don't care.

Why is this scareware and how would you word it?

>If they're so standard why do people develop for Chrome and ignore other browsers?

Because in practice each browser is a separate app platform with support of different features and with different performance profiles. From a business perspective for a business to expand to a new app platform there must be some sort of justification to do so. As an extreme example think of why don't websites also remake their site on Roblox for example? Supporting a product on an app platform well is expensive and not all platforms can justify that expense.

But ... i thought Google was standardizing the web.

Would they be introducing features to their browser at a speed no one else can match just to create a lock in effect instead?

And are those features benefiting every site or are they targeted towards Google properties?

They are standardizing the web.

>just to create a lock in effect instead?

No, developers requesting features and expressing pain points are a major motivator of changes.

>And are those features benefiting every site or are they targeted towards Google properties?

They are targeted towards web developers to enable them to create good experiences for end users.

The way that monopolies dominate is by stagnating tech. IT tech. The driver of our economy. You're missing a decade plus of killed advancements through acquisition and extermination. The efficacy gains are theirs, we just get to larp as being better by using them. The idea that HTML5, JS standardization, web assembly etc. are important is ignoring how they are simply abstractions that maintain the status quo and add complexity that only serves builds their moat.

RSS is probably the best example. This is massively more efficient than any other thing you mentioned, which are only incrementally better. RSS saves orders of a magnitude more energy than is "saved" by modern JS which requires ever more powerful processors where older computers are simply incapable of browsing the modern web, but for some legacy websites which really highlight how "efficient" these techs you mentioned really are. The only thing they are efficient at is extracting money from users into Google's pockets and selling new iPhones.

Newer processors, massive low power RAM banks, specialized IP processors, cutting edge lithography, Webkit, Chromium, all these advancements google now claims as theirs with your logic.

How could Google claim WebKit as "theirs"? Symmetrically, how could you not acknowledge that without Google Chromium would not exist?

I disagree and I think that some of these things are some problems.

Forcing HTTPS was not really the best idea (and HSTS is bad for other reasons too). Let's Encrypt is a way to get a certificate easily in case you do want or need HTTPS, although it does lead to problems, such as some businesses will have certificates that do not contain the identification their address and that stuff, and some more problems. In addition, I think the design of Let's Encrypt automated certificates is not very good either.

I had not known what is Project Zero, but Wikipedia says they find vulnerabilities and documenting them so that you can defend against it, and this is helpful.

The authentication standards they made up aren't that good either. If you already have HTTPS, then you can use client certificates, which has many benefits and some more security compared with many of the other methods being used (e.g. TOTP) as well as not needing JavaScripts and cookies and that stuff.

V8 is not bad, but the designs that need this much speed (not only V8 but also HTTP/3 etc) means the design is probably already excessive. Making or using a browser should not require this for everything.

HTML5 has some good ideas as well as some bad ones, and so do the other web standards. But older versions have their own problems too. I also think they put too many things in the document and the script and styles in the document, that should better belong in separate user settings.

I also think that believing that JSON and Unicode and that stuff that they use, are not really that good either. (I think DER is better than JSON in many ways, anyways)

I'm gonna take the other end of the luddite argument— this is cool as hell and they should lean into it more. Discord has proven that an app platform hiding underneath IRC is hugely popular. Email with the power of discord integrations and bots would get me to up drop gmail immediately.

It could be cool as hell if it would be used for any purpose other than sending marketing communication. But, unfortunately, we live in this world.

No, thank you. E-Mail is designed to be an analog to, well, analog mail. I expect to open the same e-mail 5 years later and see it intact, in meaning sense.

For interactivity, we have web pages, and they seem to work fine.

This doesn't compare with Discord, because Discord is meant to be a "chat" platform for ephemeral issues to begin with (yet it's abused as a permanent platform), and AMP for e-mail is abusing a platform designed for permanence for temporary communications.

That's a bad idea(TM).

The use case you described is genuine. But the problem I see here is the insistence that the email platform should fulfill those requirements instead of creating a new platform and letting it win the market on its own merit.

People have certain expectations from emails, which have remained largely unchanged since the emergence of the internet. Those include a federated and fully open platform, immutability of messages that make it valuable as communication records, privacy afforded by plaintext, simplicity of use, etc. Many changes have already ruined some of those qualities of emails. For example, introduction of HTML in emails have converted emails from a messaging platform to an ad and tracking platform, forcing many clients to block dynamically loaded resources. Quoting of prior messages have become a complete mess. But worst of all, the email platform is arguably no longer fully federated, now that it's nearly impossible to self host email servers.

It wouldn't be a stretch to argue that changes like these are intended more to centralize the email network than to add features to it. AMP is a clear aggression in that step. It's telling that neither AMP for web, nor AMP for email survived once Google was forced to stop pushing the so aggressively. Makes you question who wanted it so badly and why.

The chance of another distributed platform with the properties desired seems small. Why should email be resistant to any change? Takes like this is why every company develops their platforms as silos rather than open standards. To avoid the inability to ever make a change once it becomes popular. Instead, at best, we end up with large monocultures around an open source project such as Linux or chromium. Maybe that's better and email like platforms are a mistake, but fundamentally I don't feel like that should be true.

Such an "interactive" use would need to keep the basic structure of email; for example, a bot you can email and it talks back to you. (Such things have been tried before, but never really caught on.)

If Discord had the same spam or mass marketing problems that email and postal mail have, nobody would willingly use Discord. As it stands, the primary purpose of email is to get authentication codes emailed to you so you can login to other things.

This to me is the strongest argument in favor full evolving email into something else. It's damn near pointless, nobody needs digital letters and just like our IRL mailboxes they have become our distal trash bins. I would love to email to work up the stack and lose it's unstructured nature for most use cases.

People use email for 2FA codes and such, why not go the whole way and let email and Google Authenticator be the same thing.

Discord is not built on IRC. It's a completely custom, proprietary thing. "Servers" are not separate machines, as they are in IRC land, they're just groups of channels.

Discord is the worst platform of all. All content is hidden for outsiders, non-indexable by search engines, its the prime example of non-open siloed knowledge. To this day I will not use a project if it heavily relies on discord. All of the content could be gone at once, at the whims of one company.

These are all complaints about Discord the chat platform, not Discord the extremely successful blending of text based messaging and rich UI interactions.

Reply on news.ycombinator.com