►
From YouTube: OCI Weekly Discussion - 2020-08-26
Description
The recording of the weekly OCI developer's call from 26 August 2020; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#August-26-2020
A
A
B
A
A
B
A
A
B
We'll
work
on
being
able
to
get
folks
codes
ahead
of
time,
but
things
to
be
able
to
watch
for
for
next
time,
we'll
be
creating
more
channels
in
the
cncf
slack.
That's
where,
like
a
whole
bunch
of
like
kind
of
energy
is
going
to
start
rising
up
for
kubecon,
and
I
would
say
that
will
probably
rise
up
like
the
week
before
for
the
cncf
kubecon
meeting
for
november.
So
sweet.
A
A
Go
why
do
they
do
this?
They
put
the
chat
over
here.
Is
it
more
there?
We
go
okay,
so
this
is
basically
a
timely
continuation
of
the
conversation
we
had
around
artifacts.
If
you
remember
back
last
year,
pre-covet,
which
is
called
pre-code,
we
had
the
artifacts
approach
that
basically
uses
the
config
media
type
to
say
this
is
what
this
thing
is,
and
the
majority
of
the
artifacts
at
the
time
were
things
that
were
single
man.
A
Obviously,
the
image
images
that
they
would
run
depending
on
what
they
were
deploying
and
an
invocation
image,
and
then
in
theory
they
can
have
other
things
like
helm,
charts
and
others.
Today
they
actually
put
a
lot
of
that
content
in
the
invocation
image.
So
the
only
thing
is,
the
collection
is
the
other
images
they
deploy,
but
I
think
that
was
mostly
just
basically
a
limitation
of
what
was
available
at
the
time
this
because
they
they
started
pre
artifacts.
A
In
fact,
it
was
their
example
that
validated
that
after
helmley
would
go
to
our
not
being
able
to
chase
all
these
things
individually
in
acr.
We
wanted
to
do
a
generic
approach
in
all
registries
for
all
artifact
types,
so
so
now
that
we've
kind
of
standardized
on
the
config
object
as
a
way
to
pivot.
What
the
thing
is-
and
we
talk
about
like
an
extension
to
a
file
in
a
file
system-
is
basically
what
the
config
object.
The
media
type
says
we're
now
ready
to
start
thinking
about
index.
A
The
well
cnab
has
been
there
for
a
while.
The
one
that
we're
really
thinking
about
now
is
signatures
for
the
notary,
v2
work
and
what
that's
about
is
basically,
obviously
we're
putting
signatures
into
the
registry.
There's
a
bunch
of
background
I
can
put
on
the
notary
work,
but
if
you
think
about
the
way,
notably
view
one
and
docker
content,
trust
were
done.
That
was
a
separate
service
with
a
separate
store
and
that
had
all
kinds
of
challenges
with
it
to
the
same
tag
can
be
mean
two
different
things.
A
If
you
wanted
the
signature
where
it
went
to
notary
story
versus
not
so,
we've
said
from
the
beginning,
we
wanted
to
make
sure
that
a
signature
was
sorry.
I
thought
I
had
the
list
of
okay.
Anyway,
we
said
we
wanted
to
have
natively
in
a
registry,
so
that
was
one
of
the
main
goals
of
nov2,
and
then
we
got
into
conversations
of
if
I'm
putting
something
in
a
registry
that
needs
to
link
to
something
else.
So
a
signature
is
a
detached.
A
Signature
is
referred
to
needs
to
reference,
another
artifact,
that's
in
a
registry,
then,
and-
and
we
don't
want
to
have-
to
change
the
digest
or
the
tag
of
the
original
thing
that
it's
signing.
So
I
push
a
helm
chart.
We
use
the
network,
monitor
software
as
an
example
from
webbit
networks
and
that
you
know
I'll
pick
on
craig
here,
because
I
think
of
craig
has
lots
of
deployments
and
bills.
You
know
he's
basically
in
his
deployment
chart
he
references
something
as
net
monitor
colon
v1.
A
He
could
also
reference
it
by
the
digest.
That's
a
religious
debate
that
I
want
to
get
into
right
now.
The
point
of
both
are
valid
and
regardless
of
what
he
references
it
just
because
we
sign
it
that
shouldn't
change.
Is
the
deployment
chart?
That's
an
additive
thing,
so
it
works
through
the
system
and
the
signature
can
be
added.
A
So
we
wanted
a
way
to
have
separate
things
put
in
it,
because
if
you
put
a
signature
on
a
manifest
by
definition,
the
manifest
changes,
the
digest
changes,
and
so,
therefore
that
wouldn't
work,
and
because
we
have
to
link
these
things,
we've
been
talking
about
a
couple
of
ways
to
do
that,
but
indexes
already
have
a
way
to
link
reference.
Other
things
an
index
can
reference
another
index
and
an
index
can
reference
a
manifest.
A
A
A
validation
object,
a
signature
object,
there's
some
other
talk
around
whether
we
use
the
config
to
store
the
signature
itself,
the
config
object.
But
for
the
point
of
this
conversation
I
think
I
can
simplify
it
by
just
saying
we
would
like
to
have
config
added
to
index.
So
now
I
can
look
at
an
index
and
see
it's
not
an
oci
multi-arc
image.
A
It
is
a
helm,
sorry,
a
c
lab
a
signature
object
and
for
other
things
that
we
assume
will
people
will
be
adding
over
time
as
well
other
collections
of
things,
so
that
kind
of
brings
us
to
the
conversation
like
all
right.
We're
we'd
like
to
follow
through
the
conversation
we
had
a
while
ago.
I
realized
we
never
actually
opened
an
issue,
so
I
only
opened
the
issue
recently
unless
I
lost
track
of
it.
I
thought
mike
and
I
to
the
two
of
us
at
least:
had
it
open
somewhere.
A
Oh
I
remember
here
it
is
so
I
had
the
the
list
of
requirements
that
we
talked
about
here
so
maintain
the
original
digest,
multiple
signatures
per
artifact,
although
we
actually
would
not.
This
is
kind
of
the
inverse.
What
we'll
do
here
is
it's
not
a
an
index
that
has
multiple
signatures
in
it,
because
that
means
every
signature
that
gets
added
later
on
again,
the
digest
would
have
to
change.
So
that's
not
a
what
we're
trying
to
do.
A
Next
pick:
okay,
let
me
just
pop
this
one
over
here
and
switch
to
read
me
and
you
so
I've
updated
this
I'm
a
visual
person.
I
was
focusing
on
the
pictures
trying
to
convey
the
information
and
now
that's
too
small
and
others,
because
that's
the
beauty
sam
was
like
I.
I
need
any
text,
so
I've
added
the
the
jsons
for
each
one
of
these
things
to
try
to
be
more
a
little
illustrative
of
some
of
the
approaches
that
we
had
here.
A
A
A
That's
fair,
too.
Okay.
I
was
the
the
order,
the
it
was
a
sequence
of
events,
so
I
think
it
depends
on
what
you're
reading
right
to
left,
but
that's
again
great
feedback.
I
first
push
the
manifest
or-
and
I
put
the
net
monitor
and
then
I
can
put
some
signatures
on
it,
but
I
see
what
you're
saying
so
that's
a
good
point.
So,
basically,
in
its
manifest
collection,
it's
referencing
this
manifest
right
because
index
is
my
manifest
collection.
A
But
the
thing
is,
I
want
to
know
this
is
not
a
multi-arc
in
an
image
in
a
multi-arc
index.
It
is
a
signature
object,
so
things
like
the
container
d
client,
the
docker
client,
any
client.
That's
trying
to
work
with
a
multi-arc
index
would
know
that
it's
not
and
they
should
ignore
it,
because
we're
obviously
trying
to
make
sure
that
each
of
these
things
know
just
like.
If
I
try
to
pass
a
jpeg
to
the
word
doc,
it
goes
like.
I
don't
support
that
and
don't
know
what
to
do
with
it.
A
A
One
was,
please
give
me
json
to
explode
out
what
you're
trying
to
say,
because
my
pictures
are
not
always
as
clear
which
clearly
it's
not
here
and
the
other
was
what
happens
when
I
sign
a
multi-arc
image
and
I
didn't
get
that
one
added
yet,
but
let's
walk
through
what
that
would
look
like
so
here
so
remember.
If
we
go
back
to
one
of
the
core
requirements,
that
we've
said
is
that
signatures
are
additive
to
a
registry
and
additive
to
artifacts
that
are
already
in
the
registry,
so
the
I.
A
So,
if
whether
I
push
a
manifest
name
called
net
monitor,
v1
or
let's
say
I
paste-
I
pushed
a
net
monitor
v1
multi-arc,
manifest
multi-arc
index
and
it
had
the
net
monitor
v1
for
windows
and
that
monitor
v1
for
linux.
Then
this
would
actually
be
referencing
an
index
because
manifest
lists
can
reference
other
manifest
lists
and
then
of
course
we
had
that
conversation.
What's
the
number
of
nesting
you
can
do
blah
blah
blah,
but
absolutely
you
could
sign
a
multi-arc
index.
D
D
D
A
D
A
More
or
less
right,
but
what
I
think
I'm
hearing
you
saying
is
in
the
manifest
collection
there
would
be
a
signature
and
the
other
things
that
the
other,
the
multi-arc
images
is
that
what
you're
thinking
you're?
Seeing?
Yes,
that's
what
I'm
thinking!
Okay!
So
that's
that!
That's
that's
why
I
need
to
add
the
picture,
because
that's
actually
not
what
we're
suggesting.
A
D
A
A
A
A
A
When
I
want
to
sign
this
multi-arc
index,
then
I'm
not
adding
these
to
its
list,
because
that
would
mean
this
index
digest
and
tag
is
changing.
What
I
want
to
say
is
I'm
adding
another
index.
This
index
is
going
to
reference
this
index,
so
the
ordering
actually
doesn't
matter
because
this
still
has
its
normal
collection
in
its
manifest
collection,
pointing
at
these
two
individually,
the
windows
and.
A
A
Because
then
we
wanted
exactly.
This
is
exactly
the
problem,
so
we
wanted
to
avoid
any
ordering.
Well
we're
not
going
to
avoid
any
ordering.
We
want
to
make
sure
that
any
clients
that
are
already
dealing
with
multi-arc
images-
they
don't
need
to
know
anything
about
signatures
per
se.
They
can
optionally
add
in.
We
didn't
want
to
change
anything
to
the
workflow.
So
this
this
whole
thing
on
this
side
for
a
multi-arc
doesn't
change
in
the
least
it's
only
when
I
want
to
additively
add
something
saying
that
this
thing
is
now
a
signature
object.
A
This
thing's
a
signature
object
that
the
container
d
client,
the
docker
client
would
say,
look
it
well.
No,
it
would
look
and
say
it
has
a
config
type,
and
I
don't
support
that
config
type.
So
if
it's
got
no,
so
the
fallback
of
what
I'm
trying
to
propose
here,
so
I'm
trying
to
make
sure
that
all
these
clients
don't
break
obviously
is
at
the
very
bottom.
We
started
talking
a
little
bit
about
this
sorry
at
the
bottom
of
the
wrong.
A
One
is
that
we
want
to
make
sure
that
container
runtime
clients
can
check
and
there's
a
question
whether
we
need
to
bump
the
version.
So,
let's
just
assume
we
bump
the
version
for
a
moment,
and
we
can
come
back
in
this
and
if
the
bump,
if
the
version
is
greater
than
three
less
than
three,
then
they
just
assume
hey.
This
is
a
multi-arc
image.
It's
the
only
thing
could
have
ever
existed
at
that
time.
So
continue
as
normal.
A
If
the
version
is
greater
than
three
greater
than
equal
to
three
then
check
the
config
media
type.
First
of
all,
if
there
isn't
one,
then
you
could
also
assume
it's
a
multi-arc
image,
we're
not
going
to
force
everybody
to
put
a
config
empty
config
in
it
they
could,
and
if
it
is,
then
that's
what
they
should
use.
But
if
it's
something
else,
basically
the
container
d
client
says
no
bueno
and
out.
It
goes.
A
A
A
A
It
depends
on
the
artifact
type
it
could
be
empty.
So
in
the
artifacts
approach
we
actually
say,
and
because
the
spec
already
does
support
null
descriptors,
you
know
null
config
objects
and
all
it
is
is
saying:
hey
this
thing's
a
helm
chart
in
fact
helm
doesn't
have
any.
I
don't
believe
helmet
is
anything
in
the
config
object
in
other
ones.
They
can
put
stuff
in
the
config
object
and
it's
completely
up
to
that
artifact
type
and
what
they
want
to
do
in
the
cnab
case.
They
might
put
hey
in
this
collection.
A
E
A
E
E
A
E
E
So
if,
if
you
just
try
to
say
oh
I'm
just
adding
a
field,
but
if
nobody
knows
that
that
field
exists
that
exists
today,
then
it
leads
to
what
we
just
say
is
undefined
behavior
and
yeah.
We
want
to
try
to
avoid
that
when
we
can
so
at
least
from
what
gets
returned
as
much
as
they
hate
using
the
media
type
for
negotiating
with
the
registry.
Sometimes
the
registry
coming
back
and
saying
hey:
this
is
an
index
b3
and
just
let
the
clients
just
choke
on
that
and
just
say
I
don't
know
what
that
is.
E
A
A
A
I
was
just
kind
of
running
an
idea
in
my
head
is
from
at
the
registry
when
we're
getting
the
requests.
Do
we
know?
Does
the
client
declare
enough
in
the
header
that
we
know
it's
a
docker,
client
or
container
decline
or
something
we
can
just
say
if
you're
asking
for
something
like
well?
First
of
all,
they
have
to
know
to
ask
so
these
are
not
going
to
be
named.
Something
can
hopefully
be
confusing.
I
give
somebody.
E
A
A
So
with
it's
not
like
we're
using
tags
that
well,
obviously
a
user
can
do
whatever
they
want
if
they
want
to
put
out
something
that
says,
you
know
hello,
world
v1
and
somebody
a
client
assumes
that
that's
a
it
was
trying
to
deploy
that
tag
by
something.
That's
that's
fine.
My
assumption
is
most
of
these
things
that
people
are
going
to
push
are
going
to
be
named,
something
they
don't
overlap
with.
Something
already
exists,
so
somebody
has
to
explicitly
tell
the
container
d
run
time
to
try
to
run
something
that
it
couldn't
run.
A
It's
kind
of
like
I
intentionally
pass
a
jpeg
to
the
word.
Doc
example,
like
I
don't
know,
I'm
just
I'm
just
thinking
through
the
permutations
I
mean.
Obviously,
we
want
to
run
some
tests
and
we
want
to
see
what
this
thing
you
know
winds
up
doing,
but
hopefully
it's
not
like
we're
breaking
existing
deployments,
so
to
speak
of
things
that
people
are
already
deploying.
A
E
A
A
So
that's
the
general
thing
so
granted.
This
is
just
the
dock
that
I
was
just
kind
of
writing
up.
I
was
I
wanted
to
circulate.
That's
so
much
the
motory
folks
and
I
wanted
to
circumvent
some
folks
also
to
get
the
initial
round
of
feedback
before
I
went
and
actually
did
a
pr
on
it,
the
pr
the
distribution
spec
but
or
actually
it's
the
image
spec
to
be
fair.
The
other
thing
was
as
part
of
the
notary,
v2
prototyping
work,
we're
actually
working
on
and
working
on
me
as
of
last
night
gonna.
A
A
A
The
signature,
the
index
the
index
needs
to
have
a
config
object.
The
distribution
spec
needs
to
have
it
not
choke
on
that,
and
the
auras
client
doesn't
actually
know
anything
about
indexes
today,
yet
either.
So
we
have
a
couple
of
things
that
we
have
to
go
off
and
do
so.
Our
thought
process
was
kind
of
like
the
splash,
the
color
on
the
wall.
A
Before
you
take
the
wall
off
and
know,
you
know
make
a
major
commitment
to
it,
because
we
were
going
to
prototype
this
figure
out
some
of
the
things
we
would
have
the
benefit
of
being
able
to
test
some
of
the
existing
clients,
because
we'll
just
instance
this
fork
of
the
distribution
spec
and
see
if
we
like
it
and
if,
as
we
get
all
those
details
done,
then
we'll
have
enough
information
to
actually
say
all
right.
Here's
the
updated
pr
to
the
spec
that
has
the
config
object.
Then
we'd
go
from
there.
E
Not
not
to
make
it
like
much
more
complicated
but
like
if
we
had.
I
think
we
had
a
little
bit
of
this
issue
with
kind
of
the
earlier
versions
of
the
image
spec
that
we
were
trying
to
take
something
trying
to
take.
The
docker
schema
2
specification
and
make
something
that's
really
really
similar,
with
the
hopes
that
that
would
help
backwards,
compatibility
and,
in
the
end,
they're
different
media
types
and
the
backwards.
Compatibility
really
didn't
matter
that
much
like.
I
don't
know
that
it
actually
made
things
easier.
E
In
some
cases,
it
might
have
actually
made
stuff
more
hard
and
confusing,
like
we've
had
some
issues
like
the
implementation
and
in
the
distribution
and
the
open
source
registry
was
kind
of
weird,
because
it
was
trying
to
make
these
assumptions
that
they
were
the
same
when
they
they
weren't.
So
that
being
said
it,
it
could
actually
be
a
good
time
to
consider
moving
some
of
these
types
to
the
artifact
spec
at
least.
Consider.
A
E
A
So
is
this
remember
mike
we
talked
about
refactoring,
some
of
the
stuff
that
was
in
the
image
spec,
and
we
talked
about
taking
the
schemas
for
index
and
manifest
and
pulling
it
out
of
the
image
specs
so
that
basically,
distribution,
image
and
artifacts
could
reference
these
things
as
kind
of
independent
schemas,
because
it's
kind
of
weird
the
distribution
spec
doesn't
really
talk
too
much
about
it.
But
yet
it
does
because
we've
all
implemented
things
in
the
distribution.
A
E
Just
going
to
magically
support
it
like
no,
everything
is
going
to
have
to
go
and
explicitly
support
it.
Therefore,
you
might
as
well
do
it
exactly
how
you
want
it
to
be
done?
My
point
is:
like
the
delta
looks
small,
but
the
change
to
clients
is
is
almost
the
same
as
if
you
were
to
move
it
somewhere
completely
different.
So.
A
E
I'm
not
suggesting
that
we
we
just
change
everything,
because
I
think
that
the
incremental
approach
is
is
good.
I'm
just
saying
yeah
that
the
spec
we
can
move
the
spec
by
doing
that.
If
that's
the
I
mean
we
talked
about
the
artifacts
or
the
the
artifact
specification
being
the
better
place
to
have
this
index
so
that
if
you
come
across
and
index
b2,
you
know
exactly
what
it
is
and
how
to
handle
it.
D
E
A
That's
why
I'm
just
I'm
sorry,
I'm
still
trying
to
get
a
point
of
clarity.
Are
you?
Are
you
saying
that?
Because
I
agree
with
the
incremental
approach
like
we
talked
about
blowing
it
up
and
putting
a
property
called
artifact
type
like
just
just
make
it
very
explicit,
and
there
was
a
lot
of
concern
around
changing
too
many
named
elephants
elements.
Somehow
I
got
elephants
that
was
the
elephants
in
the
room.
We
also
talked
about
not
calling
them
layers,
but
calling
them
blobs
because
they
are
blobs
and
layers
has
an
implied,
meaning
specific
to
images.
D
E
Yeah,
I
think
I'm
just
I'm
just
advocating
on
behalf
of
like,
though
like
when
you
actually
go
to
implement
it.
If
you
were
to
move
this
to
the
artifact
spec
and
call
it
artifact,
spec
v1
versus
having
it
be
image,
spec,
v3
and,
and
actually
that
that
might
be
easier
in
some
cases.
I
I
think
that
might.
E
A
E
B
E
Yeah
so
from
the
container
d
perspective
like
yes,
the
client
is
obviously
going
to
know
about
existing
image
stuff,
but
what
you're
adding
here
is
whether
or
not
you're
adding
knowledge
of
a
a
newer
container,
manifest
or
container
image
manifest
or
just
a
artifact
manifest.
That
can
be
a
container
right.
It's.
This
is
the
same
change
to
the
client.
E
A
D
A
Okay,
so
we're
talking
more
about
where
we
put
the
spec
changes,
which
is
awesome
when
we,
because
we
weren't
sure
we
could
create
another
repo
for
the
schemas
or
just
put
in
the
artifacts
one.
I'm
fine
either
way.
What
I
really
like
is
it
won't
be
in
the
image
specs
so
that
we
don't
talk
about
writing
the
image
spec,
because
that
already
is
a
released
thing,
and
I
didn't
want
to
kind
of
break
the
glass
on
that.
A
Just
for
this,
as
in
addition
to
just
the
logistics
of
where
to
put
this,
which,
from
a
timing
perspective,
I'm
going
to
try
to
work
more
on
the
notary
stuff
to
kind
of
make
sure
that
what
we're
building
works
before
I
worry
about
doing
the
the
overhead
of
the
spec
review,
so
this
will
actually
have
a
case
like
hey.
This
is
what
we
learned.
A
For
okay,
so
alexa
had
some
questions
I
answered
him.
I
thought
I
did.
I
didn't
hear
back
so
we'll
see,
hopefully
we'll
we'll
see
if
there's
anything
new
there.
There
is
some
different
conversations
of
whether
it's
actually
a
config
object.
The
signature
is
in
the
configure
in
a
manifest,
but
honestly,
that's
like
an
implementation
detail
of
how
that
particular
artifact
works.
Being
the
notary
client,
the
whole
idea
is
that's
the
freedom.
It's
like
different
artifacts
can
use
the
different
technologies
as
they
choose.
That's
the
beauty
of
this
approach.
A
C
C
C
We've
had
several
of
them
close,
I
think
one
through
six
were
closed,
take
the
remainder
and
put
them
into
one
final
pr,
so
number
one.
Seven
eight
basically
is
the
remaining
changes,
and
then
there
was
another
comment:
derrick
made
that
we
were
ripping
we're,
basically
going
from
like
a
4
000
line,
spec
to
a
400
line
spec,
and
so
in
order
not
to
lose
some
of
the
deep
detail
we
had
from
the
original.
C
C
Please
help
review
this
message.
The
diff
will
be
a
little
strange,
so
this
is
the
actual
400
line.
Spec
can
be
found
here.
I
can
throw
that
in
hack
md,
but
you
know
if,
if
people
make
comments
on
here
like
I
see
sergey,
actually
made
a
bunch
of
comments,
we'll
be
sure
to
you
know,
get
back
to
it
asap.
So
we
can
get
this
out
as
soon
as
possible.
E
C
Yeah,
it's
been
kind
of
it's
been
like
open
since
early
june
and
there
hasn't
been
a
lot
of
shouting.
So
I
think
there's
there's
either
one
of
two
things
going
on:
one
which
is
probably
most
likely.
People
are
busy
and
coronavirus
season
and
then
the
other
one
is
people
just
don't
have
problems
with,
what's
being
what's
being
proposed.
So
if
that,
if
the
second
is
the
case,
then
yes,
let's,
let's
get
this
merged
and
and
move
on.
E
C
C
E
E
C
C
All
right,
so
the
other
topic
was
something
I'm
very
excited
about,
so
peter
peter
and
I
have
been
working
on
this
project
bundle
bar.
So
this
is
I
I
think
I
brought
it
to
oci
like
early
last
year,
but
originally
put
online
bundle
bar
as
basically
like
a
read-only
registry
for
helm,
charts
and
I
worked
with
gareth
rushgrove
to
get
a
single
one
of
his
open
policy
agent,
bundles
uploaded,
and
it
was
kind
of
just
a
fun
demo
project.
C
C
C
C
So
you
can
sign
up
if
you
want
to
try
it
out
with
like
a
github
handle
or
with
email
password,
but
I'll,
just
kind
of
really
quickly
walk
through
this
there's
a
very
very
few
pages
on
this
site
right
now,
so
the
main
page
is
the
repos,
and
this
is
just
all
of
the
repositories
in
your
in
your
account.
So
it's
you
don't
have
to
create
them
ahead
of
time.
C
C
And
then
I
have
my
handy
docs
here,
so
we
also
have
like
really
intense
docs.
So
if
you
go
to
bundlebar
docs,
we
have
lists
for
all
these
different
clients
and
like
how
to
use
them,
and
we
actually
have
our
own
cdn
and
signatures
on
these.
So
we
took
the
releases
the
latest
releases
for
all
these
tools
uploaded
to
our
cdn,
sign
them
with
our
public
key.
So
you
can
actually
validate
the
signatures,
but
we
kind
of
try
to
walk
through
how
to
use
it
in
the
simplest
way
possible.
C
B
C
C
D
C
C
B
C
C
C
But
thanks
for
listening
yeah.
Well,
you
know
I,
yes,
there's
a
money
thing
involved
here,
like
we'd
love
for
this
to
be
a
business
opportunity,
but
also
I'm
really
just
trying
to
explore
pushing
the
spec
forward
and
these
new
concepts-
and
I
was
also
talking
to
steve
about
potentially
you
know,
being
the
sacrificial
goat
for
notary
v2
and
you
know
so
we
don't
have
the
stability.
C
D
A
All
right,
we
don't
have
any
particular
agenda
next
week,
but
please
the
people
we've
been
with
kubecon
done.
We
were
summer's,
sadly
coming
to
an
end,
please
post
things
for
next
week
and
if
we
have
content
we'll
have
next
week,
if
not
we'll
try
to
try
to
get
the
can
amy-
and
I
are
tagging
each
other
on
mondays
like
to
be
sure
we
have
content
for
this
week,
if
not,
let's
free
up
people's
agendas.
So
please
get
agenda
items
in
before
monday
morning
and
we'll
see
you
next
time
thanks
folks.