►
From YouTube: CNCF Serverless WG Meeting - 2019-04-11
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
Okay,
I,
don't
think
I,
think
that
is
wide
where
at
the
bottom,
but
don't
think
as
a
microphone
yet
well
circle
back
around.
Alright,
let's
go
and
get
started
lots
of
fun
topics,
ooh
all
right,
community
time
are
there
any
anybody
on
the
call,
not
normal
attendee
or
anybody
have
any
community
related
topics.
They
want
to
bring
up
all
right,
good,
moving
forward,
all
right,
STK
subgroup.
We
were
supposed
to
have
a
meeting
right
before
this.
No
topics
really
came
up,
so
nothing
really
to
bring
up
their
demo
calls.
A
So
we
are
making
some
progress
on
the
demo.
We
hopefully
will
have
a
call
right
after
this
one
for
those
of
you
who
can
make
it
to
keep
working
through
the
sample,
workflows
and
stuff.
For
those
of
you
are
kind
of
waiting
on
the
sidelines
until
we
get
everything
nailed
down
with
concrete
examples
for
you
to
start
coding
to
not
quite
there
yet
I
feel
like
we
are
getting
really
close,
though
so
keep
an
eye
out.
A
Going
forward
COO
Connie
you,
the
agenda
is
outs,
I,
don't
think.
We've
made
a
changes
there
or
made
any
progress
relative
to
presentations.
People
to
review
the
practitioners
summit
agenda
is
out
I
apologize,
I,
don't
think
I
put
the
I
think
I
put
a
link
or
what
is
it
now?
I
didn't
think
I
put
it
on
select
channel
I'll.
Try
to
find
the
link
to
the
agenda
the
the
working
group
session.
They
are
yet
session
that
Kathy
and
I
were
going
to
present
that
that
one
was
accepted.
A
So
we
do
have
something
there
to
talk
about
our
work
here
and
that
will
include
a
teaser
for
the
other
sessions
that
we
have
during
coop
con
itself,
so
it
did
get
in
there.
So
that's
good
koukin
CN,
oh
I'm!
Sorry,
this
agenda
doc
here
is
actually
not
correct.
That's
actually
for
China
I
apologize.
So
if
just
as
an
FYI
in
case
you
did
submit
something
for
China,
you
know
the
agenda
is
out.
Our
group
did
get
132
five-minute
session
for
cloud
and
one
35
minute
session
for
service.
A
They
didn't
have
enough
room
for
intro
and
deep
dive,
so
we
do
at
least
have
those
that
will,
in
the
future,
be
talking
about
the
planning
sessions
for
those
I
think
it's
a
little
far
out.
So
we
need
to
worry
about
it.
Quite
yet.
I
have
not
put
together
the
presentation
yet
for
our
yearly
review
for
May
7th
and
that's
available
for
you
guys
to
review
I'll.
Let
you
guys
know
and
with
that
we
can
jump
into
PRS,
but
did
anybody
have
any
topic
at
a
higher
level?
A
They
want
to
bring
up
before
we
jump
into
PRS
all
right
cool
moving
forward.
Then
all
right
Tim
opened
up
a
PR
now
normally
because
this
was
opened
up,
I
believe
just
yesterday,
or
so
we
would
normally
have
fuel
the
weight.
However,
this
is
just
a
very
minor
change
to
the
primer
dock
and
it's
just
a
sample
AWS
cloud
events.
I
want
to
hide
cloud
watch
event,
so
I
thought,
maybe
you
guys
could
just
take
a
quick
look
at
this
and
approve
it.
B
I
was
also
thinking
about
maybe
taking
out
one
or
two
of
the
other,
both
the
other
AWS
examples
I
mean
because
this
is
the
one
that
actually
matters,
but
anybody
you
have
self,
the
other
ones
are
some
random,
SNS
thing
and
so
on.
When
it
comes
to
events,
though,
the
one
I
put
in
is
the
one
that
matters.
B
C
A
B
A
Wait
a
minute,
there's
more
updates,
then
so
is
there
any
objection,
then,
to
not
only
accepting
this
edition
with
the
space
fixed
but
then
also
removing
per
Tim's
request,
I
guess
so,
there's
the
SNS
one
and
I
guess:
is
it
here's
the
other
one,
okay
and
then
removing
this
one?
So
you
want
to
remove
those
two
and
then.
E
A
A
B
A
Okay,
let's
say
the
space
and
remove
the
other
examples
cool.
Thank
you
Tim
for
that
appreciate
it
all
right.
This
one
I
think
I
may
have
open
this
two
days
ago,
Oh
22
hours
ago,
so
a
little
over
a
day.
Okay,
so
this
one
while
it
is
new,
it
is
very,
very
straightforward.
Basically,
there
were
a
couple
of
editorial
things
that
Clemens
did
not
get
a
chance
to
pick
up
before
we
approved
his
subject.
Pr
you
can
see
here
it's
just
changing
stars
to
dashes
just
for
consistency
with
the
rest
of
the
doc
and
I.
A
Believe
someone
had
a
comment
that
Clemens
forgot
to
pick
up,
which
is
just
add
the
phrase.
If
present,
it
must
be
a
non
empty
string
so
that,
if
present-
and
that's
mainly
just
to
be
consistent
with
the
rest
of
the
spec
more
stars,
two
dashes
fixing
some
blanks
at
the
end
of
lines
here
and
then
the
rest
is
stars
dashes
and
the
blanks.
C
A
C
A
Rebel
Eve,
the
text
of
this
is
pretty
much
the
same
as
what
you
had
before
when
you
had
the
PR
as
adding
it
to
the
main
specs.
Is
that
correct?
Yes,
yes,
okay,
I,
thought,
okay
and
keep
in
mind,
as
you
guys
think
about
this
one.
This
is
an
extension,
so
the
bar
is
definitely
lower
than
the
spec
up
a
bit
spec
change
any
discussions
on
this
one.
A
With
that,
okay
Jim
yeah
yeah.
G
And
I'm
sorry
I've
been
mentally
out
of
it
for
a
week
or
so
being
sick,
and
the
only
comment
I
have
around
this,
maybe
for
Christophe
is
that
it's
a
little
bit
odd.
The
middleware
I
think
and
we're
giving
me
the
guidance
that
the
middleware
or
intermediary
can
sort
of
drop
the
data
and
then
pass
references
to
it
and
I'd
sort
of
I
sort
of
wonder
whether
that's
really
an
end-to-end
contract
between
emitter
and
the
eventual
subscriber,
because
there's
no
guarantees
subscriber
will
have
the
ability
to
resolve
a
reference.
G
C
C
Change
no
and
what
I?
Now
it
is
an
extension.
So
there
is
no
guarantee
that
a
subscriber
implements
this.
Actually,
if
we
will
put
it
into
the
main
spec,
it
would
be
sort
of
every
subscriber
with
Opie.
You
know
should
have
an
understanding
of
this
field
versus
now.
It
is
well
optional,
so
it
is.
If
you
are
a
middleware,
you
cannot
know
if
your
subscribers
will
support
this
data
refresh
rate
or
not,
but
anyway,
it
is
in
the
sense
that
it
has
been
billed.
C
It
is
not
always
guaranteed
that
the
every
subscriber
can
necessarily
follow
this.
So
if
you
have
the
case
or
use
the
claim
track
pattern
to
make
sure
that
no
one
reads
the
data
who
shouldn't
in
this
case
only
these
subscribers
that
have
a
preferred
secret
can
read
it
anyway,
so
yeah
it
is
sort
of.
If
we
build
it
in
then
it
means
that
a
someone
has
to
build
the
chain
right.
A
F
C
Right,
it's
a
thing
d.
What
the
the
background
of
this
is.
We
have
the
size
limitation.
So
if
you
are
a
middleware
and
someone
sends
you
I,
don't
know
a
one
megabyte
data
attribute
and
then
you
try
to
forward
it
on
to
another
different
protocol
where
you
are
restricted
to
a
smaller
size,
let's
say:
64
kilobytes,
then
either
you
just
drop
the
event
which
is
maybe
not
so
good
or
you
use.
This
claim
track
pattern
so
that
the
consumer
then
at
least
gets
the
event
and
then
can
get
the
data
through
D
data
ref.
A
D
G
Other
one-
and
it
was
probably
a
rather
dismissive
comment-
I
made
on
Christoph's
original
PR-
was
the
fact
that
whether
there
was
some
way
to
address
this
using
the
data
content,
type
methodology
to
sort
of
say
well,
the
data
is
not
actual
data.
It's
a
reference
to
data
I
that
I'm
not
sure
if
you
guys
discussed
that
when
I
was
off
last
week,
but
so
that
was
the
only
other
sort
of
comment
I'd
had
on
this
issue.
A
E
F
Yeah
and
I
think
that's
for
me:
that's
the
preferred
solution
to
keep
the
event
to
keep
even
small
and
then
the
event
might
actually
turn
and
might
actually
point
at
different
kinds
of
data
emmalin's
elements.
You
eventually
want
to
go
to
pull,
and
you
probably
also
want
to
go
and
describe
the
be
a
little
bit
more
descriptive
about
the
data
that
you
are
referring
to
and
that's
all
something
that's
well.
How
is
I
think
in
the
in
the
data,
the
other.
A
So
how
do
people
feel
about
this
going
forward?
I
said
it
is
an
extension,
so
it
doesn't
have
to
be
at
higher
bars
things
for
the
spec
and
one
of
the
nice
things
about
it
being
ascension
is
we
can
get
to
see
we
can
get
that
we
get
to
see
what
kind
of
a
uptake
there
is
in
the
community
for
this
versus
some
other
solution
that
people
may
have
I
I.
G
Don't
have
a
problem
with
this
going
in
as
a
as
an
extension,
I
sort
of
I.
Maybe
I
have
more
of
a
problem
if
middleware
providers
start
randomly
applying
those
extensions,
you
know
what
I'm
not
expecting
it
to
happen.
So
if
it's
an
end-to-end
contract
between
the
original
event,
emitter
and
its
trusted
subscribers,
then
you
know
I,
think
that's
where
extensions
sort
of
work
yeah,
but
but
the
middleware
should
just
be
pass
it
you
know,
should
just
pass
on
so
III.
G
G
G
A
A
A
The
thing
is,
we
actually
discussed
that
and
we
actually
did
allow
it
exactly
because
if
you
don't
allow
it,
then
if
a
voting
member
wants
to
get
their
thing
in,
they
have
to
get
up,
but
they
can
play
a
game
by
getting
a
proxy
to
vote
for
it
yet,
and
it
just
avoids
a
whole
bunch
of
game
playing
say,
look
the
features
of
feature
regardless.
Who
mentioned
it?
A
Even
if
it's
the
person
who
mentioned
that
they
they
should
be
able
to
say
yes,
I,
want
it
it
just
it
actually
avoids
game
playing
so
adds
game
playing,
so
okay,
yeah
so
hold
on
a
second.
We
just
double
check
here:
I
apologize,
my
machine
is
getting
kind
of
slow
all
right.
So
here
are
the
voting
members
Christoph.
You
are
actually
a
voting
member,
so
you
can
book
your
own
things
and
you
do
anybody
else
want
to
raise
their
hand
as
the
second
voting
member.
A
A
Do
you
guys
want
to
wait
until
he's
on
the
call
to
discuss
this
quoting
issue,
actually
neither
Scott
or
Adam
around
the
call?
Or
would
you
guys
like
to
discuss
it
now?
I'm
inclined
to
wait
until
he's
one
of
those
guys
around
the
call,
but
it's
up
to
you
guys
if
you
think
we
can
discuss
it
without
them.
We
should
wait.
A
Okay,
okay,
any
objection
to
waiting
okay,
unfortunately,
okay,
so
we
had
this
whole
issue
about
what
is
going
to
be
used
for
uniqueness
for
messages,
because,
right
now
the
spec
says,
source
and
ID
together
works
well
and
actually
doesn't
technically
say
that
I
think
the
spec
technically
says
for
every
producer.
The
ID
must
be
unique
for
every
single
event.
You
can
imply
from
that.
That
means
ID,
plus
source
and
I
believe.
A
Somebody
who
was
it
somebody
opened
up
a
PR
to
actually
clarify
that
to
say
that
it's
actually
source
plus
ID.
It
could
be
used
for
D,
dupe
and
stuff
like
that
and
that's
fine.
But
then
there
are
some
issues
raised
about
whether
type
should
be
included
in
there
and
that
was
actually
raised
by
Scott
I.
Think
if
the
main
proponent
of
that
either
I
think
May,
there
may
be
one
or
two
other
people
that
may
have
kind
of
raised
their
hand
and
said
yeah.
That
makes
sense
for
the
people
on
the
cause.
A
I,
don't
think
we
can
resolve
this
today
without
at
least
Scott.
Since
yes,
I
think
it's
drawn
the
pain
on
this,
but
for
people
on
the
call,
what's
the
general
sense
for
from
you
guys,
do
you
want
to
keep
it
as
it
is
today?
We're
kind
of
ID
alone
is
a
unique
factor
or
I.
Guess
ID
plus
source
of
the
unique
is
the
uniqueness
sort
of
tupple
for
an
event
to
determine
uniqueness.
Or
do
you
guys
think
we
need
to
include
type
in
there.
F
So
my
sense
is
that
the
source
identifies
who's
raising
the
event
and
then
the
idea
is
hey,
whatever
number
space
or
any
space
the
source
wants
to
assign
to
the
event
and
that's
efficient,
that
crazy
situation.
Uniqueness
äì,
you
could
include
the
type
but
I,
don't
know
what
that
adds,
because
then
he
was
thinking
you
would
scope
the
the
ID
to
the
sort
and
type
first
and
then
created
an
ID
space
kind
of
force
or
some
type,
and
that
makes
that
doesn't
make
a
lot
of
sense.
For
me,
okay,.
B
G
Okay,
so
my
only
comment
with
that
is
something
that
we've
seen
in
the
past.
Is
that
an
obviously
outside
the
context
of
cloud
events?
We
can't
guarantee
that
our
clients
are
going
to
generate
globally
unique
IDs
yeah,
so
we
always
have
to
pair
it
with
a
client
ID
to
actually,
you
know,
create
a
global,
unique
space.
G
C
Okay,
Christopher
hands
up
I
made
this
comment
on
a
previous
court.
My
issue
is
that
for
the
type
we
say
this
should
be
should
start
with
a
reverse
DNS,
so
we
kind
of
try
to
make
the
type
globally
unique
for
the
source.
We
don't
require
such
a
thing
so
for
sauce
I
could
just
say
this
is
slash
user
right
and
then
there
could
be
like
a
lot
of
people
whose
/user
is
well
it
for
me.
Well,
I
could
be
Facebook
Twitter
github.
C
Anyone
could
have
that
like
slash,
user
is
pretty
generic,
so
we
could
also
think
about
saying.
Okay,
this
source
should
also
you
should
try
to
make
these
for
school
were
unique,
then
my
concern
kind
of
goes
away,
but
if
we
don't
do
that
and
I
think
type
is
nice
in
there,
because
it
contains
the
reverse,
DNS
and
sort
of
makes
sure
that
it's
then
probably
unique
yeah.
But
that's
that's
not
that's
not
the
reason
why
you,
where.
F
You
have
the
the
the
type
unique
it's
like:
that's
it
that
might
be
a
nice
element
that
you
can
use
for
yourself,
but
but
it's
not
guaranteed
to
be
unique
and
certainly
not
unique
for
the
source
because
it
really
like,
if
you
have
to
Microsoft
the
blog
created
events,
how
I
said
that's
a
universal
thing
that
might
be
used
all
over
the
place.
How
impose
that
help
you
with
a
uniqueness
for
you
in
the
individual
event?
Instance.
C
F
Id
is
the
the
idea
is
the
thing
that
that
varies
and
that's
being
that's
being
generated
by
some
relative
to
some
counter
that
you
keep
and
if
you
don't
use
a
good
and
then
and
then
you
have
a
relatively
you,
have
a
source
it's
identified
and
whether
that
source
know
straight
loads
that
that
that
number
space
with
another
unique
identifier
which
is
unique.
But
then
you
know
it's
not
doesn't
constrain.
The
number
space
go,
doesn't
help,
but.
C
C
The
source
I
mean
that's,
that's
exactly
what
I'm
saying
then
we
should
go
in
and
we
should
tell
the
people.
Don't
use
your
I
reference
use
a
full,
your
I
to
make
sure
that
it
is
globally
unique,
something
like
slash
users,
it's
a
very
bad
idea
because
that's
probably
going
to
clash.
So
if
your
github
use
github.com,
slash
users
and
if
your
Twitter
use
twitter.com
slash
users-
and
we
should
be
more
explicit
in
the
spec
about
this-
that's
all
I'm
trying
to
say
yeah,
so
my
hands
up
I.
A
A
There
doesn't
like
all
a
lot
of
sense
from
my
perspective
and
I,
just
wanna,
say:
I
agree
with
what
Clement
said:
I
I
don't
see
what
type
ads
in
terms
of
uniqueness
and,
in
fact,
I
think
if
you
actually
did
add
type
in
there.
We
then
have
to
explain
what
it
means
for
the
same
source
to
have
two
events
with
the
same
ID,
because
then
obviously
ID
means
something
beyond
just
some
random
number
right.
What
does
it
mean?
It
implies.
A
H
Yeah
I
think
I
also
agree.
You
know
it's
a
source
pass
ID
that
you
know
uniquely
identify
about
that
event
because
I,
you
know
it's
easy
to
scope
that
uniqueness
of
the
ID
with
being
a
source,
but
it's
not
easy
to
scope.
You
know
idea
globally
because
there's
so
many
different
sources,
it's
hard
correlate
in
all
the
events
and
I.
Think
hi,
Agnes
I
think
that
ask
more
complication.
A
A
So
in
that
case,
we'll
do
this
I'll
I'll
I'll
talk
to
Scott
offline
and
then
see
how
he
feels
about
this,
but
obviously
I,
don't
wanna
resolve
this
without
him
on
the
call,
since
I
think
he'd
a
some
strong
feelings
about
that,
and
maybe
he
can
convince
everybody.
That
type
actually
does
make
sense,
but
I
guess
I
just
want
to
get
a
sense
for
the
the
mood
of
the
room.
So
thank
you
guys.
I
think
I
got
that
okay
now
another
one
from
Scott.
So
unfortunately
we
can't
we
guess.
A
If
we
have
already
really
agreed
with
this,
we
could
we
could
resolve
it
if
we
wanted,
but
basically
Scott
wants
to
change
the
current
version
of
the
spec
to
0-3
I.
Actually,
don't
think
that
III
know
a
moderator,
I
shouldn't
jump
in
here,
but
I
do
want
to
join,
but
anyway,
I
actually
think
this
is
a
bad
idea,
because
we
aren't
at
0
3
yet
and
I
think
that
would
actually
cause
more
confusion
for
people.
A
What
I
would
I
would
rather
suggest
is,
if
you
want
to
change
it,
to
something
put
it
as
like:
0.3
alpha
or
release
candidate,
or
something
like
that
to
make
it
clear
that
this
isn't
really
0.3.
It's
a
pre,
0.3
type
of
thing,
but
I
wanted
to
get
a
sense
from
the
room.
What
you
guys
thought
about
something
like
that
before
I
actually
made
a
formal
proposal.
I
I
F
A
A
Maybe
we
should
I
mean,
do
you
guys,
so
what
is
there?
Is
there
a
string
that
people
would
like
to
put
in
there
I
mean
I?
Think
in
the
past
someone
even
suggested
putting
the
word
master
in
there
or
something
like
that
to
represent.
You
know
it's
the
master
branch
and
that's
clearly
not
a
real
cember
thing.
I
prefer.
J
A
My
only
concern
with
latest
is,
if
you
think
about
the
docker
world
latest
means
of
all
the
birds
out
there.
This
is
the
latest
one
that
was
built
and
I
wouldn't
want
someone
to
think
that
this
is
the
latest
version
of
the
spec
meaning.
At
this
point
of
time,
it
latest
is
an
alias
for
0-2
yeah,
my
latest.
It's
an
idea,
that's
not
like
return.
I
I
do
like
master,
though
cuz
I
think
that's
very
clear
for
anybody
who's
geeky
enough
to
actually
go,
find
it
and
get
out
mark.
A
I
A
I
I
think
I
think
that
we
need
to
separate
out.
Where
do
we
want
to
say
what
is
the
latest
version,
which
would
be
a
0.3
or
0.4
versus
the
examples
that
it
should
just
be
agnostic
with
respect
to
a
specific
version,
except
when
we're
doing
a
release
that
has
specific
features
that
are
implemented
in
that
version.
A
I
A
A
D
A
A
K
A
K
A
K
A
I
A
A
I
A
A
A
All
right
that
was
exciting.
Thank
you.
All
right,
I'll
talk
to
Scott.
Thank
you
all
right.
This
one
did
it
to
do.
Kathy
you're
still
on
the
call
right.
Okay,
no
gather
you
left,
oh
I
was
gonna,
ask
her
never
mind
since
she
was
the
lone
holdout
on
this
one,
and
we
can't
ask
her
about
that.
Okay,
let
me
see
if
there's
any
there
at
the
end
of
the
normal
PR
list
so
hold
on
Matt.
Let's
say:
there's
anything
we
could
talk
about.
A
No
I
think
everything's
up
for
discussion,
I've
already
covered
I,
guess
one
thing:
Clemens
your
size,
PR
was
approved,
but
I
think
there
were
some
edits.
You
needed
to
make.
Yes,
sorry,
yeah,
that's
fine,
because
we
were
actually
waiting
for
Rachel
to
do
some
things.
There
was
still
some
possible
open
discussions
around
this.
One
I
think
you
weren't
on
the
call
that
day,
but
there
were
some
amazing
things
that
Rachel
wanted
to
do,
but.
F
A
E
C
E
A
C
The
first
comment
for
me
here,
so
we
already
discussed
this
like
I.
Guess
everybody
forgot
it
by
how
well
we
discussed
whether
we
should
want
to
have
a
size
constrained,
as
is
in
this
PR
or
size
guarantee,
and
then
we
decided
we
want
to
have
a
size
guarantee,
which
is
also
I,
changed
that
in
my
initial
PR
yeah.
C
A
C
C
The
DD
DD
down
here,
not
us,
well,
there
yeah
I
think
there
another
line
that
I
commented
on.
Well,
it
should,
generally
it
shouldn't,
be
named
a
constraint
D.
It
should
be
so
if
you
know
that
I
don't
know
your
your
whole
chain
supports
one
megabyte,
then
you
should
be
in
compliance
with
the
spec.
If
you
send
out
a
something,
that's
one
megabyte
if.
C
F
One
is
you
shouldn't
be
put
in
putting
you
shouldn't
be
putting
more
than
64
K
and
K
on
the
wire
and
then
the
other
one
is
as
a
consumer.
Your
limits
should
not
be
less
than
64
K.
So
effectively,
one
is
be
careful,
don't
put
anything
more
than
64
K,
but
on
the
other
side
is
you
should
be
you
if
you're
putting
a
limit
on
this?
That
should
not
be
less
than
64
K.
C
F
D
C
F
A
C
D
C
A
So
I
think
what
you're
saying
is
you'd
like
to
change
the
title
and
you'd
like
this
line
to
be
augmented.
Excuse
me
to
say
post
event
should
not
exceed
64
K
and
receivers
may
reject
messages
that
they
consider
too
big
or
greater
than
64
K.
No,
that's
already
a
paragraph
below
okay,
then
and
I'm
so
confused
as
to
what
the
specific
text
you'd
like
to
see
in
like
three
or
four.
C
A
C
A
Okay
from
my
for
my
way
of
looking
at
it,
I
think
that's
similar
to
what's
already
being
said,
but
put
these
act
words
that
you'd
like
to
see
in
there,
so
Clemens
go,
look
at
and
see
if
it
actually
changes
what
his
intent
well
and
we
can
have
a
discussion
I.
Just
for
me
personally,
without
seeing
the
exact
text
you'd
like
to
see
it's
a
it's
hard
for
me
to
follow
the
exact
set
of
changes
to
know
whether
I
would
agree
or
disagree.
A
C
I
think
in
terms
of
implementation,
it
is
not
a
big
change,
but
it
was
more
like
we
look
at
all
the
sizes
we
had.
We
saw.
There
are
message
queues
who
go
up
into
several
megabytes
and
we
want
to.
We
didn't
want
to
exclude
those.
We
didn't
want
to
set
a
low
limit
and
saying
we
know
you
run
on
a
message:
queue
that
supports
65
one
megabyte
and
you
are
forced
to
go
with
64
kilobytes,
more
or
less.
We
want
to
say
it's
completely
fine.
If
you
go
above
that.
C
A
A
A
A
All
right
cool,
thank
you
guys
very
much.
Oh
I
should
point
out.
We
have
a
credible
demo,
call
in
seven
minutes
the
same
slack,
channel
or
seams
in
channel.
If
you
want
to
join
that
discussion,
heading
on
or
back
in
in
seven
minutes,
otherwise
everybody
else
is
free
to
go.
Thank
you
guys
very
much.
We'll
talk
next
week.