►
From YouTube: OpenJS Foundation AMA- AMP Project
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
and
we
are
live.
Thank
you
everybody.
So
much
for
joining
us
today
for
our
openjs
foundation.
Ask
me
anything.
This
month,
I'm
really
excited
to
be
featuring.
The
amp
project,
tsc
amp
project,
joined
the
openjs
foundation
as
a
growth
project
this
summer.
We're
super
excited
to
have
them
as
part
of
the
big
family,
and
today
we
will
have
nina
from
the
amp
project,
moderating
our
ama,
but
before
I
hand
it
over,
I
just
wanted
to
give
folks
a
quick
update
on
how
you
can
ask
your
questions.
A
B
Thanks
rachel,
as
rachel
mentioned,
my
name
is
nana
rei,
singhani
and
I'm
a
pm
on
the
amp
project.
I
have
the
absolute
honor
of
actually
moderating
this
q
a
but
I'll
hand
it
off
to
the
tsc,
which
is
our
technical
steering
committee
to
introduce
themselves
and
I'll
go
across
the
screen
david.
Do
you
want
to
kick
us
off.
C
Hi
I'm
david
strauss,
I
joined
the
mtsc
at
I
guess.
We
mostly
joined
at
the
formation
of
the
tsc
and
I
primarily
work
on
the
drupal
project
and
on
an
a
website
hosting
platform
that
delivers
many
sites
for
that
use.
Amp
pages
and
I'm
happy
to
be
answering
questions
today
about
the
direct,
my
own
perspectives
on
the
direction
of
the
project.
D
Hi
I'm
chris
papasian.
I
also
joined
the
tst
at
formation
with
david
I've
been
I'm
a
software
engineer
at
pinterest
and
I've
been
using
amp
since
I
guess
late
2016.
E
F
Malta
hi
I'm
malta,
I,
together
with
dima,
I
originally
made
amp
and
working
at
google
leading
leading
the
team.
That's
working
on
it
there
full
time
and
obviously
also
a
member
of
the
tsc
since
it
started.
B
Good
to
know
it
comes
with
benefits.
Kasiana,
do
you
want
to
introduce
yourself
next.
G
Hi,
I'm
cassiano
mclanahan,
I'm
a
product
manager
at
axios.
We
launched
a
basically
an
all
amp
site
in
february
2020.
I
am
the
newest
member
to
the
tsc
I
just
joined
after
we
launched
our
site
and
I'm
very
excited
about
the
technology.
H
I
Hey
everyone,
I'm
rudy
galfie,
I'm
a
product
management
lead
at
google,
focusing
on
amp
and
I've
been
with
the
tsc
since
we
got
that
started
back
in
2018
with
the
project
since
we
started
it
back
in
2015.
B
Right,
that's
everyone!
That's
here
today,
just
to
get
folks
started.
Since
you
know
this
is
still
part
of
we
had
amp
fest
yesterday
I
was
just
curious.
What
was
the
one
topic
you
were
excited
to
learn
about
or
just
have
our
audience
learn
about
going
into
amp
fest
and
what's
the
one
thing
you
actually
learned
at
amfast.
D
Amp
fest
yesterday,
I
actually
didn't
make
any
of
the
talks
yesterday,
but
I'm
excited
about.
D
Let's
see
what
am
I
most
excited
about,
amp
in
the
direction
of
amp,
I
think
generally,
one
of
the
really
cool
things
about
amp
is
how
a
lot
of
the
technology
that
started
is
amp
only
is
really
making
it
into
the
web
ecosystem,
and
so
we're
particularly
excited
about
science
exchanges
and
how
that
might
help
us
improve
page
load
experience
and
even
though
it
doesn't
get
a
lot
of
press
with
amp,
it's
more
part
of
the
chrome
ecosystem.
B
B
C
C
And
I
feel,
like
pixie,
just
puts
stadium
lighting
on
the
path
in
the
sense
that
it
provides
all
the
more
ability
to
winnow
down
onto
the
issues
that
are
actually
affecting
a
site
and
actually
get
to
the
heart
of
delivering
not
just
pages
that
are
amp
compliant
for
delivery.
C
B
Yeah
as
someone
who
worked
on
it,
we're
incredibly
excited
about
the
fact
that
you
know
this
pushes
the
amp
promise
for
page
experience
even
further.
It's
like
we
promise
you
that,
yes,
in
a
very
large
amount
of
cases,
you'll
be
you'll,
be
set.
You
don't
have
to
do
anything
just
as
long
as
you're
on
the
amp
path,
but
in
the
few
cases
where
you
need
to
like
go
implement
web
development
best
practices
where
the
amp
specific
actions
you
can
take
there.
B
We're
really
excited
by
that
and
the
fact
that
you
know
you
have
this
exit
where,
if
you
really
don't
understand
what's
going
on
or
you
really
can't
understand
why
your
page
isn't
performing
well,
you
have
that
route
back
to
the
amp
project
or
like
the
performance
working
group,
so
yeah.
If
folks
want
to
use
that,
that's
it
self
plug
app.dev,
slash
page
dash
experience.
B
You
should
absolutely
go
test.
Your
amp
page
today
and
let
us
know
if
you
have
any
feedback
anything
else
that
folks
want
to
talk
about
about
something
they're,
proud
of
that
the
project
achieved
in
2020.
E
I
wanted
to
bring
up
also
red
vitals.
We
were
working
quite
a
bit
on
them
this
year
and
it's
a
very
exciting
direction.
It
feels
like
amp
is,
has
done
a
lot
of
work
in
this
area
and
we
also
are
going
to
have
a
lot
about.
We
also
have
a
lot
a
lot
to
do
next
year
to
to
make
sure
that
the
experience
on
the
web
just
raises
to
a
new
bar
to
new
height.
I
So
this
is
kind
of
a
new
thing,
and
it's
also
like
a
bit
of
what
you
learn
by
attending.
I
guess
virtually
an
event
like
amp
fest
for
me,
which
is
like
getting
to
see
the
usage
of
amp
by
different
people.
So
you
know
whether
it's
like
some
of
the
work
you
know
in
in
the
wordpress
space
or
things
like
camp
for
email
usage
like
these.
I
These
are
things
that
I
don't
often
get
to
see
each
day,
especially
things
like
email,
where
you,
like,
you
literally
kind
of
have
to
be
something
email
to
kind
of
get
the
experience
you
can't
just
like
go
to
a
link.
So
so
I
think
that's
what's
cool
about
things
like
amp
fest
is
getting
to
kind
of
shine,
a
light
on
some
of
the
use
cases
and
adoption
that
we're
seeing
amongst
people
to
help
like
you
know,
make
that
use
case
of
email
better,
so
that
would
that
would
kind
of
be
a
bright
spot.
I
For
me,
the
other
thing
that
I
think's
advanced
a
lot
over
the
past
year
has
been
stories.
So
I'm
you
know
maybe
we'll
talk
more
about
stories
here
in
the
session
too,
but
that's
another
call
I'd
have
is,
I
think
stories
is
like
a
super
cool
product
and
it's
it's
great
to
see
the
strides
that
that's
been
taking
over
over
the
course
of
2020.
B
I'll
I'll
queue
up
a
question
from
youtube
ishaan
on
and
asked
one
of
the
biggest
concerns
about
amp
is
that
it
was
a
google
project,
but
they're
excited
to
see
that
you
know
bing
also
support,
and
in
that
way,
can
the
tsc
give
an
update
on
what
other
popular
platforms
actually
support,
amp,
especially
with
privacy,
preserving
pre-rendering.
F
I'll
take
this
one.
I
think
that
microsoft
and
google
are
the
only
one
that
are
doing
pre-rendering,
although
the
same
technology
is
basically
what
enabled
and
for
email,
but
so
from.
There
are
obviously
other
platforms
that,
like
to
amp
document.
You
know,
I
think,
the
one
I
personally
use
the
most
is
twitter.
F
So
so
there's
I
think
it's
a
pretty
broad
base
actually,
and
I
think
the
it's
definitely
interesting
to
see
how
how
that
mechanism
that
kind
of
was
was
designed
to
you
know,
be
privacy
preserving
and
that
it
like
tightly
controlled
where
requests
are
being
made
and
when
would
eventually,
you
know
you
enable
use
cases
like
and
for
email
where,
where,
like
user
expectations,
are
very
different
compared
to
the
web,
and
we
were
able
to
kind
of
fit
kind
of
the
web
programming
model
into
something
that
that
matches
users,
expectation
and
emails.
B
And
then,
to
that
end
like,
since
we
brought
up
email,
we
know
that
folks
at
yahoo
just
launched
their
developer
preview
as
well
for
amp
for
email
and
we're
excited
that
more
like
esps
and
more
senders
are
also
supporting
it.
We
had
we
had
to
talk
at
amp
fest
about
some
senders,
we're
seeing
success
with
amp
for
email,
and
we
also
announced
that
salesforce
marketing
cloud
would
be
launching
support.
B
I
believe
in
q1
of
2021,
so
we're
seeing
adoption
for
different
formats,
also
in
a
bunch
of
places,
since
rudy
brought
up
stories,
I'll
jump
off
of
that
and
ask.
What
do
you
think
is
the
most
critical
piece
that
the
amp
project
can
contribute
to
actually
see
things
like
web
story
c,
like
amazing
scale,.
H
I
can
I
can
try
to
take
this
one
so
as
I've
been
super
impressed
with
stories
since,
since
the
beginning,
I've
like
I've,
expressed
even
internally
and
microsoft,
like
a
lot
of
interest
for
using
the
platform,
and
I'm
super
happy
that
actually
google
started
pushing
more
stories
and
actually
has
a
dedicated
experience
to
stories,
and
that
makes
it
easier
for
any
developer
like
any
company
to
go
ahead
and
create
a
an
experience
based
on
stories.
H
Right
and
that's
super
super
really
because
it's
so
complex
to
interaction
models,
all
the
features
and
that's
all
given
by
amp
to
to
to
the
developer,
to
to
just
use
it.
So
it
simplifies
the
developer
cycle
and
if,
if
you
are
a
smaller
developer,
like
a
smaller
company
that
wants
to
leverage
that
you
don't
need
to
create
all
your
infrastructure
to
do
that,
it's
all
given
to
you.
So
it
scales
much
much
better
and
it
brings
the
richness
that
it's
super
rare
to
see
and
anywhere
else
and
in
any
component
or
any
framework.
F
To
add,
is
you
know?
It's
just
specifically
talked
about
like
what
amp
can
do,
and
I
think
it
has
a
little
bit
of
a
different
role
compared
to
the
website
space
and
that
the
the
main
customer
of
of
of
amp
in
the
web
story.
Space
is
actually
the
makers
of
the
tools
and
and
the
powerful
thing
is
that
there
are
these,
like
no
code,
specific
tools
that
allow
people
to
to
make
these
stories.
F
I
One
thing
I
will
add,
though,
that
I
think
super
cool
is
the
story
player
that
is
being
built
out
for
stories.
So
you
know,
I
think,
when
stories
first
launched,
it
was
basically
like
okay,
this
is
a
web
page
and
it
like
it
renders
in
a
certain
way
it
has
certain
sort
of
navigational
like
behaviors
to
how
it
works,
interaction
models,
but
it
was
kind
of
just
like
a
standalone
thing
and,
like
you,
you
know
what
I
think
is
cool
about
the
web
player
or
the
story.
I
Player
project
is
that
we
can
like
have
a
better
way
for
sites
to
think
about
sort
of
integrating
stories
to
be
displayed
as
part
of
like
their
core
flows,
and
so
I
think
that
that's
like
gonna
be
something
that
helps
like
make
the
mental
model
sort
of
click
more
for
for
people,
and
it
will
hopefully
like
enable
you
know
better
experiences,
especially
just
directly
on
the
the
origin
of
the
site,
to
be
able
to
kind
of
facilitate
navigation
and
provide.
I
Like
you
know,
you
know
more
layers
of
customization
and
be
able
to
like
handle
presentation
of
stories
on
websites.
B
Anything
else
that
folks
want
to
mention
on
the
stories
fun,
otherwise
I'll
flip
to
email,
because
I'm
curious
about
this.
So
what's
one
use
case
that
folks
actually
want
to
see
an
amp
for
email
for
like
what
one
problem
would
you
like
and
for
email
to
solve?
For
you
be
productivity,
be
it
you
know
getting
food
delivery
or
really
anything
in
the
consumer
or
enterprise
based.
F
I
have
one
so
I
mean
I've
been
I've
been
where,
where
for
me
like,
just
personally,
it
has
been
really
powerful
is
when,
when
it
when
it
shortcuts,
workflows
it's
really
in
the
enterprise
space.
So
I
get
a
lot
of
you
know:
common
notifications
from
google
doc
and
being
able
to
like
see
more
context
in
line
see
the
latest
comment
in
line
instead
of
just
the
email
in
reverse
order
has
just
been
really
powerful
and
then
not
having
to
kind
of
jump
back
into
the
relatively
slow
loading
document
actually
to
the
reply.
F
It
was
powerful
and
I
think
recently,
they've
they've,
looked
also
into
into
like
approving
of
of
of
permission
requests
right,
which
is
another
thing
where
you
can
just
kind
of
shortcut
that
process
and
and
so
since
you're
asking
what
I
would
like
to
see
like
just
again
like
me
personally,
like
I
get
a
lot
of
github
notifications
and
if
I
could,
you
know-
and
I
like
to
use
email
for
them
because
for
me,
my
you
know,
I
live
in
my
inbox
as
opposed
to
like
the
the
you
know,
github
inbox
for
notifications.
F
Is
you
know
I
mean
there's
other
people
who
like
that,
but
like
that's,
not
what
I
do,
and
so
I,
if
I
could
do
more
things
in
my
in
my
email.
So,
for
example,
if
I
have
a
code
review
and
I
get
like
the
you
know,
done
done
done
done
reply
and
I
trust
the
person.
I
would
like
to
be
able
to
say
like
approve,
right
and
then
be
done
and
and
and
and
don't
have
to
jump
back
into
github
click
like
15
buttons
and
and
do
the
work.
G
As
a
as
a
publisher,
I
think
one
of
the
things
that,
like
I'm
personally
very
excited
about
is
axios,
has
a
really
large
email
newsletter
business.
It
seems
a
little
outdated,
but
it
turns
out
that's
actually
kind
of
a
great
way
to
get
your
news.
G
The
problem
is
that
when
we
send
out
an
email,
we
have
no
idea
if
you
live
on
the
east
coast
of
the
west
coast,
and
so
if
we
send
an
email
at
you
know:
5
30
a.m,
east
coast
time
and
by
the
time
you're
actually
reading
that
on
the
west
coast,
it
may
be
six
or
seven
hours
out
of
date,
and
so
I
think
that
that's
actually
a
really
nice
way
to
start
to
think
about
how
you
can
pull
dynamic
content
into
like
what
previously
has
been
a
very
static
platform
and
and
kind
of
make
yourself
a
little
time
zone.
G
E
For
me,
you
know
once
19
is
over.
I
would
like
to
be
able
to
make
decisions
on
what
restaurant
me
my
friends
go
to
and
what
exact
time.
D
Yeah,
it
seems
like
a
good
fit
for
anything.
That's
transactional.
The
the
cynic
in
me
says
unsubscribe
would
be
a
good
use
case,
but
anything
that's
kind
of
a
clear
action
that
you
can
take.
You
know
extending
specific
discrete
actions
from
a
product
experience
into
email
seems
like
a
great
use
case.
C
I'm
hoping
it
means
I
get
to
unsubscribe
a
lot
less
in
the
sense
that
we
can.
You
can
basically
send
something:
that's
almost
like
an
evergreen
email
that,
like
here's,
the
email
that
represents
the
state
of
your
order
and
be
able
to
provide
different
interactions
and
capabilities
in
it
and
in
ways
where
I
don't
necessarily
have
to
get
a
pile
of
transactional
emails
for
each
interaction
with
the
site.
D
B
Right
one
other
question
was
right:
so
the
new
york
times,
along
with
some
other
publishers,
released
a
proposal
for
content,
aggregation
technologies
and
like
a
framework,
how
to
think
them
through?
Does
the
trc
have
any
opinions
here
or
thoughts
for
folks
who've
like
actually
had
the
chance
to
like
consume
it
so
far,.
F
I'll
do
a
first
answer
and
then
maybe
other
stuff
have
more
to
say.
First
of
all,
I
think
it's
really
important
to
say
that
there's
no,
the
tsc
as
an
entity
does
not
have
an
opinion
about
this,
because
this
came
out
on
monday
and
our
next
regular
meeting
is
next
wednesday
and
we,
you
know,
I'm
not
sure
it's
on
the
agenda
there,
but
like
we
certainly
haven't
discussed
it
right
and
most
of
us
probably
haven't
read
it.
I
I
mean
I
personally
also
have
only
only
skimmed
it.
F
I
think
my
main
reaction
is
first
of
all,
I
have
to
say
I've
tweeted
this
five
years
ago
that
the
original
name
of
of
amp
was
cat
for
content,
authoring
toolkit
and
we
were
not
allowed
to
to
use
it
because
our
lawyers
were
afraid
of
getting
sued
by
caterpillar
and
I'm
just
very,
very
disappointed
because
you
know
the
internet
is
made
of
cats
and
it
would
have
been
a
really
good
name.
So
so
I'm
I'm
very
excited
about
the
name.
F
They
they
found
a
better
backroom
than
content
authoring
toolkit,
and
it's
it's
great.
So
that's
that's
good
and
and
and
so
the
the
second
part
to
my
reply,
you
know
a
little
bit
more
in
depth.
Is
that
I
I
like
so
I
I
think
this
is
generally
a
good
idea
right,
like
I
I'm
I'm.
I'm
excited
the
new
york
times
working
on
this.
I
like
I
mean
they
haven't
reached
out
to
us,
so
that
would
be
good
to
have
a
conversation.
F
I
I
certainly
disagree
with
some
of
the
representations
that
are
being
made
in
the
document,
but
you
know,
I
think,
that's
fine
and,
and
you
can
people
can
iterate
on
it.
I
think
it's
you
know,
especially
since
it's
concretely
names
like
different
technologies,
like
apple
news
and
facebook
and
articles.
You
know
I
think
amp
is
different.
F
It
has
a
tc
right
that
isn't
just
like
one
proprietary
company
there's,
you
know
representation
for
microsoft
to
have
literally
their
own
major
integration
and
and-
and
we
have
like
meetings
like
this
one
right
like
you-
can't
go
to
the
apple
news
committee
live
stream.
That
does
not
exist
right
and
then
you
can't
even
like
probably
talk
to
anyone
there
right
like
so
it's
it's
very.
It's
like
fundamentally,
financially
different,
and
so
honestly,
like
that's
just
me
personally,
the
main
thing
I'm
worried
about
is
like,
I
think
we're
most
likely.
F
The
tsc
is
going
to
be
open
to
this
and
say
like
hey:
let's
have
a
conversation
at
the
very
least
right
like.
Why,
wouldn't
you
say
say
yes
to
this,
but
if
you
know
there
are
no
similar
signals
from
other
members
of
of
the
of
the
you
know,
platform
aggregator
community,
like
those
names
in
the
documentary
apple
on
facebook,
then
I
mean
I'm
not
super
convinced
this
is
going
to
be
the
most
productive
process
right.
F
You
know
outcome
where
you,
you
know.
You
complain
about
13
standards
and
you
have
14..
So
I
think
that's
one
of
the
thing
I'm
worried
about,
but
you
know
nevertheless,
I'm
pretty
optimistic
that
this
is
a
good.
G
One
quick
thing
you
know,
I
think
what
malta
said
is
salient
for
this
point.
You
know,
I
think
what
is
helpful
as
a
publisher
is
that,
like
I
do
think
that
there
are
parts
of
the
cat
document
that
identify
real
problems
that
we
do
have,
and
so
I
think
it's
really
helpful
to
at
least
start
that
conversation
and
see
whether
there
are
ways
that
we
can
make
it
better.
G
You
know,
in
general,
publishers
do
have
pretty
small
dev
teams,
and
you
know
we
are
then
asked
to
create
this
kind
of
bespoke
formats
to
be
able
to
sort
of
appear
in
all
these
various
distribution
platforms.
I
think
one
of
the
real
benefits
that
that
you
know
that
we
saw
in
in
amp
is
that
it's
also
sort
of
creating
a
better
user
experience
it's
accessible
to
anybody
on
the
web,
not
just
somebody
participating
in
kind
of
the
walled
garden
ecosystem
of
one
of
these
other
aggregation
platforms,
and
so
for
for
us.
G
I
think
that
was
sort
of
what
made
it
like
an
attractive
standard
to
kind
of
adhere
to.
So
I
think
that,
like
it's
certainly
a
worthwhile
conversation
to
to
have-
and
would
you
know
is-
is
at
least
a
proposal
for
addressing
a
real
pain
point.
E
I
wanted
to
add
that,
from
a
beginning,
we
really
were
trying
to
make
amp
as
unbearable
as
possible,
and
it's
you
know,
obviously
a
lot
more
complicated
than
just
being
able
to
display
images
and
maybe
cache
them
and
as
an
example
in
our
access
of
subscription
tools.
E
As
an
example
here,
google
news
can,
when
publisher
option
can
actually
replace
checkout
flow
to
be
native
on
android
platform
from
you
know,
instead
of
running
some
sort
of
a
checkout
platform
in
a
which
probably
would
fail
now,
there's
a
lot
of
this
kind
of
features.
We've
already
had
a
fairly
solid
experience
with,
so
I
think
it's
definitely
worth
having
a.
B
Conversation
so
speaking
of
conversations-
and
you
know
thinking
about
how
to
involve-
I
mean
more
open
standards,
work.
What
are
problems
that
the
tsc
is
actively
thinking
about
going
into
the
new
year.
I
know
it's
around
time
where
organizations
are
thinking
about
2021.
B
Hopefully
it
happens
and
we
don't
just
get
a
repeat
of
2020.
but
yeah.
How?
How
are
folks
thinking
about
the
new
year
and
any
efforts
that
the
amp
project
should
be
picking
up.
C
I
think
on
deploying
the
infrastructure
at
origin,
and
but
it
provides
enough
benefits
from
a
content
loading
perspective,
especially
as
part
of
the
new,
the
increasingly
leveled
playing
field
represented
by
core
web
vitals
that
I
I
don't
know
that
it's
our
unique
burden
to
shoulder,
but
it
I
think
that
it's
a
potential
barrier
to
performance
capabilities
that
the
next
year
may
be
a
bit
make
or
break
for
in
terms
of
adoption.
F
Can
I
really
quickly
say
that
we're
in
the
awkward
conversation
where
the
person
asking
the
question
is
the
most
qualified
person
to
answer
it
so
always
feel
free
to
also,
you
know,
give
me
up.
D
I'd
echo
david,
I
mean
okay,
sound
exchange,
adoption,
seeing
where
that
goes,
we've
struggled
with
our
own
kind
of
adoption
at
pinterest
and
trying
to
figure
out
how
that
that
fits
in
so
and
then
I
think
that
combined
with
core
web
vitals
is
really
interesting,
core
web
vitals
rolled
out,
but
it's
been
stated
that
it's
gonna,
you
know
it's
the
metrics
that
are
part
of
core
web
vitals
today
are
not
necessarily
what
are
always
gonna,
be
part
on
how
that's
composed
so
seeing
how
that
kind
of
changes
over
time
and
evolves
with
the
web
is
super
interesting
is
staying
up
to
speed
on
that
and
generally
seeing
how
amp
and
and
the
metrics
that
we
think
about
as
the
performance
metrics
how
they
you
know.
D
The
interplay
between
the
two
ecosystems
is
really
interesting.
F
One
thing
maybe
demo
can
later
give
some
technical
details.
I
think
bento
continues
to
be
super
interesting
and
something
I
learned
next
week
next
year.
I
think
what
one
one
area
of
research
that
I've
I've
heard:
chatter
about
which
not
hasn't
risen
to
the
level
of
a
proper
project.
It's
just
kind
of
trying
to
compile
way
more
parts
of
amp
and
just
be
just
be
thinner
and
less
of
it.
F
F
B
And
kind
of
building
into
like
then
into
next
year's
planning
kind
of
a
question
which
sectors
or
use
cases
are
the
highest
priority
for
the
mtsc,
it
seems,
like
content
is
number
one.
E-Commerce
seems
to
be
number
two,
but
there
weren't
any
e-commerce
case
studies
featured
at
amfest,
so
we
did
have
some
e-commerce
case
studies
very
specifically
in
like
the
email
section
section
as
well,
because
I
think
there's
a
lot
of
usefulness
there,
such
as
for
abandoned
cart,
emails
or
just
account.
B
Verification
like
one
of
the
use
cases
I
am
really
excited
to
see
is,
if
I
get
an
email
saying
verify
account,
I
shouldn't
have
to
go
somewhere
else,
go
to
another
web
page
confirm
and
just
follow.
300
steps
there
to
just
be
able
to
click
within
the
email,
but
yeah.
How
do
folks
do?
Does
the
tse
think
of
that
we're
going
to
continue
focusing
on
content
publishers
or
do
we
want
to
expand
into
more
verticals
or
just
keep
our
presence
and
more
verticals,
and
I
can
also
express
my
opinion
here.
B
Cool,
I
will
in
that
case
I
will,
I
think,
going
into
2021
the
the
one
thing
I'm
really
excited
about
is
page
experience
and
quarterback
vitals
and
how
I
can
really
push
the
boundary
there.
I
think
we
announced
yesterday
that
about
60
of
amp
domains
passed
the
corvette
by
those
criteria
compared
to
like
12
percent
of
non-amp
domains,
where
passing
is
like
at
75
percentage
of
pages,
passing
the
criteria,
I'm
not
happy
with
anything
less
than
100.
Personally
speaking,
so
I
think
like
we
have.
B
We
have
some
ways
to
go
there
and
I'm
really
excited
to
see
the
team
push
that
so
that,
regardless
of
what
vertical
you're
coming
in
from
as
long
as
you
pick,
what
part
of
amp
really
you
will
benefit
from.
So,
for
example,
you
can
pick
the
take
an
amp
carousel,
because
you
have
a
lot
of
cls
issues
and
just
have
a
bento
amp
page.
B
But
really
you
can
pick
and
choose
what
pits
of
amp
work
for
you
to
help
you
solve
for
your
corporate
vitals
or
your
page
experience,
metrics
and
problems
so
that
that's
something
that
I'm
really
excited
about
and
that
allows
us
to
be
mostly
vertical
agnostic
as
well.
Here.
E
I'm
actually
kind
of
curious
to
see
how
web
stories
could
change
e-commerce
and
how
what
role
they
could
play,
because
I
feel
like
every
time
I
see
these
nice
stories.
I
almost
always
want
to
buy
something.
B
B
Oh
yeah,
when
that's
possible,
2022
or
road
trips
folks,
can
do
those
right
now
question
from
youtube.
Will
websites
need
to
maintain
duplicate,
implementations
of
articles
that
is
html
and
amp
version
to
get
picked
up
by
publishers
or
I
assume
platforms?
I
have
a
very
strong
stance
on
paradigm
versus
ampersand
folks.
C
I
I'm
actually
really
interested
in
the
direction
of
this
over
the
next
couple
years,
in
the
sense
that
we
have
two
different
kind
of
paths
that
are
emerging
now,
one
of
them
being
the
more
amp
first
direction.
Where
you
stay
completely
on
the
rails.
C
You
take
advantage
of
all
of
the
performance
benefits
of
completely
embracing
the
framework,
possibly
even
as
your
canonical
framework,
and
then
we
have
this
other
kind
of
perspective
around
things
like
bento,
amp
and
cor
and
corweb
vitals,
where
there's
more
of
a
sliding
scale
between
different
functionality
and
attributes
of
the
page
and
the
effects
of
the
bat
of
the
balance
between
capabilities
versus
performance
impacts,
and
I
think
that
that
will
affect
this
a
lot.
C
One
of
the
stances
that
we
have
well
represented
here
is
is
the
idea
of
taking
amp
first,
which
is
to
to
build
the
pages
completely
in
amp
and
not
have
a
of
a
sort
of
right.
So
I
I
almost
chafe
at
the
the
idea
of
regular
html,
because
because
amp
is,
is
regular,
html
in
a
sense,
but
it's
just
a
restricted
subset
of
it,
and
that
can
be.
C
That
can
be
a
great
way
to
not
have
to
maintain
duplicate
articles,
but
I'm
definitely
like
going
to
be
watching
how
much
people
also
choose
to
say.
Don't
like
do
things
that
are
using
the
amp
toolkits
and
are
still
focused
on
performance,
but
not
necessarily
passing
the
validator.
I
Yeah,
I
agree
with
that,
like
there's,
never
been
explicit
need
to
use
like
a
duplicate
implementation
of
amp,
alongside
like
a
non-amp
version,
but
what
we
found
over
several
years
is
that
there
is
in
practice,
kind
of
some
barriers
to
really
getting
there.
So
I
think
a
lot
of
the
work
and
like
the
things
that
I'm
excited
about
heading
into
2021,
are
the
approaches
by
which
will
make
amp.
I
I
Where
you
can,
you
can
get
there
over
time
by
using
like
parts
of
amp
and
and
that
you're
sort
of,
like
you
know,
while
not
having
like
a
fully
valid
amp
implementation,
you're
starting
to
be
able
to
get
some
of
the
benefits
along
the
way,
and
you
can
potentially
like
graduate
fully
up
the
path
to
a
valid
amp
page.
I
mean.
C
I
It's
worth
noting
like
one
of
the
really
difficult
things,
and
I
think
a
lot
of
the
reason
that
there's
sort
of
this
paired
pattern
of
adoption
is.
It
makes
it
a
lot
easier
to
kind
of
reason
about
it
first
and
be
able
to
experiment.
C
I
You
know
with
investing
in
amp,
and
so
you
know,
I
think,
we've
recognized
that
through
feedback
from
the
community
over
the
years-
and
I
think
that
there's
like
a
lot
of
projects
now
that
are,
are
really
squarely
focused
on
and
trying
to
address
this
pain.
I
So
I
you
know
like
like
david
and
others
have
expressed,
I'm
really
excited
to
see
how
that
plays
out
and
would
love
for
the
community
to
continue
giving
us
feedback
as
we
as
we
go
down
that
path,
because
at
the
end
of
the
day,
like
you
all,
who
are
really
you
know,
taking
time
day
in
and
day
out,
to
invest
in
building
up
the
sites
and
the
pages
we'll
have
the
best
feedback
that
we
can
take
with
us
to
figure
out
what
to
do.
G
I
think
our
experience
might
be
also
kind
of
salient
in
here.
You
know
axios
kind
of
took
a
different
path,
which
was
that
we
were
going
to
be.
G
You
know
fully
rebuilding
our
site
and
kind
of
had
this
opportunity
to
make
a
choice
of
you
know
which
technologies
we
really
wanted
to
bet
on,
and
we
had
previous
sort
of
previously
done
like
a
little
experiment
and
like
set
up
an
amp
site
for
the
previous
iteration
of
axios
and,
had
you
know,
seen
clear
user
benefits
from
that
and
decided
that,
like
we
knew
that
amp
was
going
to
be
part
of
the
solution,
and
so
we
really
ended
up.
You
know
centering
it
through
our
development.
G
I
think
that
now
we
are
that
we
are.
We
have
a
fully
amp
site.
We
are
finding
some
of
those
pain
points
and
I
will
tell
you
I
am
I
raised
my
hand
a
lot
here
to
like
have
this
conversation.
That's
part
of
why
I
wanted
to
join.
The
tse
was
to
to
you
know,
help
help
us
navigate,
but
also
help
other
publishers,
kind
of
navigate.
The
you
know
places
where,
like
amp
is
both
great,
but
there
are
places
where
it
can
be
a
little
bit
of
a
struggle.
G
You
know,
I
do
think
that
the
I
think
it
is
easy
to
see.
The
places
where,
like
you
know
at
this
point,
where,
like
amp,
can
be
a
little
bit,
make
our
build
a
little
bit
more
complex,
but
I
do
think
that
there
are
really
strong
benefits
to
the
user
experience
and
I
think
that
those
are
really
highlighted
by
the
corporate
vitals
statistics.
G
So
what
we're
trying
to
figure
out
is
like
how
can
we
figure
out
how
to
how
to
kind
of
fully
make
this
implementation
work
for
us,
and
I
think
that
that
is
the
you
know
broad
direction
that
that
the
tsc,
I
think,
is
also
engaged
in.
B
So
I'll
go
into
the
next
question,
since
we
did
the
word
pain
points
it
was
measure
was
mentioned.
What
are
some
and
like?
I
think
this
is
more
asking
you
all
to
respect
on
your
reflect
on
your
own
personal
experiences
as
web
developers
or
folks
working
with
web
developers.
What
are
some
of
the
most
common
web
development
pain?
Point
that
your
teams
have
individually
experienced
and
how
can
frameworks
or
how
can
amp
help.
B
D
Kind
of
just
piggybacking
off
what
casino
was
saying
about
pain,
points
and
performance.
You
know
most
of
the
pain
points
map
directly
to
an
instance
where
kind
of
the
amp
philosophy
puts
end
user.
D
Get
you
know
the
end
user
before
the
developer
and
says
that
we
are
not
going
to
compromise
performance,
for
you
know
one
more
widget,
one
more
ad
one,
more
kind
of
a
b
experiment
that
doesn't
really
necessarily
benefit
the
user,
a
b
experiments
in
particular
one
because
we
really
have
interest
like
the
we
do
that
a
lot,
but
it
it
kind
of
conflicts
with
this
privacy,
preserving
preload
and
this
amp
cache.
So
how
do
we
do
both?
You
know,
there's
some
instances
where
you
can
say
hey.
D
You
can
do
an
experiment
on
something
that's
later
in
the
page
load,
but
something
that's
part
of
the
initial
paint.
No
we're
not
going
to
call
back
to
origin
for
that,
because
that
would
slow
the
performance
down
for
the
end
user.
D
E
I
feel
like
to
be
honest,
like
almost
everything
is
hard,
I
mean
way
too
hard.
I
mean
starting
from
server
side,
rendering
to
hydration
on
a
client
side.
You
know
quote
spinning
all
of
these
issues
that
are
state-of-the-art.
You
know
many
many
many
big
sites
solving
by
large
teams
are
still
too
hard.
You
know
dom
apis
themselves
at
times
pretty
hard.
E
You
know,
try
to
use
history,
api
and
it's
you
know
you
can
sync
any
amount
of
you
know
engineering
hours
just
trying
to
figure
that
out
I
mean
almost
everything.
D
Is
a
bit
too
much?
I
absolutely
agree
a
thousand
percent
and
I
think
you
know
there's
an
illusion
that
sometimes
things
are
easy,
but
then
you
get
to
production
and
it's
slow.
So
I
think
amp
puts
the
pain
up
front
in
a
lot
of
cases
and
I
think
that's
the
strength
of
amp
don't
make
it
seem
easy.
If
it's
not.
I
guess
is
something
that
I
I
kind
of
agree
with.
B
We
have
a
question
from
youtube.
Sorry,
yep
notice
that
the
first
feedback
from
the
amp
page
experience
guide
is
to
use
the
amp
optimizer
wondering
about
more
approachable,
architectural,
more
approachable,
architectural
wow.
This
is
hard
wondering
about
more
approachable,
architectural
options.
Few
for
html
conversion
on
high
volume
sites.
B
I
think
I
reached
out
and
asked
about
a
clarification
about
the
approachable
architectural
options,
but
I
think
for
amp
optimizer,
very
specifically,
one
of
the
pain
points
that
I
want
to
see
addressed
going
into
next
year,
seeing
it
be
available
for
more
for
more
frameworks,
currently
it's
available
for
next
year's.
So
if
you're,
so,
if
you're
working
in
next
year's,
you
have
like
optimizable
and
it's
not
something
you
have
to
think
about,
and
that
is
really,
in
my
opinion,
the
most
ideal
use
case
right.
B
It
just
comes
for
free,
it's
not
something
you
have
to
actively
think
about,
but
then
I
know
it's
available
in
the
wordpress
amp
plugin
netlife
somebody
from
the
community
contributed
for
netlify
as
well
as
well
as
we
have
an
integration
with
11t
and
I
want
to
see
it
be
used
in
more
places
automatically.
F
I
can
try.
I
think
this
I
mean
it's,
it's
a
difficult
question
the
abstract,
because
it's
unclear
that
there's
a
problem.
I
think
the
so
you
know
you
could
there
might
be
a
problem
that
it
takes
too
much
cpu
if
you
have
a
very
large
site
and
then
it
depends
a
little
bit
on
why
your
site
is
large,
like
if
your
site
is
large
because
it
it's
it
has
a
lot
of
pages.
Then
the
right
strategy
is
to
do
it.
Lazily
because,
probably
most
of
them,
no
one
ever
looks
at
I'm,
not
sure.
F
That's
true
for
chris's
site,
for
example
right.
It
probably
has
a
lot
of
web
pages
that
don't
get
a
lot
of
traffic
right,
so
like
they're
only
exist
in
theory
and
and
so
like.
That's
a
very
different
strategy
from
if
you
know
from
a
website
that
you
know,
maybe
at
some
point
made
the
decision
that
static
site
generator
is
a
good
idea,
and
now
they
have
a
hundred
thousand
pages
and
it
takes
a
long
time
to
deploy
them
and
adding.
F
You
know:
100
millisecond
per
page
html,
parsing
process
times
100
000
is
isn't
fun
right.
So
these
are
all
very
different,
different
problems.
I
think
the
the
yeah,
so
we
haven't
heard
so
much
feedback
around
this.
I
think
where
we
are
seeing.
F
You
know
one
interesting
development
is
that
there's
a
php
version
of
this
now
and
I
think,
and
and
so
originally
this
was
like
tied
into
the
m
plugin,
but
that
team
took
that
out
and
basically
just
made
an
amp
optimizer
that
anyone
who
has
a
php
pipeline
can
just
plug
in
independent
of
of
using
the
wordpress
plugin.
F
And
so
you
know
one
interesting
development
that
was
really
recently
was
the
release
of
the
c
plus
plus
amp
validator,
that
that
google
is
using
in
production,
so
that
was
previously
not
available
open
source
and
it's
available
open
source
now,
so
you
could
envision
that
one
could
build
an
amp
optimizer
in
cpl
plus
based
on
that
relatively
easily
compared
to
if
that
wasn't
already
around.
But
since
we
actually
haven't
heard
particular
feedback
that
that
people
use
so
much
electricity
convert
optimizing.
F
B
We've
got
another
question
coming:
do
you
see
amp,
focusing
more
on
making
better
ui
components
such
as
lightbox,
accordion,
etc
or
deprioritizing,
those
in
favor
of
components
that
users
can
build
themselves
using
amp
script.
I
I'll
take
this
one
I
this!
This
is
a
tricky
one
for
me,
because
I'm
not
sure
where
we
end
up
netting
out
there's.
So
one
of
the
things
I
I
loved
about
the
kind
of
concept
of
amp
when
we
were
initiating
the
project
is
the
idea
that
there
were
these
components
that
were
like
super
approachable
like
super
semantic,
and
I
feel
it
it.
I
It
made
people
who
are
maybe
even
like
newer
to
web
development
to
be
able
to
like
come
in
and
use
use
the
amp
library
to
put
together
web
pages,
and
they
could
be
really
rich
in
terms
of
the
experience
that
they
provide,
like
building
a
light
box
or
carousel.
Like
is
a
pretty
complicated
thing
to
get
right.
Just
in
terms
of
like
you
know,
navigation
and
performance
and
stuff
like
that,
and
so
I
feel
like
amp
put
a
lot
of
power
in
into
your
hands.
I
While,
while
it's
kind
of
getting
pretty
close
to
a
guarantee
that,
like
you,
would
you
would
end
up
in
a
good
state
with
with
how
you
built
out
that
experience
plus
all
the
other
stuff
that
you
wanted
to
do
in
building
up
the
web
page,
so
that
aspect
of
amp
has
always
been
something
that
I've
really
cherished
about
it?
And
we
have
put
investment
in
recent
years
into
things
like
lightbox
and
carousel
to
make
those
better.
I
So
I
think
I
could
see
sort
of
more
continuity
of
that
it'd
be
interesting
to
hear
if
there's
like
feedback
around
specific
components
where
you
see
there's
like
opportunities
or
gaps
on
the
other
hand
and
going
back
maybe
a
bit
to
the
e-commerce
question
that
came
up
earlier
as
well,
so
things
like
amp
scripts
can
actually
be
used
to
drive,
amp
and
and
to
get
to
sort
of
you
know
more
more
nuanced.
I
U
cases,
you
know,
be
able
to
get
more
power
out
of
amp,
and
so
I
think
that
that
has
been
a
path
that
has
been
useful
in
helping
to
address
the
e-commerce
use
cases
that
we've
been
looking
at
over
the
years,
and
so
you
know,
I
think,
to
the
extent
that
further
investment
in
that
area
is
merited.
I
think
you
know
that
that
that
could
make
sense,
but
I
don't.
I
don't
necessarily
see
us
like
saying.
I
I
If
I
see
that,
but
I
you
know
I
could
see-
maybe
a
little
bit
script
to
be
able
to
handle
some
of
the
more
those
more
nuanced
use
cases,
power
use
cases
in
general,
but
what
I'd
also
say
is
like
across
all
of
these
things,
I
think
what
I'm
you
know
reiterating
what
I'm
really
excited
about
in
2021-
and
this
is
groundwork
that
we've
laid
so
far
this
year
has
actually
been
thinking
about
amp
like
super
holistically
too,
not
even
along
these
specific
dimensions.
I
Like
thinking
about
things
like
bento
and
ways
that
we
can
make
amp
more
flexible
so
that
you
kind
of
you
know
just
change
the
details
of
how
you
how
you
interact
with
amp,
you
kind
of
change
like
the
whole
sort
of
mindset
that
you
might
have
in
approaching
amp
are
the
options
that
you
see
on
the
table
for
building
with
amp,
and
so
that
is
like
a
third
kind
of
path
of
investment.
That
I
think
is
is
open
to
the
project,
and
I
do
see
us
investing
significantly
in
that
direction.
In
the
coming
year.
C
I
I
also
wanted
to
add
that
high
level
semantic
components
are
also
much
better
for
accessibility,
in
the
sense
that,
when
things
get
implemented
that
way
as
long
as
the
component
supports
an
accessible
interface,
things
like
say,
keyboard
navigation,
various
tagging
of
the
function
of
the
element
that
comes
basically
for
free
with
using
that
element,
whereas
if
it
gets
built
up
from
scratch,
using
something
like
amp
script,
in
many
cases,
it
just
won't
be
implemented.
Accessibly.
E
I
I
agree
with
that.
I
also
you
know,
thinking
that
a
lot
of
the
accessible
components,
they're
also
accessible
to
other
type
of
clients
like
even
search
search,
indexers
and
so
on
in
annoying
that
semantic
information
is
useful.
E
Personally,
every
time
I
open
an
amp
page
source
code
and
just
being
able
to
see
where
ads
are
or
where
analytics
events
are
sort
of
very
declaratively.
It's
actually
very,
very,
very
helpful.
I
mean
part
of
the
answer
could
be
that
we
could
see
how,
where
you
know
our
developers,
you
know
take
take
all
of
this.
You
know
how
much
they
use
sunscreen
versus
components,
but
part
of
it
we're
also
getting
feedback
that
people
wanted
to
be
able
to
use
our
components
outside
of
even
amp,
which
is
why
you
know
inventor
project
exists.
B
We're
roughly
10
more
minutes
so
I'll,
take
I'll.
Take
two
or
three
more
questions.
The
next
one
is:
should
publishers
or
companies
be
encouraged
or
penalized
for
favoring
certain
websites
over
others
based
on
the
underlying
technology
versus
content?
I
think
this
is
why
I'm
really
excited
about
things
like
core
by
vitals
and
page
experience.
H
H
No
yeah,
yes,
that's
a
very
yeah.
That's
a
very
good
answer!
No,
and
I
like
I'm
here
like
representing
microsoft
and
what
we
do
for
search
and
then
like.
There
are
folks
from
from
google
here
for
me
with
like
what
matters
like
the
web.
Vitals
are
a
perfect
picture
of
what
what
matters
for
us
like,
even
though,
like
microsoft,
for
being,
we
don't
have
the
same
thing
as
web
vitals
like
we
use
similar
very
similar,
very
similar
signals
to
to
do
that,
and
what
matters
is
performance
content.
H
The
underlying
technology
doesn't
matter
at
all
right.
You
can
use
an
app.
You
can
use
any
script
any
any
framework.
You
can
do
all
server-side,
rendering
your
client
side,
it
doesn't
matter
what
matters
is.
The
is
the
page
quick,
like
are
the
sign
signals.
There
is
the
content,
good
and
so
on
and
so
forth.
So
the
short
answer:
no,
no!
No!
No!
No!
No.
D
Yeah
I
can
echo
that,
on
the
other
side
of
the
coin,
you
know
there's
a
perception
I
think
that
might
do
amp
for
seo,
but
having
core
web
vitals
lets
us
point
at
the
fact
that
hey
the
amp
pages
are
still
faster
and
as
long
as
the
amp
pages
are
faster,
there's
not
much
of
an
argument
that
we
should
switch.
It.
D
B
I'll
ask
I'll
see
if
there's
any
more
questions
coming
in
right.
I
feel
like
I
don't
have
the
memory
to
answer
this
question,
but
at
the
contributor
summit
it
was
mentioned
that
amp
runtime
might
give
you
a
pwa
out
of
the
box
for
navigating
amongst
amp
pages.
Is
there
are
there
any
updates
on
that?
B
B
E
I
mean
and
I'm
not
sure
it's
the
same
thing,
but
we
do
have
a
pwa
runtime
for
some
historical
reasons.
I
think
it's
called
shadow
runtime
and
it
allows
you
to
load
a
document
in
a
pwa
using
all
the
amp
technology
using
possibly
prerendering
and
everything
else,
and
you
know
there
are
think
couple
good
examples
there
as
well.
B
C
C
The
answer
is
no
chris
baxter
demoed
this
it
works
really
yeah,
because
my
understanding
is
that
the
the
actual,
the
the
defining
property
that
distinguishes
say,
bento
components
from
one's
running
in
a
in
a
fully
validated
amp
page,
is
that
there
are
certain
constraints
that
cannot
be
assumed
to
hold
once
you
start
going
beyond
the
boundaries
of
a
valid
amp
page,
and
once
you
unlock
once,
you
unlock
the
ability
to
basically
do
anything
with
a
framework
say
like
react,
then
a
lot
of
the
constraints
that
the
amp
components
depend
on
in
a
fully
validated
amp
page,
probably
can't
hold
anymore,
but.
E
Yeah
we
have
amp
script
where
which
has
a
fairly.
You
know,
unlimited
amount
of
technology
that
can
be
used
with
it
and
deployed
there.
You
know
react,
we
have
examples
in
react
and
pre-act
another.
There
are
definitely
limitations.
E
You
know
you
could
what
amp
wants
to
observe
instead
of
amp
script,
but
it's
a
basically
open-ended
app
that
can
be
hosted
inside
of
a
separate
thread.
It
has
a
some
sort
of
a
sandbox
around
it
and
can
be
included
on
any
amp.
F
It's
kind
of
I
was
talking
earlier
about
how
like
I'm
kind
of
going
away
and
it's
it.
This
is
kind
of
the
interest.
This
is
the
direction
that
all
of
this
is
kind
of
going
to
right.
You
can
definitely
imagine
stuff
like
this
happening,
and
I
you
know,
I
think,
beyond
the
demo.
You
can
actually
do
it
today
right.
It's
definitely
interesting
area
of
research.
How
how
such
program,
programming
models
could
look
like
in
the
in
the
future
and
when
it's
all
a
little
bit
better
tied
together.
F
I,
but
you
know,
amp
script-
does
put
constraints
on
you.
So,
for
example,
you
can't
just
set
up
a
timer
and
keep
updating
the
page
right,
or
so
there's
constraints
like
that
because,
like
you,
have
to
have
a
user
action
to
make
changes,
and
so
those
are
definitely
handled
independent
of
whatever
technology
is
actually
used.
Inside
of
the
of
the
worker.
E
Actually,
I
think
I'm
script
cancelling
timer
they
just
you
just
can't
violate
the
size
of
a
page
or
you
know
the
content
layout
shift
basically
constraints
right,
yeah,
that's
what
I
meant.
B
B
If
you,
this
is
a
great
point
to
actually
go
plug
the
youtube
channel
for
the
amp
project,
which
is
youtube.com
the
amp
project,
where,
if
you
find
the
talk
for
amp
script,
I'm
sure
you
can
find
the
video
as
well
as
you
can
find
the
talks
from
yesterday
as
well,
where
everything
from
stories
to
email
to
things
like
quora
vitals
will
also
be
covered
since
we're
about
like
three
minutes
out,
do
folks
have
any
last
comments.
B
Question
from
the
tse
do
folks
have
any
like
last
things
to
say
otherwise,
I'll
close
this
out.
B
Okay,
yeah.
I
guess
with
that.
Thank
you
to
folks
who
are
joining
us
who
took
the
time
out
to
join
us.
It
means
a
lot
to
get
your
feedback
to
hear
your
questions,
your
concerns
and
I'm
sure,
like
this
just
factors
in
very
much
into
like
the
way
the
amp
project
is
run
all
of
your
community
feedback.
So
with
that,
thank
you
for
joining
us.
B
I
hope
you
all
stay
safe,
are
washing
your
hands
socially
distancing,
staying
six
feet
apart
and
taking
care
of
yourselves
and
your
family
like
this
is
this
is
no
you're
like
before,
but
I
hope
you're
all
taking
care
and
stink
safe
with
that.
Thank
you
for
joining
us
to
the
members
of
the
tsc
here
and
thank
you
for
those
who
are
joining
us
on
the
live
stream
and
also
thank
you
to
openjs
for
having
us
absolutely
like.
100
we've
been
great
hosts.
Thank
you
thanks.
Nana.