Hacker News new | past | comments | ask | show | jobs | submit login

The problem with monopolies is that nobody else has a choice. If Outlook or Yahoo were to fail to adopt the proprietary Gmail standard, they would eventually end up incompatible with the now-proprietary format of email. Whilst AMP4Email can fall back to HTML, the reality, as with text-only emails after HTML, that many providers will not bother sending multiple formats.

Your team has repeatedly refused to address criticisms of AMP from users and the community at large, and continued forward with a program that nobody wants[1]. There's still no way for someone to opt out of AMP as a whole except to use a search engine that doesn't support it, and Gmail seems to lack an AMP switch in settings, so I'm guessing you currently have no plans to let Gmail users escape it either.

[1] https://twitter.com/googleampsucks - Endless retweets of people's thoughts on AMP.




Or, based on the evidence...

... Microsoft and Yahoo think it's a good idea and want to support it. There's no particular reason email needs to sit around in the gutter while the rest of the web gets more multimedia and more performant.


> sit around in the gutter while the rest of the web gets more multimedia and more performant

I (sincerely) appreciate reminders like this of just how much online opinions and experiences vary.

My sense of the last few years of web changes is that performance is mostly a product of script-blocking or AMP-degraded functionality, and new multimedia is mostly a user-hostile attempt to boost revenue. Whether it's five-point stories broken across five page loads, Reddit's "use our app" links breaking in AMP, or Techcrunch's insane scroll-down-to-redirect-to-homepage layout, the last ~3 years of web development are full of changes I find actively negative.

I understand the fight over something like AMP for email much better when I remember how far from universal that is. It's not really a surprise there's so much disagreement over what to do next when there's this much divide over what's working well at present.


AMP seems less like a response to 'the web is slow' and more a response to 'people who are tired of slow websites are using content blockers so we need an alternative so they don't block our ads'.


It's a solution to the web is not instant, which closed proprietary competing solutions like Facebook Instant Articles and Apple News solve.


> There's no particular reason email needs to sit around in the gutter while the rest of the web gets more multimedia and more performant.

Email is not part of the web, and more multimedia and more round trips is not more performant, it's the opposite.


Email should be plain text. HTML in email itself was a terrible idea, though not as bad as AMP in email.


Some HTML in email is fine, I would say the subset that can be expressed by markdown. Making text bold, italic etc should be possible. The real problem I have is how limited email HTML/CSS and email clients are compared to the web, so that every "rich" email will use table layouts that render terribly on mobile.


But still better than anything else that could reasonably be achieved.

Tables are pretty much the only cross-platform/client way to format email.


> Email should be plain text.

That ship sailed the moment it got named email, leading people to think of it as an electronic form of mail, and so to expect that eventually it could be used for any documents you would send by mail.

With mail, I can send anything I can print or handwrite on paper, which includes text in multiple fonts, graphics, charts, tables, in a variety of colors. I can also include anything that fits in the envelope, so I can include files on floppy or disc or memory card or a thin thumb drive.

Sure, earlier email systems could not handle anything more than plain text, but because it was called email many people assumed that was just because common computers and displays didn't have the capability to handle more.

Once the GUI became prevalent for home and office computers, rich email was inevitable.

In retrospect, if the people who designed the earlier email systems had wanted the restriction to plain text to be a design goal, rather than just a consequence of the technology of the day, they should have named it etelegram to make it clear.


There's been rich-text email since (at least) 1980 and by the mid- to late-1980s there were many competing efforts: CMU's AMS, BBN's Diamond/Slate, NeXT's NeXTMail, and probably several others.

I'd go so far as to argue that the parent's reaction -- "email should be plain-text" -- is exactly why the horrors of HTML are what we have today. No one adopted any of the better alternatives out there and then Netscape -- a web browser, after all -- hacked in HTML mail, and "worse is better" won the day yet again.


Technically email is plaintext, though for the definition you aspire towards, it was in the early days. But then various RFC's added this and that and now email processing/sanitisation is scary.

