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.
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.
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.
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.
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).
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.
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.
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 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.
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...
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.
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.
What are you sending that 3MB for an email is "low"? The Bible is a little over 4MB of plain text.
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
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).
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.
Whether a site used AMP did not affect ranking in Google.
It never occurred to me that AMP is an initialism for "Abuse of Monopoly Power". It's deliciously fitting.
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?
That’s not possible without building an AMP page since it requires being able to safely serve off of google’s domain.
Instead they should have said, "Web pages should be lightweight not overdo it on interactivity, and load fast."
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
It’s mostly business use that’s keeping email alive, either business-to-consumer or business-to-business.
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.
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.
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.
And don't tell me Cloudflare does no evil, that goes for now, and that went for Google some time in the past too.
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)
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.
And, standards should not be made excessively complicated or badly designed; even if there is some complexity they should be optional when possible.
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.
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.
# 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
> 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.
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.
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.
* 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)
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)
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?
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.
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).
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.
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.
People use email for 2FA codes and such, why not go the whole way and let email and Google Authenticator be the same thing.