Convopage
See the entire conversation
76 replies and sub-replies as of Apr 24 2017
probably sounding pedantic, but URLs that obfuscate ownership are a problem. imagine 2017 without 2016's fake news or podesta spearphishing.
a fan of AMP's creators and mission, but i don't think better web UX is worth a "repeal and replace" of its fundamental ownership system.
fwiw sites can implement their own URL schemes
I see your kool-aid and I’m not drinking it 😋 cc @jedschmidt
ooh, punchy.
developer.apple.com/library/conten… > trying to register random URL schemes
computer people never accidentally cause naming conflicts, right?
Fake urls
We agree that the URLs aren’t ideal and want to get rid of them as fast as we can. As I said going it: Various initiatives in the works.
Regarding fake news:
I’m optimistic about opportunities in AMP to help with that problem on Google surfaces.
I'm resisting an urge to troll you.
I think it passed.
sure, what arbitrary identifier that does not suffer the same draw backs will we replace them with? sorry if i missed that part
i'm cool with "not ideal". this is actively harmful. and for what, privacy? seems like innovation at the wrong end. UAs should drive that.
Bad id (too old): 2792926893
Again: I completely agree that the URLs should be fixed and we will. There is no argument. You don't need to convince me, because I agree.
Speaking of that tweet: AMP's URL scheme directly addresses the concern by being resolvable without a database.
The URL space can be maintained forever at minimal cost with as little as a .htaccess config.
Don't assume I haven't thought things through, because I have. See also #4 here
ampproject/amphtml
amphtml - AMP HTML source code, samples, and documentation. See below for more info.
github.com
i make no such assumption. i just disagree that AMP's noble mission is more important than the fundamental ownership model of the web.
I understand. It's a trade-off and I can absolutely understand coming out on the other side of the conclusion.
Privacy: Anon pre-rendering. UAs cannot do that. Needs a proxy.
okay, cool, so don't pre-render. those who would give up essential accountability to purchase a little performance deserve neither.
Would you also like me to nominate Eric Holder to supervise the process? The short answer is: yes.
Actual work is happening. Except I'm on 3 weeks vacation / JSConf organization trip.
Case in point, RT's AMP pages are/were (can't find one now) very minimally branded. Google name is bigger. trib.tv/2017/03/31/amp…
does this really need explaining?
(if so, @triblondon's post explains well the issues of relegating publishers to a google.com subpath: trib.tv/2017/03/31/amp…)
AMP: breaking news
Google has made much of their Accelerated Mobile Pages project as a solution to bloated websites and frustrated users. But could AMP actually be bad news for the web, bad news for news, and part of a trend of news distribution that is bad for society in general? I didn't start out as strongly an
trib.tv
From experience many of his concerns aren't issues at all imho, but the others in itself justify his alarm
i'm cool with subsetting web tech for performance, but the enforced obfuscation of ownership bothers me a lot.
Agree. I was never sold on the CDN requirement which is the main cause of confusion.
Trying a few things to make it better
- link-rel-sharelink
- redirecting bots to origin
- trying to get Twitter to rewrite to origin
More long term we'll get rid of the google.com/amp but it'll require some new primitives in the web platform.
these feel like hacks to treat the symptoms. i guess i don't understand why the CDN isn't opt-in. seems that would obviate so much gnashing.
It is opt-in for the doc publisher. Simply remove the amp tag from the amp doc and it isn't used.
You sometimes have to push the platform and it comes with short term pain. Otherwise the native apps just win.
this strikes me as pulling the platform more than pushing it.
Both. And both are needed.
AMP in Google iOS native app: no URL problem, largely same tech.
It's a double-edged sword. Advent of AMP meant we paused our regular article perf project at New Yorker to chase the new shiny thing
I hope you're not suggesting it's a binary choice between AMP and native apps :)
so AMP is opt-in, no? i don't understand why the cache and the format need to be tightly coupled. seems the costs outweigh the benefits.
Both are opt-in. Substantially documented what benefits the cache brings. Primarily privacy safe pre-rendering.
Can you point me to an AMP publisher that doesn't use the cache? I want to see the difference from a user perspective, but haven't seen any.
It just a link, no pre-rendering, no swiping, just another web document. AMP is just a JS library like any other.
Maybe I mis-understood. You're saying AMP pages can opt-out of CDN part (use my own) - and still get same treatment in search/carousel etc?
No, of course not. The cache is required for pre-rendering for privacy reasons. Without the cache, it is just another web document.
Ok, so no CDN opt-out. Am also unclear on privacy benefits (just a https thing?). Would gladly take web perf hit to avoid CDN & URL issue
That's not opt-in.
Sure, you put it there in the first place. It has no other side effect besides inclusion in cache.
And the amp symbol in the search result?
Requires the opting into cache / pre-rendering.
So the cache isn't opt-in
There are two side effects, getting the amp symbol and also the cache. Not one side effect.
And since people want the symbol, you are twisting the words when you say the cache is opt-in.
Not for the AMP specific experience. Reasons explained above. Won’t go into details again.
The amp specific experience is getting the amp symbol in the search result next to your site
If privacy is the reason for the opt-in, a 3rd party like us could enforce that and let people use their own domains.
It isn’t out of the question, but changes nothing about the google.com top level. Solution has more facets.
What do you mean changes nothing?
But enabling AMP (which will enable the CDN) is completelt opt in. Right? Or I missed something....
As long as CDN hosting is part of package then URL problem persists. You can control all 3rd parties
"can't"
No. I know why, I'm surprised non-media folk know too
I came here to ask "why?" too, so yes, yes it does need explaining.
I'm also wondering why - what's wrong with amp urls
they obfuscate ownership.
It’s often difficult to get the real URL from an AMP site