But then email is one large unsanitized input that has so many rules to be applied, what could go wrong.

That's why email attachments alone are an utter MIME-field when it comes to security.


Pure gold pun right here:

> That's why email attachments alone are an utter MIME-field when it comes to security.

And yes, remember the 35C3 talk on e2e email security.

https://www.youtube.com/watch?v=kKjtZy87iI0


> https://www.youtube.com/watch?v=kKjtZy87iI0

Not seen that, watching now (about half way thru) and nice to retouch upon a feild I've not working in for many years and seeing how not much has changed. Equally a little depressing, to see the same types of problems 10 years on.


> Email is not part of the web

The web is not just what happens in a web browser:

> An information object is "on the web" if it has a URI.

— Tim Berners-Lee, Axioms of Web Architecture, https://www.w3.org/DesignIssues/Axioms.html


so, not emails? I can't refer to an email via URI, as far as I know.


Wait, the original claim was:

> Email is not part of the web

That's "email", not "emails". I understood that to mean email the concept / technology, not "emails" as in individual email resources.

By that reading, yes, email is on the web. You can link to a mailbox with the mailto: URI scheme.

If you read it as "Individual emails are not on the web" instead, then webmail seems to cover that.


That’s good news for books ("urn:isbn:"), movies ("urn:isan:"), UUIDs ("urn:uuid:"), and so many other things that I thought weren’t on the web.

If I reside in "urn:oid:2.16.840" and I read "https://news.ycombinator.com", is that what they call the inner-platform effect?


I'm guessing the point you're driving at is "these things obviously aren't on the web, so this is wrong"?

The web is an abstract information space that can contain arbitrary links between objects. The web isn't something you load in a browser, it's a way of organising links between things. So, yes, you can link to books, movies, etc. Anything with a URI.

You might be interested in this early document about the World-Wide Web:

https://www.w3.org/People/Berners-Lee/1996/ppf.html

It describes what I'm saying in more detail, including explicitly mentioning books as something that can be addressed in URI space.


If the definition of the web is "anything addressable via URI," then the definition of the web is no longer useful. I can imagine a URN scheme for every atom in the universe. Welcome to the web -- you're soaking in it!

More seriously, I think that -- if pressed -- I'd say that the identifiers are on the web, but the things are not. Other than that, I believe we would agree???

That said, the origin of this discussion is in relation to Google's launching of AMP for e-mail. The justification was that e-mails are on the web, so it's OK to use AMP to push them forward. A better viewpoint, though one I disagree with, relates AMP to being a better mode of HTML. (As opposed to one of the Web.)


Every email message has a unique identifier called the Message-Id, but SMTP does not host messages with an HTTP URI.

Serving public URIs for messages must be done by separate web servers like a webmail client, or a mail archiving tool such as Pipermail.


> an HTTP URI

Note that there's no requirement for something to be an HTTP URI specifically. Any URI will do.


Yet still, without a webmail client (a client that specifically takes an offline protocol and puts it on the “web”) email would not have a URI. You an “link” to a mailbox, but not create a particular mail with a particular identifier then later retrieve it with that same URI. The URI identifies the users mailbox, NOT their mail.


Good point, there are URIs for other protocols (like FTP, Gopher etc).


> An information object is "on the web" if it has a URI.

I think that TBL is very incorrect here. If that statement is accurate, then most of the non-web internet would have to be considered "the web".


> I think that TBL is very incorrect here.

You think Tim Berners-Lee, inventor of the World-Wide Web, is very incorrect about what makes up the World-Wide Web?


Yes, he is not the authority on the web and has very little to do with it these days other than accepting back slaps for something he did decades ago.


Yes, I do. Even TBL can't take all of the services that ran on the internet before the web was a thing and declare that they're all "the web" now.


> Email is not part of the web

Content-Type: text/html seems to disagree with your assertion.


The HTML documentation sitting in my /usr/share/doc does not make it part of the web.

The output from man -H is not part of the web, no matter what its mime type is.

