►
From YouTube: OCI Weekly Discussion - 2022-11-10
A
B
B
D
B
Is
it
yeah?
Some
of
this
I
talked
to
him
yesterday,
and
some
of
this
came
out
of
that.
So,
if
he's
not
here,
I
volunteered
to
be
the
John
stand
in
and
I'll
try
not
to
mock
him
too
much.
D
D
A
B
Yeah,
the
first
item
is
probably
going
to
be
falling
on
deaf
ears,
because
I
don't
think,
there's
any
image.
Spec
maintainers
here
you
have
not
already
given
a
thumbs
up
to
this
PR,
but
I
will
go
and
bug
s
and
anyone
else
who
will
listen,
we'd
like
to
specify
an
image
spec
that
wasm
is
treated
differently
than
the
go
recommendation
happy
to
talk
about
this,
but
otherwise
I
was
just
hoping
there
to
be
another
image
back
maintainer
to
bug
in
the
recent.
So
we
can
move
on.
C
B
B
I,
don't
know
I,
don't
it's
not
it's
not
urgent.
Now
that
the
folks
that
were
violating
this
not
spec
were
you
know,
know
that
they
should
do
something
else
so
I'm
not
in
a
rush,
but
in
general
it
would
be
nice
to
have
more
active
image
back
maintainers
to
beat
a
dead
horse.
B
B
B
B
Like
if
you,
if
you
call
runtime,
go
OS
inside
of
JavaScript
duasm
thing,
it
would
say:
JS,
oh
interesting,
yeah
and
there's
no
there's
no
non-j
like
when
they
when
they
implemented
this
in
go.
Wasm
was
only
javascripty
was
only
used
in
javascriptiness,
so
it
made
sense
at
the
time.
But
now
wasm
has
like
you
know
five
more
years
of
growth
and
adoption
and
and
stuff,
and
so
I
think
that
was
just
a
little
behind
on
that.
B
B
Last
week
or
two
weeks
ago
or
three
weeks
ago,
Docker
Hub
announced
that
they
support
oci,
artifacts
and
I
found
out
yesterday
that
that
isn't
exactly
true
oci
artifacts,
as
described
in
the
in
the
you
know,
1.1
RC.
Whatever
release
is
a
new
manifest
type
with
media
type
artifact
and
an
artifact
type
field,
and
Etc
and
dockerhub
does
not
support
that.
The.
B
Okay,
okay,
that's
I
should
look
it
up
on
the
blog,
but
yeah.
E
A
B
Is
continued
sort
of
room
for
ambiguity
and
confusion
while
we
live
in
the
world
where
artifacts
can
mean
these
two
things.
B
From
the
oci
summit
that
we
had
before
kubecon
I
had
an
action
item
to
Ferry
out
useful
stuff
from
that
repo
into
image
spec
and
then
with
it
being
devoid
of
useful
stuff
archive.
It
and
say
like
look
over
here,
for
this
I'm
still
planning
to
do
that.
But
I
just
wanted
to
get
sort
of
more
people's
eyes
on
this
problem.
And
when
you
hear
oci
artifacts
understand
that
they
probably
mean
the
other
thing
than
what
we
mean.
E
Probably,
and-
and
they
were
specific
in
the
blog
that
you
know
that
what
they
were
doing
was
you
know,
modification
of
the
one
I
expect
using
or
you
know,
changing
the
type
from
image
to
you
know
an
artifact
type
right
on
the
mine
and
that
that's.
They
didn't
really
explain
that.
That's
not
supported
in
the
1-0
spec
right
now
in
Maine,
but
we
haven't
shipped
that
version.
Yet
you
know
a
new
release
that
has
the
the
restriction
for
using
the
artifacts
in
the
104
format,
as
was
done
by
or
as
and
and
the
artifacts
repo.
E
C
Yeah
yeah
I
was
going
to
say
they.
They
definitely
said.
Hey
we're
supporting
the
1-0
version
of
the
spec
and
part
of
the
reason
was
1.1
hadn't
even
been
released
yet,
and
so
they
don't
want
to
put
a
release
on
something
that
hadn't
been
released.
Yet
the
bigger
concern
I
had
was
when
they
put
the
filter
in
there
on
the
subject
field,
because
that
blocks
the
backward
compatibility
that
we
had
with
what
was
going
on
with
the
newer
implementation.
So
the.
A
B
I
have
a
I
have
an
un
like
an
unsent
PR
for
this,
that
I'm
just
I
need
to
do
a
little
wordsmithing
on,
but
anyway.
This
is.
This
is
a
mostly
unactionable
topic,
except
that
the
action
is
I
need
to
do
some
stuff.
I
just
wanted
to
sort
of
get
more
people
aware
that
we
are
still
confusing
folks
with
what
artifacts
means
pay.
A
E
A
B
B
But
yeah
all
right
before
I
before
I
monopolize
the
agenda.
Does
anyone
else
have
anything
else
they'd
like
to
talk
about
as
far
as
stuff?
Otherwise
we
can
go
into
refers
changes.
E
I
guess
one
one
thing
as
like:
I
guess
we
could
just
add
it
to
the
agenda.
Was
we
talked
about
creating
work
group
for
Authentication
like
to
get.
C
E
B
All
right,
if
there
are
no
other
blockers
to
me,
monopolizing
I'm
gonna
go
ahead
and
monopolize
I
talked
to
John
a
bit
yesterday
and
there's
also
this
issue
357
in
distribution
spec
about
loosening
some
of
the
requirements
in
the
refers
API
to
be
maze
instead
of
musts,
not
even
shoulds,
but
all
the
way
back
to
may
I
know.
B
This
was
a
topic
we
talked
about
months
ago
for
probably
months
at
a
time
in
the
ref
in
the
reference
working
group,
but
I
think
I
am
convinced
by
his
argument
that
we
should
soften
these.
Does
anyone
have
a
strong
reason
not
to
soften
them?.
E
A
B
B
A
B
E
B
That
the
the
this
is.
B
The
subject
refers,
response
includes
the
referring
manifests,
annotations
hoisted
not
not
each
of
the
blobs
annotations,
just
the
like
top
level,
annotations
and
I
think
that
is
a
bit
a
bit
onerous
on
the
registry
to
be
able
to
do
that
processing
at
the
kind
of
scale
we're
talking
about
the
alternative
or
an
alternative
to
that
is
that,
if
you
want,
the
annotations
of
that,
you
have
to
your
client
has
to
go
fetch
that
manifest
and
get
those
annotations
or
and
I
liked
this
as
an
option
as
a
as
a
possible
mitigation
to
this
that
the
registry
I
think
the
word
is
May.
B
The
registry
May
embed
that
manifest
as
data
in
that
descriptor
and
now
you
have
access
to.
You-
may
have
access
to
the
annotations
and
everything
in
that
manifest
inlined
in
that
response
for
each
object
for
each
manifest
referencing.
The
thing
makes.
E
C
Yourself,
I
think
yeah
I
comment
on
the
issue,
so
I
was
just
going
to
raise
up
those
comments
just
to
put
them
for
the
overall
Community
here.
The
two
concerns
I
have
one.
If
we
do
the
data
field,
because
that's
pulling
the
entire
manifest
in
that
could
also
pull
in
data
fields
within
that
child,
manifest,
which
means
you're
now
growing
this
thing
rapidly,
because
the
date
appeal
is
not
as
compressed
as
a
man
immune
base64
encourage
something
that's
larger
than
what
it
originally
was
and
because
we
say,
may
we
might
even
be
dropping
those.
C
So
there's
that
risk
the
bigger
risk
is
because,
once
we
say
may
on
the
annotations,
if
I
pull
an
image
and
say
query
and
tell
me
all
the
things
that
point
to
it
and
a
registry
comes
back
and
says
these
50
different
manifests
have
a
reference
pointing
over
to
that
and
it
doesn't
fill
in
the
rest
of
the
annotations
and
I'm
looking
for
the
most
recent
or
something
that
matches
a
gpg,
fingerprint
or
whatever
criteria
I
had
to
know
which
manifest
I
want
to
pull.
I
have
to
pull
all
50
of
those
manifests
individually.
C
B
The
I
think
we
could
say
Registries
should
do
one
or
the
other
or
Registries
should
set
the
data
field.
B
We
have,
we
have
an
option
between,
must
and
may
that
we
could
that
we
could
use
I'd,
we
can
argue
about
which
one
should
be
a
should,
but
there's
at
least
it's
worth
noting.
There
is
a
note
between
May
and
must,
as.
B
B
You
want
to
make
50
requests,
and
so
it
sort
of
benefits
the
registry
to
do
one
or
the
other,
based
on
its
like
its
idea
of
which
is
easier
to
do.
I,
don't
know
that
I
don't
know
how
every
registry
is
implemented.
I,
don't
know
whether
one
would
be
easier
or
harder
to
implement
for
any
given
registry,
but
it
seems
worthwhile
saying
that
Registries
should
do
one
or
the
other
for
their
own
benefit
as
much
as
for
the
client's
benefit.
It's
it's
useful
for
the
registry
to
do
that.
C
B
If,
if
the
response
includes
the
data
field,
you
know
because,
or
you
know,
it
has
populated
not
only
the
annotations
but
of
the
whole
the
whole
manifest
in
that
data
field.
If
it
returns
annotations,
you
know
that
it
is
giving
you
annotations
if
it
is
giving
you
annotations,
but
it's
the
empty
set
of
annotations
you're
right,
there's
no
way
for
you
to
know
whether
that
is
an
empty
set
of
annotations
or
a
populated
empty
set
of
annotations.
If.
B
B
Think
I
would
recommend
against
Registries
trying
to
do
smart
stuff,
like
that.
B
For
my
own
part,
I
think
returning
the
whole
data
field
is
an
elegant
option
for
the
registry,
because
you
get
to
Short
Circuit
all
the
requests
you
you
may
like
to
your
point.
You
may
embed
data
twice,
which
is
a
bit
gross,
we'll
base
64
things
twice,
but
if
it
is
a
small
like
specifically
signature
data,
you
can
avoid
a
lot
of
hops
to
return
the
you
know
a
couple
of
K
A
couple
of
hundred
bytes
of
data.
You
might
care
about.
B
A
lot
of
data,
if
we
say
the
registry
May
return,
May
Hoist
the
data
field.
That
is
not
registry-wide.
That
is
request
wide.
The
registry
can
now
make
a
decision
about
whether
it
says
you
know
it's
a
signature,
it's
under
a
k
and
so
I'll
embed
it
or
it's
a
500
megabyte.
You
know
s-bomb
you're,
going
to
have
to
fetch
that
yourself
I
think
I
think
it
gives
a
lot
of
flexibility
to
the
registry
to
to
do
what
it
thinks
is:
cheap
and
worthwhile.
C
G
Yeah
I
I'm
catching
ice
I'm
catching
up.
I
I
thought
the.
G
B
G
B
Right
the
the
registry
May
Hoist,
the
annotations
from
that
manifest
it
may
Hoist
the
whole
thing
into
the
data
field.
It
may
implicitly
do
neither
but
I
think
that
that
is
something
Registries
should
not
do.
I
think
we
should
say:
registry
should
do
one
or
the
other
first
right
or
sort
of
to
avoid
mistakes
like
that
I.
G
It
should
change
based
on
the
biggest
the
biggest
piece
I,
wouldn't
want,
like
some
references
in
the
response
to
have
data
and
some
not
to
and
some
to
have
annotations
and
some
not
too,
like
I,
think
clients
should
be
able
to
expect.
If
I
don't
know.
We
like
it
just
seems
like
it's
confusing
with
with
all
of
these
maze,
it
seems
like
clients
are
gonna,
have
to
write
a
lot
of
code
and
Registries
are
you
know,
because
of
that
probably
some
bugs,
and
so
some
Registries
will
work
and
some
won't
and
I
don't
know.
B
Think
that's
a
worth
like
a
I,
think
that's
a
useful,
Viewpoint
I!
Think
that's
that's
right,
like
less
complexity,
good
I
think
the
least
complex
thing
would
be
to
not
hoist
either
and
the
client
always
knows
it
has
to
go
and
fetch
those
manifests
if
it
things
that
might
care
about
annotations
or
things
that
might
care
about
the
stuff
in
there.
The
simplest
thing
to
do
is
sort
of
Brute
Force.
Now
you
make
a
bunch
of
requests
which
we
could
also
change
the
spec
to
say
that
it
will.
You
know
it.
B
D
D
B
I
think
that's
I
think
that's
pretty
out
of
character
for
a
registry
like
I.
Think
it's
it's
pretty
unusual
for
a
registry
at
least
using
standard
oci
apis
to
inject
new
data.
I
would
be
I.
Think.
D
C
I
would
say
that,
because
annotations
are
a
field
that
are
open-ended
for
the
client
to
provide
on
their
manifest
that
if
you
start
putting
a
field
in
there,
there's
a
very
possibility
of
a
collision,
potentially
in
intentional
that
a
client's
trying
to
override
that
field.
So
it
might
make
more
sense
to
put
any
other
metadata
in
another
field,
because
you
can
always
add
another
piece
into
a
descriptor
with
a
different
name,
not
an
annotation,
not
a
descriptor.
Any
of
those
things
just
another
field
in
there.
B
E
C
E
Hey
you'll
be
fair
for
the
client
to
set
The
annotation
in
the
artifact.
No,
the
server
doesn't
see
it
to
add
it,
but
at
the
same
time
that
changes
the
digest
so
yeah.
C
Maybe
not
yeah
I
would
not
want
to
modify
the
Manifest
and
I
I
wouldn't
want
to
potentially
step
on
a
field
that
is
in
the
Manifest.
So
I
would
say
if
you're
making
your
descriptor
you've
got
the
digest.
You've
got
the
media
type.
You've
got
the
annotations,
make
a
fourth
field
that
we
haven't
defined.
Yet.
B
Yeah
I
think
I
think
I
I,
I
I
would
argue.
I
definitely
don't
want
the
server
to
inject
Dynamic
content
into
my
manifest
ever,
even
if
I
like,
even
if
I
didn't
specify
the
created
time
for
this
I
want
that
to
be
heavily
cachable
and
content
addressable
and
not.
B
B
D
E
C
But
the
annotations
that
are
in
that
descriptor
come
from
the
Manifest,
and
so
you
have
a
namespace
collision
problem
where,
if
you
start
putting
a
field
in
there,
if
you're
an
annotation
name,
it's
very
possible,
the
Manifest
can
put
the
same
annotation
name
in
there.
So
I
would
say
to
avoid
Collision
inject.
D
C
B
I
think
that
also
says
to
me
that
a
a
registry
that
wants
to
inject
this
information
can,
because
you
can
add
whatever
Fields
you
want
to
any
type
except
for
reserved
stuff
I,
don't
know
if
we
even
had
those
but
like
if
Brandon's
registry
wants
to
inject
more
fields.
That
say
when
this
manifest
was
created
and
mine.
Doesn't
then
we're
all
welcome
to
do
that,
and
eventually,
if
clients
pick
it
up
and
want
to
do
it,
we
we
may
all
agree
to
do
it
and
specify
it.
B
Some
of
the
difficulty
in
the
doing
the
reference
API
design
work
was
that
none
of
us
have
implemented
it.
Yet
it's
not
something
anybody
we're
not
specifying
a
thing.
We
implemented
we're
specifying
a
thing
we'd
like
to
all
implement,
so
it's
a
bit
backwards
and
hard
to
do
well.
D
B
D
I
yeah
I'm
trying
to
go
through
some
of
that
process.
Now
I
yeah,
the
the
refers
API
itself
is
kind
of
thorny
I
I
feel
like
from
a
client
implementation
side.
B
I
think
we
I
think
that's
useful
feedback
and
like
please,
please
tell
us
where
the
Thorns
are
and
we'll
try
to
break
them
off,
like
I'm
I'm,
also
implementing
a
client,
a
client
library
to
do
this
and
hitting
things
that
kind
of
suck
and
I
think
I
think
we
knew
because
we
were
designing
it
all
before
anything
was
built
that
we
have
to.
B
D
Sure
I
mean
I
I.
Think
one
of
the
concerns
I
had
is
kind
of
like
at
what
you
were
saying
at
the
beginning.
Talking
about
oh,
are
we
gonna?
Are
we
going
to
pull
down
these
50
objects
or
or
whatnot,
like
I,
think
from
a
client
perspective,
especially
from
containerdy?
We
do
kind
of
more
of
a
synchronization
approach,
so
we're
trying
to
figure
out
how
do
we?
D
How
do
we
approach
this
refers?
Api,
that's
kind
of
unbounded,
as
opposed
to
images,
aren't
really
unbounded
in
size,
at
least
from
number
of
like
objects
that
we
would
need
to
pull.
Obviously,
layers
can
be
unbounded
in
size,
but
the
number
of
objects
we
pull
is
not
unbounded.
But
now
here
we're
trying
to
look
at
this
API.
That's
that's
potentially
unbounded.
It's
unclear
like
what
objects
we're
actually
going
to
need
from
that
and
I
I
understand.
The
annotations
are
intended
to
to
help
with
that.
D
D
So,
if
you're
doing
some
sort
of
signature
check
likely
there's
going
to
be
one
signature,
Maybe,
maybe
two,
but
for
the
most
part
we're
dealing
with
a
pretty
small
set
of
objects
that
are
needed
and
from
a
registry
perspective
you
know
yeah.
They
don't
want
to
serve
up
all
those
objects,
but
the
the
language
now
makes
it
sound
like
the
registry
has
to
keep
around
every
object
that
it's
given
and
has
to
give
them
all
out,
which
I
don't
understand.
Why
that's?
D
B
So
there
were
a
few
things
in
there
and
I
want
to
make
sure
that
that
I
got
them
all
one
is
that
perhaps
the
registry
would
like
to
delete
things
that
refer
to
things
without
the
user's
input.
Is
that
something
that
you're
interested
in.
D
D
But
if
you
know
about
it,
it
might
still
exist,
but
it
at
that
point
it
might
be
kind
of
eligible
for
garbage
collection.
I,
see
the
same
thing
here
with
like
signatures.
You
may
sign
something
you
know,
and
then
you
may
go
through
and
want
to
overwrite
that
previous
signature,
but
yeah
from
a
client
perspective.
You
might
be
in
a
case
where
now
you're
just
serving
up
multiple
signatures
to
the
client.
D
The
client
now
just
has
to
go
back
through
and
filter
it
rather
than
having
some
explicit
way
to
just
say:
okay
I,
don't
you
know
I
want
to
replace
this
one
thing,
maybe
like
there's
no
Central
like
identifier
to
say:
hey
I,
have
this
artifact
and
this
kind
of
artifact
ID
that
I'm
trying
to
like
overwrite
or
I'm,
trying
to
use
like
I,
have
one
signature
that
I
want
and,
as
it's
coded
today,
it
seems
like
yeah.
You
can
just
have
them
unbounded
and
not
a
clear
way
to
manage
that
yeah.
B
I
think
that's
I
think
that's
the
signing
client's
responsibility
to
solve
like
if,
if
I'm,
if
I'm
sick,
if
I'm
signing
an
image
or
an
artifact
or
whatever
I,
have
to
decide
at
that
moment
whether
I'm,
appending
my
signature
or
replacing
all
signatures
with
mine
or
replacing
you
know,
I
only
want
to
keep
the
last
five
signatures,
and
so,
if
this
is
the
sixth
signature,
find
the
oldest
one
and
delete
it.
That
seems
like
all
client.
D
If
it's
a
compatibility
mode,
I
think
actually
going
back
from
the
client
perspective,
I
I,
like
the
compatibility
mode
more
than
the
refers
API,
because
in
the
compatibility
mode
it's
very
clear,
yeah,
okay,
here,
here's,
the
signature,
let
me
overwrite
it
and
then
upload
it.
I
know
it
has
it's
that
its
own
Thorns
for
consistency.
But
from
the
standpoint
of
like
a
client
perspective,
the
compatibility
mode
is
actually
pretty
nice.
Yeah.
B
To
in
order
to
replace
a
signature
in
the
refers
API
world,
you
have
to
add
your,
you
know
create
a
new
thing
that
refers
to
it,
go,
look
up
its
references
or
look
up
its
referrers
and
then
delete
any
old
ones
that
match
that
you
want
to
replace,
and
you
either
do
that
before
or
after,
but
either
way
it's
it's
sort
of
a
a
two-step
process.
So
yeah
I
agree
that
it's
a
bit
more
magical
on
the
on
the
registry
side.
Brandon
go
ahead.
C
I'm
just
going
to
add
to
that,
if
any
attempt
to
do
that
on
the
registry,
server
set
I
feel
like
you're
gonna
fail
as
soon
as
the
next
unknown
kind
of
artifact
type
shows
up,
and
you
don't
know
how
to
process
it
and
how
to
dedup
it.
It's
we.
We
don't
know
how
users
are
going
to
use
this
tomorrow.
We
know
how
they
might
use
it.
D
So
from
the
from
the
client
side,
I
feel
like
what
we're
going
to
have
to
do
like.
Usually
we
deal
with
this
kind
of
unbounded
response
case
from
a
registry
is
have
some
sort
of
like
limits
limits
that
we
have
to
put
in
there,
which
then
it
comes
into
the.
How
do
we
sort
and
I
think
that
brings
up
the
previous
conversation?
D
Relevance
of
it,
which
is
you
know
if
the
only
way
we
can
sort
and
filter
is
based
on
annotations
like
having
to
go
fetch
a
bunch
of
content
just
to
just
to
say
we
don't
need.
It
is
not
a
it's
not
a
great
case,
but
yeah
I
think
John's
concerns
are
valid
as
well.
That's
kind
of
why
I
suggested
you
know.
Is
there
some
way
like
if
the
registry
does
have
logic
or
doing
some
sort
of
filtering
or
sorting?
D
F
A
C
D
I'm,
certainly
not
thinking
of
I
know
we
talked
about
in
terms
of
like
yeah,
be
able
to
pass
like
arbitrary
annotations
or
something
like
that.
That's
definitely
not
what
I
was
thinking
of
there
for
the
most
part,
I
think
it's
more,
which
is
the
most
recent
of
a
specific
artifact
type,
is
probably
going
to
be
most
relevant
for
those
cases
it.
C
It
might
be
relevant
in
some
cases
and
then
you
get
to
next
ones
where
someone
says
well.
I
want
the
most
recent,
but
it
needs
to
match
this
filter
because
I
don't
care
about
the
other
person
that
signed
it
I
care.
If
this
person
signed
it
or
I,
don't
care
the
most
recent
s-bomb
I
want
the
most
recent
s-bomb
in
this
format.
C
So
there's
there's
always
some
other
case
in
there
that
we
haven't
planned
on.
What
we
did
do,
though,
was
we
tried
to
push
a
lot
into
the
client
side?
So
that's
why
we
push
all
the
annotations
back,
at
least
until
I
get
it
written
on
that
one
and
we
allow
you
to
filter
by
the
media
type,
so
you
can
at
least
knock
out
a
large
chunk
of
it.
C
You
end
up
sharding
the
data
and
say
you
only
pull
back
media
types
that
you
recognize
and
then
the
biggest
thing
to
me
is
if
you
look
at
you're,
not
pushing
too
many
annotations
you're
talking
about
a
thousand
some
odd
responses
before
you
hit
the
or
make
size
limit
on
index,
and
then
you
have
paging
and
there's
another
ability
in
to
continue
that
even
more
so
I
feel
like
we've,
got
pretty
good
flexibility
to
scale
this
up
pretty
large.
Before
you
run
into
issues
and
that's
per
image,
so
yeah,
it's.
D
F
So
we've
been
considering
implementing
it
with
filtering
and
not
but
sorting
by
The
annotation.
That
is
called
out
in
the
chat
right
now.
So
the
artifact
created
time
is
what
we
at
least
from
Azure,
set
that
we
were
thinking
of
using
as
a
default
way
of
sorting
things,
because
it's
not
specified
in
specification,
but
this
annotation
specifically
was
called
out.
F
The
problem
is
we
don't
have
an
actual
use
case
and
clients
implementing
it?
So
we
don't
know
exactly
whether
that'll
be
useful
or
not.
So
it's
a
it's
a
rough
cut
but
I
think
the
question
that
we're
talking
about
is:
yes:
we
want
to
find
out
the
the
the
latest
thing
that
people
have
pushed
or
attached
to,
but
the
second
level
of
filtering
will
not
work
with
this,
because
if
it's
a
signature
that
comes
afterwards,
you
still
want
to
maybe
look
at
the
key
depending
on
the
key
and
whatnot
right.
F
So
there's
a
little
bit
of
a
challenge
there,
but
just
to
kind
of
like
share
with
this
group.
The
Creator
time
is
definitely
something
that
we
are
interested
in
kind
of
pursuing
as
an
implementation.
Also
through
I
I.
Don't
know
whether
other
operators
want
to
kind
of
take
that
path,
but
that's
something
that
we
we
felt
this
at
least
important
to
look
at.
F
Timely
yeah,
because
the
client
is
generating
the
data.
The
client
can
corrupt
the
data,
there's
nothing
stopping
them
from
pushing
a
signature
up
or
re-pushing
the
same
blob
with
new,
manifest
and
a
new
creative
time,
so
they
can
control
how
the
sort
order
is
fully.
That's
the
whole
reason
why
the
sort
implementation
is
actually
controlled
by
the
client
indirectly
because
they
decide
where
the
item
needs
to
come
as
well.
Yep.
B
F
B
Right
like
what,
if
what,
if
the,
what,
if
my
registry
is
antagonistic
and
is
mostly
sorted
except
the
last
two,
things
are
out
of
order,
there's
no
way
to
guard
against
that
in
a
general
way,
but
I
I
think
it's
useful
to
have
that
optimization.
You
know
you.
You
are
free
to
have
your
sorting
order,
whatever
you
want
it
to
be,
and.
B
Yeah,
which
says
to
me,
we
should
specify
as
little
as
usefully
possible
and
wait
for
people
to
use
it
and
then
sort
of
pave
the
cow
pads
that
people
are
using
it
for,
rather
than
try
to
try
to
guess
what
people
use
it
and
not
that
you
are
doing
that.
I
think
you
are
doing
a
good
thing
for
your
for
your
use
case,
but
whenever
we
don't
have
users
and
we're
designing
something,
I
want
to
design
as
little
as
possible
until
people
start
to
use
it.
C
I
think
the
vision
we
had
when
we
were
originally
writing.
This
was
that
we
would
potentially
have
a
whole
lot
more
advanced
filtering
in
there,
so
you
could
say
sort
by
this
one
field,
but
only
on
the
entries
that
match
this
other
annotation
and
it
would
all
be
annotation
based
and
so
that's
still
possible.
It
doesn't
mean
that
what
we've
implemented
now
is
the
only
thing
we've
got
but,
like
Jason
said
we
we
start
with
a
minimum
viable
product.
C
B
Yeah
so
I
don't
know,
I
don't
know
if
we've
come
to
any
useful
conclusions
or
useful
things
to
try
to
push
on.
D
I
think
my
concern
was
more
the
other
way
around
like
instead
of
managing.
You
know
more
and
more
and
more
and
more
refers,
but
try
to
Define
ways
that
keeps
that
set
of
refers
small
and
useful
for
the
client,
because
I
think
in
the
majority
of
use
cases,
there
doesn't
need
to
be
thousands
of
refers
that
that
is
an
edge
case
that
we
should
maybe
support,
but
like
in
container
D.
B
That's
that's
also
complete.
Like
that's
a
good
thing
to
note,
it
is
totally
viable
for
a
registry
to
limit
the
number
of
things
that
can
refer
to
a
thing
and
for
a
client
to
limit
how
many
pages
it
will
fetch
and
you
maybe
never
fetch
the
second
page.
These
are
all
completely
valid
things
for
people
to
to
limit.
C
D
Yeah
we're
trying
to
figure
out
whether
it
makes
sense
to
pull
or
have
an
option
to
report
when
you,
when
you
pull
an
image
and
you
fetch
an
image
down
whether
to
fetch
the
refers
as
well.
The
problem
is,
as
you
guys
just
saying
like.
If,
if
there's
like
a
couple
refers,
it
makes
sense.
If
there's
50
refers,
it
doesn't
make
sense.
D
The
idea
is
like
we
don't
it's.
A
continuity
does
more
of
like
a
synchronization
approach
like
we
synchronized
content
locally,
and
then
we
make
use
of
it
like
we
synchronize
the
content
first
and
then
we'll
unpack
it,
but
we
have
more
and
more
use
cases
like
lazy
loading
snapshotters
where
we're
not
necessarily
syncing
down
everything,
we're
syncing
down
metadata
and
then
letting
specific
plugins
go
back
through
and
pull
them.
D
D
So
I
mean
you
could
think
of
like
a
image,
validation,
plugin
that
runs
during
poll
that
wants
to
to
access
signature
data
or
some
sort
of
deferred
data
and
make
use
of
that
and
yeah
I
guess
for
us,
it's
like:
where
do
we
make
that
decision
like
I,
think
the
compatibility
mode
makes
it
easy
for
us,
because
it's
very
clear
what
what
metadata
we
need
to
fetch.
D
C
A
C
You
know
annotations
and
as
soon
as
the
rest
of
them
were
already
done
correctly
on
the
first
time
so
yeah.
That
was
one
key
point.
The
other
one
I
really
want
to
dig
into
on
container
D,
though
my
fear,
the
thing
that
concerns
me.
If
you
pull
down
a
signature,
no
big
deal
there,
they
should
be
small.
They
should
be
easy,
pull
down
with
the
image
you
start
playing
down,
s-bombs
those
are
going
to
get
significantly
larger.
So,
if
you're
pulling
the
Manifest
okay,
that's
cool.
C
If
you
start
pulling
down,
blobs
I
get
really
worried
about
performance,
long
term,
because
I've
have
planned
some,
not
plans
like
currently
Implement
stuff
that
attaches
very
large
things
to
images
and
I.
Don't
want
a
10
mega
image
to
have
to
pull
down
a
couple
hundred
Megs
of
other
metadata
you're.
A
C
F
Oh
yeah,
we
haven't
spoken
about
that.
I
had
a
question
for
the
continuity
implementation,
because
this
is
really
an
awesome,
useful
data
right
are
we,
so,
let's
assume
that
there
are
multiple
different
types
of
artifacts
that
have
been
attached
is
you're,
thinking
that
you
will
pull
down
every
type
or
will
you
at
least
filter
by
some
specific
media
type?
F
That's
that's
one
thing
that
would
help
to
kind
of
like
at
least
ask
for
only
the
things
that
you
want
right,
because
if
you
want
to
pull
down
everything
and
if
you
have
a
scan
report
a
test
every
day,
that's
going
to
be
a
lot.
So
where
is
what
is
the
thinking
right
now.
D
Well
and
that's
that's
kind
of
worth
figuring
out
like
we're
just
adding
the
low
level
part
now,
which
basically
gives
access
from
our
registry
configuration
to
call
the
refers
API
and
then
try
to
handle
the
compatibility
mode
kind
of
automatically
for
you,
but
I
think
as
Brandon
was
saying,
it's
like
there's
no
like,
like
the
our
apis
are
lower
level,
at
least
like
at
the
remote
end.
D
It's
just
giving
you
a
reader
and
that
reader
is
expected
to
be
oci
index
but,
like
obviously
the
if
you
pass
in
an
artifact
type,
which
I
did
add
artifact
type
to
the
to
the
API
I'm,
not
sure
that
it
makes
sense,
because
maybe
we
want
other
filters
as
well,
but
now
we're
talking
about
who's
applying
that
filtering,
because
if
you
pass
the
artifact
type
up
to
the
registry,
the
registry
is
doing
that
filtering,
but
it
if
the
registry
doesn't
support
the
refers
API.
D
Then
you
potentially
just
get
back
that
that,
like
it's
ignored
so
like
from
the
client
perspective
like
do
we
apply
that
filtering
normally
in
container
D,
it's
like
our
back
end
apis
from
the
registry.
We
don't
touch
the
data
that
comes
back
to
it,
but
it
seems
like
in
this
case
the
registry
could
be
touching
it.
You
know,
in
terms
of
like
the
registry
could
be
applying
filters
to
that
oci
index,
so
long
long
way
to
say
not
sure
exactly
what
we
want.
F
F
The
oras
project
was
using
just
a
reader
and
there's
no
way
that
we
actually
looked
at
the
Manifest,
so
we
couldn't
apply
the
filter
on
the
index
for
us
a
very
similar
reason,
but
from
the
API
standpoint,
I
think
recommending
users
to
use
the
artifact
type
might
be
the
might
at
least
guarantee
some
amount
of
filtering
both
from
the
server
side
or
if
you
have
a
giant
index
with
everything
mixed
in
it.
At
least,
you
only
start.
F
Looking
at
the
descriptors
that
you
really
need
to
ignoring
The
annotation
filtering
and
the
data
field
filtering
part.
D
Yeah,
it
depends
a
little
bit
too
what
what
that
interface
for
making
use
of
the
refers
looks
like
because,
if
it's
a
in
continuity,
it's
likely
to
be
a
plug-in
interface.
D
So
you
could
have
plugins
that
care
about
different
artifact
types
like
that
want
to
say,
hey
like
by
the
way
when
you're
fetching
the
refers
like
make
sure
you
grab
the
artifact
type
that
I
care
about,
and
then
like
do.
We
have
a
bunch
of
plugins
that
are
registering
artifact
types,
they
care
about
and
then
just
kind
of
side
loading,
those
or
going
back.
D
The
other
way,
which
is
not
have
pull,
do
anything
related
to
refers,
but
having
the
plugins
themselves
just
able
to
when
I
say:
hey
like
plug
in
you
wanted
to
verify
this.
You
want
to
verify
it
the
content,
here's
the
digest-
and
you
know
you
go
up
to
the
registry
and
fetch
it
yourself,
which
seems
to
be
more
like
what
the
API
is
designed
for
and
I.
Don't
know
if
that's
more,
like
kind
of
in
the
auras
world
of
like
you're,
not
really
synchronizing,
stuff
you're,
just
making
requests
to
the
registry
right.
F
So
the
so
the
verified
architecture
that
you
spoke
about
is
like.
We
were
thinking
of
it
like
a
push
versus
pull
model,
which
is
the
plugin,
is
actually
registering
for
a
certain
set
of
artifact
types
which
and
the
the
person
the
the
client
that's
actually
pulling
would
actually
have
to
go
query
each
one
of
those
right
which
is
which
is
one
way
versus
if
you
delegated
to
the
plugins,
each
plugin
will
have
to
know,
have
to
know
the
authentication
model
and
then
go
back
as
well.
F
So
I
think
both
models
have
challenges,
but
but
I
think
what
we're
all
agreeing
on
is
artifact
type
is
a
is
a
good
place
to
settle
on
at
least
as
a
filter.
Otherwise
you
end
up
getting
everything
and
if
Brandon
starts
attaching
vhds
to
images
or
something
like
that,
then
we'll
have
problems
right.
People
are
going
to
attach
expanded
images
to
an
image
is
what
I'm
guessing.
So
you
don't
want
to
pull
that
down.
C
Yeah
my
specific
use
cases
reproducibility,
where
I
attach
all
the
network
traffic
from
a
hermetic
field
and
so
putting
that
into
an
image
adjacent
to
an
image.
Your
little
10,
Meg,
Google
image
or
a
golang
image
is
going
to
be
significantly
larger.
When
you
look
at
all
the
goaling
modules,
you
have
to
pull
down
to
build
that.
D
Yeah
I
think
one
thing
that
makes
it
complicated,
though,
from
the
API
standpoint
like
I
I,
agree
about
like
filtering
on
the
artifact
types
and
I.
Think
we'd
certainly
do
that
in
containerd.
The
same
way
we
filter
like
platforms
out
of
an
index
like
like
yeah,
you
go
to
pull
an
image,
but
if
you
only
want
to
unpack
a
certain
image,
we're
only
going
to
pull
the
content,
that's
related
for
the
specific
architecture,
you're
in
I.
Think
the
same
thing
could
apply
here.
D
I
think
the
tricky
part
with
the
artifact
or
the
registry
doing
the
artifact
filtering
is
so
we
pull
in
this
oci
index.
But
it's
like
it's
a
it's
an
index,
that's
specific
for
that.
Artifact
type
like
if
you
come
back
through
and
you
want
a
different
artifact
type.
D
Now
we
have
another
index
that
we're
trying
to
maintain
in
ideally
from
like
how
we
want
to
refer
data
and
kind
of
collect
it
is
we
would
like
to
just
have
we
have
our
image
we
have
that
image
can
enter.
D
is
a
tag
which
points
to
a
manifest,
an
image
manifest,
and
then
we're
going
to
have
some
link
between
that
image
manifest
and
the
refers
index,
and
then
that
refers
index
will
have
its
own
sub
manifest,
and
then
we
can
have
logic
for
applying
what
we
what
we
synchronize
locally.
D
D
So
yeah
it's
definitely
a
tricky
one,
but
I
I
agree
with
it.
So
much
I
was
saying
and
if,
if
you
know
how
I
like
to
implement
registry
interactions,
I
I,
don't
like
the
long
tail
of
continuing
to
make
registry
requests
forever,
like
even
the
lazy
loading
case,
has
complications
around
authentication
and
continuing
to
hold
on
to
that
authentication
indefinitely.
D
E
D
Yeah
they
should
have
some
limited
life,
associate
them,
but
I
mean
for
the
validation
plugins.
It's
it's,
probably
not
that
hard,
because
yeah
there's
there's
likely
to
happen,
at
least
in
the
scope
of
a
poll
like
it's
not
like
later
on
and
that's
if
they
go
through
well,
I'm
sure
people
would
say
hey
when
I
run
my
image,
that's
when
I
want
to
do
the
validation
or
something,
but
you
can
treat
that
as
a
as
a
new
request
at
that
point,
but
yeah
it's
it's
it's.
D
It's
definitely
tricky
having
it
be
beautiful,
but
I
still
at
least
the
way
of
implementing
it.
Now
from
containerdy,
it's
more
like
a
sink.
The
way
we're
doing
it.
When
you
do
a
poll,
you
you
see
the
content
and
what
Mike
was
saying
it's
mutable,
but
so
are
Tagged
so
like.
If
you
do
a
fresh
poll,
you
potentially
get
a
fresh
set
of
refers
and
synchronized
down.
A
I
think
container
D
we'll
have
to
figure
out
how
do
we
let
the
higher
level
parts
of
the
stack
either
plugins
or
the
containing
client
figure
out
and
tell
continuity
what
artifacts
they're
interested
in
that
are
attached
like
confidential
containers?
You
know,
you
probably
know
fairly
high
up
in
the
stack.
You
want
to
run
this
image
in
a
confidential
manner.
So
now
you
need
to
know
a
certain
artifact
type
that
you
go
and
fetch
to
get
a
signature
when
you're
pulling
it
figuring
out.
D
Process
I
think
the
initial
getting
it
working
and
trying
it
out
is
probably
not
going
to
make
use
of
the
artifact
filtering
on
the
registry
side
to
start,
which
is
kind
of
why
I
was
kind
of
concerned
about
this
idea
of
just
them.
Growing,
larger
and
larger
and
larger
I
mean
realistically
I.
D
Don't
think
we're
going
to
be
dealing
with
cases
that
have
like
50
different
artifact
types,
I'm,
not
saying
that's
not
the
case
but
like
first
we're
trying
to
like
solve
like
the
80
90
percent
of
user
case,
which
I
think
is
pretty
simple,
but
like
we'll
code
against
that
first
and
then
Branch
out
to
these
Brandon
or
that
is
Brandon
edge
cases
or
sorry.
The
Brandon
primary
case,
which
I
don't
know.
I,
don't
want
to
call
you
an
edge
case.
That
sounds
insulting,
but
like
a
completely
non-edged
normal
cases
that
Brandon's
talking
about.
C
D
B
Mean
sure
what,
with
with
us
being
in
time,
I
don't
know
if
anything
actionable
has
come
out
of
this,
but
please
keep
talking
about
this
and
file
stuff
and
issues.
If
you
think
that
that
things
should
be
specified
better
or
differently
or
restricted
or
loosened,
or
whatever
yeah
I.
D
Think
there's
just
some
of
the
must
cases
I
feel
like
kind
of
let
John
was
saying
that
maybe
they
shouldn't
be,
must
or
further
guidance
that
needs
to
be
given
to
the
clients
for
these,
but
yeah
I
agree,
there's
other
than
kind
of
ranting
about
it
right
now
and
getting
figuring
out
where
everybody
else
is
is
kind
of
all
I'm.
Looking
for
today,.