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

Interactivity vs Email’s Role

• Many commenters argue email is fundamentally a record: self‑contained, immutable, and readable in 5+ years. Interactivity undermines this by allowing content to change after receipt.
• Examples of problematic “dynamic” behavior: countdown timers that change, emails that are just links to portals, invoices only available behind logins, and content hidden in remotely loaded images.
• Several people intensely dislike “you have a new message, log in to read it” emails from doctors, banks, and governments, seeing them as control/lock‑in rather than user protection.
• Others see valid, limited interactivity (e.g. accepting calendar invites, checking job availability, simple confirmations) as useful, provided the static text/HTML remains canonical.

AMP’s Goals and Problems

• Some defend AMP (web and email) as a technical straightjacket that solves a “tragedy of the commons”: stopping publishers from shipping bloated JS and abusive ad code, making pages reliably fast and prerenderable.
• AMP is described as “subset HTML + JS components” with performance guardrails and a shared runtime, conceptually similar to HTMX or a standardized HTML email subset.
• Critics focus on power dynamics: AMP tied to Google search carousels and caching, perceived as abuse of monopoly and centralization, with publishers feeling forced to adopt it for SEO/visibility.
• Many found AMP pages user‑hostile (hard to get to the “real” page, weird desktop layouts, hijacked back button) and AMP email too complex to justify, especially since adoption remained tiny.
• Several note that AMP’s performance benefits could be achieved by simply building lean sites; AMP added branding, lock‑in, and validator requirements.

Email’s Present and Possible Successors

• Some see email today as mostly a 2FA/notification/marketing channel and argue it should evolve or be replaced by richer platforms (Slack/Discord‑like) with bots, integrations, and structured workflows.
• Others insist that chat and email serve different purposes: chat is ephemeral and conversational; email is long‑term documentation and legal/financial record.
• Proposals surface for a Slack‑level, standards‑based protocol (akin to how browsers implement web standards) to replace siloed chat apps, but current contenders (XMPP, Matrix) are seen by some as less feature‑rich than Slack.

Security, Privacy, and Regulation

• HIPAA/GDPR and SMTP’s lack of guaranteed end‑to‑end security are cited as reasons institutions push portal links instead of emailing sensitive content directly.
• Commenters debate whether current “privacy” practices (cookie banners, forced portals, attachment limits) meaningfully help users or mainly degrade usability and increase control for senders.