HTML is not the same as the web.


> There's no particular reason email needs to sit around in the gutter while the rest of the web gets more multimedia and more performant.

"The rest of the web" is the ad-laden, tracker-infested, bloated gutter of the internet. Email is (was?) a little morsel of the old open internet (along with RSS/podcasts) that has not yet drowned in the morass.


>gets more multimedia and more performant

More performant then text? What are you comparing it to smoke signals FFS? And let me see if I understand you correctly, you _WANT_ multimedia in your emails?

What is the point? To send miniature versions of web-pages?!?


Google is looking for alternative channels to sell ads through. Adding more complicated media to email increases the type of ads that can be sold. It won’t be right away, but it’s coming.

As their users spend more time with voice assistants and less with search result pages, Google needs to make up for those losses somewhere else. If they don’t, their revenue growth will end or invert, the stock price will drop, and the amount of money they can pay all of their employees will significantly decline.

For all of the messaging platforms Google tried to build and messed up, it is a real possiblilty that Google could end up killing Gmail through management screw ups.


I favor this view of outcomes. The backlash caused by AMP in the first place was loud, but small. More people seem to be catching on with the negatives of it... AMP for email may not be the downfall of Gmail, but it opens new decision pathways that could be very harmful for the platform, such as inserting ads into private email conversations.


Ads are easy to block, even with this development. The delivery may have changed, but not the how to. Blocking ads at the DNS level is always effective. I enjoy the cat and mouse game with the ad companies. It's always interesting to see how the adblock guys do their thing. Employing a Pi-hole has been one of the best decisions I have made in regards to my own network. Couple the Pi-hole with uBlock Origin, Privacy badger, Decentraleyes, and a few other tweaks, and you get the WWW the way it was intended to be: content only.

I am unapologetic about blocking ads, beacons, cookies, trackers of all kinds. My computer, my rules. Just as I'm not required to look at roadside ads, and I don't, I refuse to allow my network to become compromised to give someone else another BMW. Running a website is the cost of doing business. If you cannot afford the domain name, bandwidth, etc., choose another business model. Ads were and are a horrible business model. I haven't seen an ad in literally years. I plan on keeping it this way.


If DNS adblocking becomes too widespread, expect Google to start serving ads on the same subdomains as your Gmail messages.


Can still block them with element blockers. Elements are quickly cataloged, added to block lists and shared. Happens in mere minutes. A lot of this is automated, but it can be hand curated as well for some that were not noticed or perhaps new. An entire "industry" exists to keep the web clean. uBlock Origin does a fantastic job in this regard. In fact, it's one of the only methods that kills adblock blockers. I've not seen a successful adblock blocker since using it. It kills them dead. No more nag screens. Nothing but a clean content-only website, as nature intended.

There are some very smart people in the blocking arena. Since most of this stuff is delivered via JS, it's fairly trivial, at least at the moment, to handle same-domain ads. The game may change in future, but the adblock people usually prevail.

One idea I have if the sites start outright blocking blocking users, is to sort out how to write the ads to a form of /dev/null while making the site think they've been shown. I used to do this with Flash cookies/LSOs. I wrote them to /dev/null so I could take advantage of Flash back when it was a thing, yet have no LSOs on my machine to track me. Coupled with referer blocking, history blocking, no fingerprinting, and other settings, it worked a treat.

I'm willing to bet that if we cannot "block" them as part of the domain, we can sort out a way to block the element, shunt the ads into the bit bucket and continue on our merry.


>One idea I have if the sites start outright blocking blocking users, is to sort out how to write the ads to a form of /dev/null

I think several dns-based ad blocking programs can do this today, but so far I have not had a problem with returning NULL address (0.0.0.0). Pihole talks about the pros and cons of common approaches: https://docs.pi-hole.net/ftldns/blockingmode/. One downside is you have to run a webserver to catch the redirect and all the overhead that comes with it.


Yes. The advantages of HTML in an email are well-documented in the TC article and the Google announcement. I would make use of that, personally.


    None of those "Advantages" were advantageous to the end user.  This only benefits Google or other corporations, and anything that benefits them harms me.


