►
From YouTube: OCI Weekly Discussion - 2021-10-07
Description
Recording of the OCI weekly developer's call from 7 Oct 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#October-7-2021
B
B
C
A
About
is
that
there
was
a
different
level
of
conversation
that
there
were
people
in
person
that
you
know,
I
won't
really
say
intensity.
Just
the
nature
of
conversation
that
people
that
were
in
person
were
able
to
communicate.
That
just
is
not
conveyed
over
video
chats
and
I
think
it
allowed
everybody
even
on
the
video
chats
to
participate
in
that
same
similar
way.
A
I've
wanted
to
close
it
a
couple
of
times
since
I've
opened
it
and
it's
been
discussed
and
it's
been
white
boarded
and
we've
gone
and
around
it
a
little
bit
and
that's
why
I
kind
of
wanted
to
get
something
out
on
the
email
thread
about
it
beforehand,
but
apparently
you
and
steven
chad
about
it.
So
I'm
glad
they
are
both
on
the
call.
D
We
are
also
of
the
same
opinion
that
moving
it
outside
slash.
V2
is
going
to
create
a
bunch
of
challenges
for
operators
who
have
introduced
controllers
and
what
not,
so
that
all
seems
to
be
in
line
with
what
I
had
chatted
with
the
only
difference.
I
think
that,
from
the
last
part
of
the
proposal
was
that
of
explicitly
calling
out
the
path
right
you
want,
you
have
a
discovery.
D
Without
this
being
closed,
it's
going
to
be
hard
to
get
the
conversation
as
to
where
does
this
land
and
the
changes
would
all
be
kind
of
like
queued
up
as
to
the
url
path
for
where
we
can
hit
this
api?
The
other
thing
is:
this
is
mostly
additive.
It
doesn't
change
any
of
the
existing
apis,
but
there's
one
one
portion
of
the
artifact
spec
that
might
is
orthogonal
to
the
extension
specification
itself.
D
The
extension
is
just
about
discovery,
and
I
think,
as
long
as
we
have
a
way
in
which
clients
can
discover
the
location
of
the
api,
and
they
understand
that,
then
we
most
of
the
scenarios
are
unblocked
for
being
able
to
query
reference
artifacts.
Like
can
we
query
by
some
digest
all
those
scenarios
can
enable-
and
other
extensions
can
also
kind
of
like
come
along.
So
that's
the
motivation
of
this.
D
E
You
all
hear
me:
okay,
all
right,
great
yeah,
so
the
and
yes,
this
is
an
office
behind
me.
So
if
you
guys
it's,
it's
very
weird,
there's
nobody
else
here.
So
it's
very,
very
spooky
so,
but
that
spooky
is
for
october
right,
okay,
so
yeah!
So
there's
there's
two
things:
okay,
so
there's
two
things
I
wanted
from
the
extension
api.
E
One
of
them
was,
I
really
wanted
to
get
us
out
of
the
the
business
of
parsing
path
parameters
like
I
think
we
made
some
pretty
difficult
choices
in
the
in
the
original
kind
of
way.
We
index
names
and
that's
pretty
solid
now,
and
I
think
if
we
add
more
path
parameters
in
there,
it
can
make
it
difficult
to
parse
in
the
future.
E
The
other
piece
to
it
is
the
I
kind
of
wanted
to
like
I
kind
of
want
to
to
trampoline
off
of
the
catalog
api
design.
It's
not
the
best
in
the
world,
but
at
least
at
the
path
level.
It's
it's
fairly
safe
and
it's
pretty
straightforward.
What
we
didn't
do
with
the
catalog
api,
though,
was
hang
it
off
of
an
individual
repository.
E
So
I
think
for
extensions
to
be
useful.
We
need
to
have
two
kinds
of
extensions.
We
need
to
have
like
a
root
extension,
and
this
would
be
like
slash,
v2
underscore
and
then
whatever
the
extension
name
is,
and
then
we
need
extensions
that
can
hang
off
the
repository.
This
would
allow
you
to
go
off
of
any
name
and
and
and
root
from
there,
and
so
those
are
the.
Those
are
the
two
major
points
in
that
comment.
I'm
not
sure
if
I
missed
anything
does
everybody
is.
Is
anybody
like
like
wild?
F
I'll
go
in
the
category
a
while
they
agree
with
it.
I
think
it's
a
good
suggestion.
The
only
question
I
think
I
have
is,
I
think
we
said
that
we're
looking
for
to
see
this
fleshed
out
in
an
example
use
case
scenario
and
to
see
some
users
trying
it
out
first
before
we
sure
approve
it
within
oci,
and
so
that
might
inverse
what
I
think
sanjay
is
looking
for,
which
is
to
see
this
get
approved
and
then
use
it
with
the
reference
types.
A
A
So
I
think
I
think
it
makes
sense,
like
I
said,
get
making
thing.
Okay.
So
let
me
just
from
all
the
ways
that
this
conversation
has
gone
and
even
where,
where
you're
arriving
at
a
way
to
because,
like
again
nobody's
no
nobody's
stopping
anybody
from
adding
endpoints
to
a
registry
implementation,
many
people
already
do.
A
A
A
That's
that's
kind
of
like
the
discovery
piece
of
like
where
to
find
those
endpoints,
something
that
was
brought
up
in
the
oci
summit
last
week
was
like
that's
fine,
to
have
these
kind
of
extensions
as
long
as
effectively
they're,
optional
and
so
th.
This
is
where
we,
I
think,
classically,
can
kind
of
go
around
in
circles,
but
I
just
want
to
make
it
as
clear
as
possible
that
there
are
these
extensions
possible
people
are
already
doing
them
for
their
own
repos,
whether
it's
you
know
any
cloud
provider
otherwise
to
enhance.
A
The
there's
a
little
bit
of
trickiness
and
care
and
concern
in
this
to
to
deal
with
like
life
cycling,
those
endpoints
of
like
we
added
something.
You
know
the
the
references
version
one
and
then
we
found
we
did
it
wrong.
We
had
to
kind
of
like
make
a
v2
of
it.
How
do
you
say
that
this
is
new,
a
new
and
or
behaving
different
endpoint?
A
You
don't
have
to
use
it.
It's
optional
as
an
endpoint,
but
if
you
do
start
using
it,
then
there's
these
other
within
itself,
musts
or
shells
or
whatever,
and
that's
like,
where
you
kind
of
point
to
some
other
dock
of
like
here's,
how
this
endpoint
behaves,
it
might
have
its
own
musts
nested
inside
there,
but
use
of
that
endpoint
at
all
is
effectively
optional.
A
So
some
way
to
keep
that
documented
or
you
know,
behavior
is
discoverable
among
users
or
enough
information
that
a
client
could
point
back
information
and
say
you
know:
here's
a
registry
and
it's
a
provides
these
endpoints
here-
are
these
additional
extensions,
here's
the
docs
on
them.
You
know
giving
people
enough
information
to
bubble
it
up,
so
that's
kind
of
like
endpoint
discovery
is
one
concern
and
kind
of
life
cycle
and
then
from
the
comments
that
you're
just
saying,
and
even
from
the
last
couple
of
comments,
I
think
are
good
that
you
can
then
say
cool.
A
So
it
has.
This
extension
added
in
here
are
the
end
points
that
you
can
start
finding
it
at
and
they're
all
nested
past
v2,
slash
name
or
whatever.
It
is
something
that,
where
the
scope
and
acls
and
otherwise
are
already
effectively
determined
for
that
client's
session,
so
those
those
two
things
are
just
really
the
balancing
act
that
we
can
be
on
on
page
with,
and
I'm
fine
with
updating
this,
this
pr
and
even
like
hack.
You
know
we
could
start
hacking
on
it
straight
away.
A
I
don't
think
I
want
to
go
down
that
path
yet
so
either
calling
it
out
specifically
like
things
the
discovery
endpoint
you
know
should
be
should
be.
You
know
generic,
regardless
of
acls,
even
if
the
behavior
that
they
get
when
they
hit
those
endpoints
might
be.
You
know,
requiring
acls
or
something
like
that.
D
Right
because
none
of
the
distribution
spec
calls
out
the
actual
acl
scope
of
what
tags
or
what
repositories
need
to
be
returned
right.
So
I
think
we
can
keep
the
model
the
same
for
these.
If
folks
have
no
concerns
on
that,
but
it's
very
simple
from
a
discovery
standpoint.
I
think
that's
why
that
was
the
premise
of
this,
just
keeping
it
as
simple
as
possible
with
a
list
of
endpoints
that
the
client
can
use
and
it
can
be
under
this
path.
D
Otherwise,
my
concern
is
that
every
registry
operator,
like
harbor,
has
an
example
of
attached
attachments
or
that
they
have
a
concept
of
attaching
certain
things
to
images.
All
those
can
could
have
potentially
been
under
a
path
like
this
brandon's
question
about
whether
we
want
the
spec
approved
before
we
get
the
reference
implementation,
I'm
open
to
it
either
way.
D
But
as
long
as
we
can
see
that
there
is
forward
motion
on
both
sides,
then
making
the
pr
into
distribution
is
going
to
be
and
showing
a
reference.
Implementation
would
be
a
little
more
straightforward.
That's
that
was
the
motivation
for
the
discussion.
It's
it's
not
about
getting
the
pr
in
or
anything.
I
just
wanted
to
open
up
the
discussion,
whether
it's
something
that
folks
want
to
proceed
with
and
make
progress
on.
E
So,
okay,
so
so
first,
I
think,
based
on
what
vincent
said,
we
need
to
have
careful
ex
careful
specification
of
the
extensions
in
coin.
I
I
don't
know,
I'm
just
dropping
some
jason
in
here.
I
I
like
to
like
have
something
in
my
head,
and
this
is
what
I'm
oh.
This
is
terrible,
but
hopefully
this
like
we
can
get
something
like
this
in
the
spec,
where
you
can
hit
the
extensions
in
point.
The
response
type
is
clear:
we
haven't
done.
E
E
You
know,
we
have
a
list
of
things,
you
get
them
and
you
know
we
can.
We
can
add
fields
to
it
as
we
discover,
but
like
I'm
not
saying
we
do
this
exactly.
What
I'm
saying
is
just.
I
think
this
endpoint,
like
underscore
extensions,
would
be
a
preferable
path
for
it,
but
we
needed
to
find
that
one
carefully
yeah
and
then.
A
Is
something
like
that?
I
think
nesting
it
where
you
have
like
the
extension
or
the
text?
That's
the
part
where
it's,
like,
maybe
nesting,
that
somewhere
past
like
the
bracket
name
so
that
you
already
can
kind
of
see.
I
don't
know
what
like.
So.
You
see
we're
not
re
re,
creating
paths
but
that's
kind
of
again
in
the
details.
E
E
E
Yeah
yeah
right,
like
I
mean
I
can't
think
of
a
use
case
off
the
top
of
my
head
either,
but
like
just
the
relationship
between
things,
seems
reasonable.
So
so
I
guess,
if
we
can't
think
of
a
use
case,
we
should
have
a
way
to
refer
to
repository
level
like
extensions
that
they
would
have
different
return
values
per
repository
at
the
root
level
so
that
they
can
so
that
we
can
understand.
Okay,
I
have
a
root
level
extension
versus
a
versus
a
repository
level
extension
and
then
the.
G
C
E
F
C
F
B
I
think
an
illustrative
use
case
of
repo
level
extensions
in
general
is
rolling
out
this
feature
across
repos.
You
might
not
want
to
enable
it
for
all
repos
you
might
want
to
have
alpha.
You
know
alpha
experimental
repos
that
are
opted
into
my
extension
until
you
roll
it
out
to
everybody.
I
have
a
question
about
the
the
value
of
a
an
api
endpoint
that
returns
a
list
of
enabled
features.
B
Generally,
I
assume
people
are
going
to
use
that
like
get
the
list
of
all
extensions
and
then
see
if
the
extension
I
care
about
is
enabled
right.
Do
we
have
do
we
imagine
a
use
case
where
a
client
would
want
to
list
and
then
just
consume
that
list
or
or
I
think
most
cases
it
would
be.
Is
references
enabled
for
this
repository
this
specific
issue,
this
specific
extension,
and
in
that
case,
I
wonder
if
we
can
just
use
the
exist,
the
response
of
that
path?
B
If
I
do,
if
I
do
repo
slash,
underscore
x
references
and
it
returns
a
404,
that
means
this
repo
doesn't
support
references
or
if
it
does
respond
and
it
responds
with
the
you
know,
documentation,
stuff
or
icons
or
blah
blah
or
whatever.
Then
I
say:
oh,
this
repo
does
support
references,
and
now
I
can
use
that.
I
don't
know
what
the
value
is
basically
of
an
api.
E
B
F
B
Separately,
I'm
also
not
sure
what
the
value
is
of
having
registry
level
extensions
versus
repository
level.
Extensions
in
practicality,
people
are
only
going
to
deal
with
repositories
and
only
really
want
to
know
whether
it's
enabled
for
the
repository
they're
about
to
push
to
or
interact
with
or
whatever.
B
A
Well
and
that's
for
a
couple
of
these
things,
even
when,
like
john
and
I
were
playing
playing
out,
the
kind
of
like
referrers
or
references
so
say
you
attach
you
push
a
blob
that
you
know
might
be
a
signature
scan
result,
and
then
you
want
to
push
another
like
effectively.
Making
a
reference
between,
like
that
blob.
That
I
pushed
is
a
type
of
a
scan
result
that
references
this
other
blob
or
you
know
it
could,
which
could
be
a
manifest.
It
could
even
just
be.
A
And
some
of
those
kind
of
like
what
kind
of
endpoints
would
you
need
at
that
point?
Where
you're
saying
actually
show
me
all
types
of
scan,
you
know
all
scan
results
for
scan
result
types
for
this
particular
digest,
and
so
at
this
point
it's
kind
of
abstracted
away
from
even
names
names
of
images,
because
you
might
have
that
particular
tarball
show
up
in
other
images
which
some
of
those
things
are
like.
B
A
E
E
A
Something
in
place
basically
two
things:
we
haven't
made:
distribution,
spec,
1.0,
that's
a
conversation.
I
think
that
a
lot
of
us
have
effectively
left
on
the
table
is
reiterate
so
basically,
yes,
sure
why
not
it's
not
1.0,
yet,
secondarily,
we've
never
really
leaned
into
any
kind
of
like
alpha
beta,
stable
process,
but
that's
effectively
what
you're
asking
about
it
like
this.
This
particular
part
of
the
docs
is
to
be
considered
alpha.
F
G
A
F
E
E
G
B
D
I
think
we
have,
I
think
stephen,
can
comment
on
that,
but
my
hope
is
that,
even
if
there's
a
provision,
there
can
be
a
configuration
flag
on
distribution
that
enables
this
or
disables
this
accordingly
right.
So
if
you
were
to
make
a
pr
into
distribution,
then
we
can
point
to
this.
Is
the
alpha
part
of
the
spec
it's
disabled
by
by
default
and
people
who
want
to
enable
it
and
try
it
out
as
an
alpha?
D
E
G
A
A
Well,
I'm
just
saying
if
we,
if
we,
if
you
know
if,
if
we
did
just
arbitrarily
say
this,
is
alpha
and
subject
to
change
or
whatever,
even
if
it
gets
tagged
in
a
v101
defining
what
that
even
means,
I
feel
like
there
needs
to
be
like
a
small
blurb.
Even
if
it's
you
know,
read
me
or
something
I
was
like.
A
C
A
D
C
F
F
There
say
it's
a
multi-platform
image,
so
you've
got
the
x86
and
the
arm
image
and
it's
got
the
config
and
the
layers
under
it
with
all
the
blobs
and
the
index
that
points
to
both
of
those
or
you
know
in
the
docker
world.
The
manifest
list,
and
so
we're
trying
to
add,
is
the
signature
and
the
s
bomb.
On
top
of
that,
and
so
we've
potentially
got
something
there.
F
We
just
need
to
find
a
way
that
we
can
add
this
to
this
object,
and
so
one
thing
that
was
going
around
the
conversations
last
week,
I
think,
was
if
we
allow
reference
types.
That
means
that
someone
could
potentially
just
update
the
index
after
the
fact
if
they
had
right
access
to
the
repo,
and
they
had
a
concern
about
that,
because
they
really
rely
on
the
digest,
and
so
you
could
potentially
just
update
this
index
just
have
more
entries
in
the
index.
F
When
you
do
that,
though,
the
digest
is
going
to
change,
and
so
that's
good
and
bad
depends
on
your
use
case
for
a
lot
of
people.
That
use
case
might
be
that
hey
changing
this
digest,
not
so
good
because
they
rely
on
that
staying
the
same
with
all
their
workflows,
but
other
people
may
want
to
say
hey.
I
want
to
know
when
I
pull
that
digest.
I
get
all
the
objects
associated
with
it
and
nothing
else,
nothing.
F
Someone
pushed
after
the
fact,
and
so
it
gives
them
that
control
they're,
looking
for
so
depending
on
the
use
case.
Maybe
that
makes
sense,
but
the
other
way
was
you
could
kind
of
do
some
theoretical,
reverse
pointer.
Where
you
said
you
know,
signatures
got
some
kind
of
way
to
say
that
it's
got
a
manifest,
so
that
might
need
to
be
a
different
object,
or
maybe
you
put
an
index
in
front
of
it.
F
However,
that
works
out
that
it
has
the
digest
pointing
up
to
the
index
and
when
you
do
that,
you've
got
the
signature
point
down
to
it's
blobs,
but
it
also
points
up
there,
and
so
that
kind
of
gives
you
an
association,
but
I
don't
really
see
a
good
way.
You
could
use
this
to
query
yeah.
There
are
a
whole
bunch
of
problems
with
it
and
the
the
least
of
which
was
when
you
do
a
garbage
collection.
F
F
This
stuff
is
just
hanging
out
there,
there's
nothing
pointing
to
it
and
so
yeah
we
get
cleaned
up
at
that
point,
so
the
cosine
model
went
a
little
different
direction
where
they
said
just
give
everything
a
tag,
and
so
we've
got
the
digest
here:
a1
b2
c3
for
this
index,
so
they
tag
their
image
with
a1
v2
c3,
whatever
the
same
as
the
sha,
the
same
as
that
digest
dot
sig
dot
s
bomb.
To
give
you
the
different
types,
so
there's
some
logic
there.
F
The
pro
is
that
each
one
of
these
things
stands
independently,
and
so
you
can
delete
the
image
and
the
stuff
still
stands
around.
That's
good
and
bad
depends
on
your
use.
Case
depends
on
what
you
want.
The
one
challenge
that
I
don't
like
about
this.
That
doesn't
work
so
nicely
when
you
start
adding
multiple
signatures.
F
So
if
you
try
to
push
a
second
signature,
you're
going
to
overwrite
the
last
signature,
do
you
have
to
have
an
extra
layer
on
top
of
this
with
some
kind
of
index
that
has
all
the
signatures
in
it
or
maybe
modify
the
signature
to
have
multiple
blobs
in
there
of
all?
The
different
sensors
that
were
attached
to
it
not
sure
how
that
works
out,
but
there
potentially
get
race
conditions
you
have
to
work
out.
F
There
are
references
all
over
the
place
you
potentially
add.
So
if
we
were
to
put
it
right
here
in
the
signature,
it
effectively
creates
a
reverse
pointer.
What
you're
saying
is
hey
I've
got
this
reference
here
from
index
pointing
down,
and
so
I've
got
all
those
blobs,
and
so
it
gives
us
a
way
we
can
add
signatures.
So
if
we
want
to
later
on
add
more,
we
can
keep
adding
more
signatures
on
this
stuff
and
they're.
F
Just
additional
things
to
come
back
does
mean
that
we're
gonna
have
to
have
some
kind
of
new
api
to
query
all
these
to
look
them
up,
but
it
had
some
nice
features
in
there,
not
the
least,
which
was
garbage
collection.
You
go
out
there
and
say,
delete
all
the
1.5
tag.
It
deletes
this
whole
image,
but
it
also
says:
hey
all
these
things
were
hanging
out
by
themselves
with
nothing
that
they
were
referring
to
anymore.
F
I
think
this
was
something
that
jason
cormack
was
mentioning
with
his
universal
proposal
and
I'm
not
sure
that
got
enough
attention
from
some
of
the
other
proposals
we've
been
looking
at,
which
is,
if
you
allow
anything
to
have
a
reference
to
it.
You
can
potentially
push
an
index
and,
since
the
child
of
an
index
can
potentially
be
another
manifest,
you
could
also
say
your
reference
to
be
one
of
your
children
and
that
creates
a
loop
and
so
that
the
solution
here
when.
F
So,
no
you,
I
don't
think
you
do,
because
this
is
creating
a
reverse
pointer,
the
hash.
I
know
when
I
create
this
bad
index.
My
child
here
is
a1
b2
c3,
it's
the
index
right
here
and
then
I
create
a
reference
of
something
that
it
had
or
it
could
even
be
the
same
index.
I
could
say
the
reference
is
the
same
thing
and
you
just
kind
of
create
a
two
two
pointer
loop
there,
but
I
made
one
extra
layer
removed
where
I
said.
Okay,
the
digest
this
thing
was
bbb222.
F
Since
I
know
something
about
my
child
within
this
branch,
I
can
create
my
child
pointer
and
a
reverse
pointer
here
with
the
reference
both
in
the
same
index,
and
so
I
think
you
can
create
this,
create
a
loop
intentionally
that
would
break
things,
but
the
the
way
you
can
do.
That
is
only
if
the
object
you're
creating
can
itself
have
manifest
as
a
children
and
the
references
point
to
manifest.
F
If
we
did
blobs.
That
would
be
a
whole
different
thing.
But
if
we
limit
our
reference
and
say
the
reference
can
only
be
to
a
manifest,
then
the
question
is:
if
your
child
object
can
include
a
manifest,
so
an
index
can
have
manifest
within
an
index.
That's
where
the
problem
came
in
that
I
was
looking
at.
C
F
And
also
especially
for
vincent
because
you're
you're
pointing
that
out-
and
I
know
that's
been
like
par
logic
there
and
that's
been
some
of
the
stuff
I've
been
thinking
about.
When
I
look
at
niches
where,
depending
on
the
objects
you
create,
you
can't
make
like
a
pointer
back
to
yourself,
because
you
would
have
to
know
the
digestive
yourself.
It
would
be.
You
know,
creating
a
creating
a
hash
collision
there.
That
would
be
very
difficult
to
create.
C
C
A
I
think
all
those
all
those
kind
of
things,
even
if
we,
even
if
you're
semantically
calling
them
a
pending,
are
truly
just
that
they're
they're
they're,
not
in
the
critical
path
of
like
a
manifest
they're,
not
they're,
they're
they're
available
through
some
like
side.
Query
that,
like
show
me
all
the
things
that
reference
this
manifest.
It's
not
like,
they're,
actually
appending
to
the
manifest,
and
if
you
want
to
make
a
union
view
at
the
end
of
like
like
for
a
data
reason
like
here's,
this
manifest
and
here's
all
these
other
references
related
to
that
manifest.
A
D
A
E
The
the
first
difficulty
was
that
each
time
you
signed
it,
you
would
change
the
thing
you're
signing
right
and
I
can
kind
of
see
that
in
the
diagrams,
I'm
not
claiming
to
understand
all
the
details
here
but
and
I'd
have
to
like
look
at
it
more
closely
to
better
understand
that.
But
once
you
change
the
thing
that
you're
signing
now
you
take
the
ability
away
you
now
you
require
coordination
externally
to
actually
build
that
thing
right.
E
So
let's
say
you
have
your
your
image,
build
your
signal
so
well,
you
have
to
you,
have
to
build
the
image
before
everything
right.
That's
one
coordination
problem,
but
that's
that's,
usually
pretty
straightforward.
Now
you
have
to
have
a
signing
and
an
s-bomb
and
a
vulnerability
scan
all
coordinated.
E
E
The
same
thing
at
the
same
time,
there's
a
lot
of
difficulties
there
so
like
the
having
a
signature
reference
from
the
manifest
and
actually
changing
that
the
hash
of
the
thing
that
you're
you're
trying
to
annotate,
I
I
think
is
just
I
think
it
is
difficult,
I'm
not
sure
which
project
it
was,
but
they
used
like
specially
named
tags
to
reference.
The
signature.
E
Is
that
cosine?
I
I
thought
that
I
thought
like
that.
Has
some
discoverability
problems,
yes,
but
at
the
same
time
it
like
it
kept
the
integrity
of
the
image
at
the
the
top
level
consistent
through
the
process
of
actually
signing
it
and
then
also
is
compatible
with
systems
that
don't
know
about
the
signature
scheme
and
stuff
like
that.
So
yeah,
but
that's
that's
just
my
two
cents,
but
I
like
like
go
back
and
look
at
like
schema.
E
Let's
see,
did
we
embed,
I
think
we
embedded
the
the
layers
in
there
and
then
the
config
was
embedded
and
when
and
then
it
used
pretty
json
web
signatures.
I
think
we
called
it,
which
was
a
from
a
blog
by
I
think,
brad
fitzpatrick.
Maybe,
and
the
issue
was
that,
like
each
time
you
signed
it,
it
would
add
a
new
signature
to
this
whole
blob,
thus
changing
the
digest.
E
F
Yeah,
I
think
the
v1
is
probably
the
most
similar
to
this,
where
you're
modifying
that
index.
Every
time
you
add
a
signature
into
this
stuff,
and
so
it's
not
just
tightly
into
the
image,
but
it's
still
you're
modifying
something
to
do
that,
and
so
cosine
definitely
went
this
direction
where
they
said.
Let's
make
a
separate
tag.
This
can
be
a
whole
isolated
thing
with
its
own
tag,
and
the
name
just
happens
to
be
the
digest
of
this
thing.
We're
talking
to
or
referring
to
so
that
is
an
approach.
F
The
reference
type
itself
is
just
saying:
instead
of
making
a
tag,
make
it
a
field
inside,
and
so
when
you
look
at
the
actual
json
what
it
ends
up.
Looking
like
because
you're
just
gonna
have
a
field
in
there,
it
says
my
reference
is,
and
then
the
descriptor
I'm
pointing
to-
and
so
it's
part
of
your
object,
you're
creating
is
just
to
have
these
references
in
there
where
it
creates
this
back
pointer
at
that
point,
and
so
that
I
know
the
comment
in
there
was.
You
know
we
still
haven't
modified
this.
F
We
haven't
changed
at
all
this
index,
the
image
anything
in
there
that
digests
maintained
exactly
the
same,
so
we
didn't
change
the
dag,
but
I
think
the
question
becomes
what
is
a
tag,
because
it
is
we're
making
a
graph,
and
we
make
this
reverse
point.
We
are
adding
something
to
the
graph,
even
though
we
have
to
modify
this
object
directly.
We
modified
externally.
C
If,
if
you
are
in
a
development
workflow
where
you
are
adding
s-bombs,
as
you
are
developing
on
top
of
the
images
it
becomes
more
and
more
difficult
to
or
organize
all
of
the
artifacts
so
for,
at
least
from
my
perspective,
I
see
the
benefit
of
keeping
both.
That
dag
thing
to
you
know
strongly
connect
all
of
those
artifacts,
but
also
like
the
flexible,
I'm
gonna
call.
I
don't
know
what
to
call
it
flexible,
appending
or
flexible
attaching
during
a
development
workflow.
C
F
F
Like
I
want
to
first
real
quick,
we've
got
a
couple
proposals
out
there,
and
one
of
them
was
the
artifact
spec,
which
created
a
new
object
here
that
wasn't
necessarily
an
image
but
created
a
new
thing
for
the
artifacts
that
had
a
nice
property,
where
the
references
were
only
on
something
that
had
blobs.
And
so
you
didn't
get
into
this
looping
scenario,
because
the
thing
you're
adding
could
only
ever
point
to
a
blob.
F
And
so
I
think
those
are
kind
of
the
two
big
cases
and
no
matter
what
we
do
with
this
there's
going
to
need
to
be
a
new
api
call
and
so
all
the
stuff
we
were
talking
about
with
adding
that
new
extension.
That's
going
to
be
part
of
the
challenges,
that's
going
to
have
to
be
implemented
at
the
registry
level
to
support
this,
because
you
need
a
way.
C
A
C
C
F
So
a
bunch
of
these
at
I
was
looking
through
a
bunch
of
samples.
I
don't
think
you
can
create
circular
reference.
I
don't
think
you
were
creating
circular
references
with
what
you're
doing
until
you
say.
There's
it's
got
to
be
an
object
that
can
link
to
other
manifest
is,
is
the
requirement
and
so
you're
creating
a
link
from
an
object
that
can
link
to
other
manifest
and
to
another
manifest.
F
C
F
A
C
So
I
shared
this
with
the
group.
If
y'all
have
questions
about
it,
then
I
I
have
a
list
over
here
about
open
questions
that
I'm
trying
to
answer
now.
I'm
not
saying
to
get
I'm
not
saying
get
rid
of
image
index
and
start
a
new.
I'm
saying,
modify
the
image
index
such
that
you
add
a
type
called
reference
that
has
these
restrictions
and
it
looks
to
me
at
least
after
going
through
all
of
these
scenarios,
that
this
will
work
and
it
doesn't
require
much.