With respect, "anything that benefits corporations harms me" is a weird attitude.

AMP in email could, hypothetically, allow me to hit the "checkin to my flight" button for a Southwest flight directly from my confirmation email without having to bump over to their website. That's cool, convenient, and simplifies my life. It also benefits the corporation (their resource allocation is easier if they have a firm count of flyers) and it benefits Google (I'm more likely to use an email client that facilitates this).

The business world is full of win-wins, and this has the potential to be one of them.


That’s theoretically possible now if not actually implemented already. AMP in the email isn’t going to automatically make this possible. The SWA devs and the Delta devs and the AA devs and the Alaska devs and the Northwest devs, ad naseum are all going to poorly implement their version just as poorly as their REST version (if they have one). The implementation mechanism isn’t really going to improve the experience. It will just be something different that is broken or slow.


> checkin to my flight button

You can do that in HTML email too. Newsletter have an "unsubscribe" button, calendar invites have a yes/no/maybe button.


Not without leaving the email UI, no.


Let me introduce you to Actions and Highlights, which do exactly this without leaving the email UI. AFAIK Gmail has the best (only?) support for them, but anyone could support them.

https://developers.google.com/gmail/markup/actions/actions-o...


It also allows for even more invasions of user privacy. We’re already tracked like tagged coyotes, so where does it stop? Obviously, not when users say so, because we can’t afford the lobbyists and lawyers that industry can.

So now we just have to lie back and think of profits?


What an incredibly bad example. Many airlines already include a link for a one click checkin. They already induce people to checkin (southwest for sure) with boarding priority based on checkin time.

You’ve perfectly summed up AMP for email with a use case that’s already been solved by a simpler technology that nobody has complained about.


Being able to respond to & deal with gdocs changes directly within an email has clear advantages for users of gdocs.


Those "advantages" are very weak, at best.


> There's no particular reason email needs to sit around in the gutter while the rest of the web gets more

In my view, that's not "email sitting around in the gutter", that's "email retaining things that make it valuable".

Also, email is not, and should not be, the web -- so "the rest of the web" is a bit of a nonsequitor.


Email has in some ways sat around in the gutter but media reasons are not why. The protocols are insanely complex and archaic and you need about 20 bits of software to actually run an email server. And then its all completely insecure because email was never built with end to end crypto.

imap is so insane that every email provider reinvented it to have a sane api for their web client and app. Fastmail also created JMAP to have a standard json api for email.


>There's no particular reason email needs to sit around in the gutter while the rest of the web gets more multimedia and more performant.

No technology has angered me more in the last few years than AMP. I have literally switched my main search engine just so I don't have to deal with AMP.

At no point have I ever appreciated AMP. It has only been a disadvantage.


How could email possibly be more performant? Its just a few blocks of text. I click on the email and it loads instantly because its already downloaded.


I think you’re looking at performance all wrong.

How long until the sender’s ad targeting subcontractors know you read it?

How long until they can act on that information to manipulate you into sending cash, voting to sabotage the government, or otherwise act against your own interests?

With static email, all of these latencies are in the days, or at least hours. With amp email, it can be accomplished in 100’s of milliseconds.


Google's mail and calendar experience is already horrible and confusing. This is gonna just make it worse.


The only thing that needs to be more performant in my email experience is the gmail UI.


Google doesn't have a monopoly on email. Check your (personal) inbox - I'd bet the majority of emails on the first page are not from Gmail users but rather from various companies and organizations. Even among individuals, while many people get their email from Google, the most popular client (which is what's relevant in this case) is the mail app on the iPhone. Microsoft and Yahoo still have decent market share as well, though much less than I thought before I started writing this with 12-18% between them according to my not-super-rigorous Google search.


> and continued forward with a program that nobody wants

Don't presume to speak so for others.


It's an obvious generalization. Everybody else gets what he meant, don't you?


Seems the majority gets it.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: