►
From YouTube: OCI Weekly Discussion - 2023-05-25
A
Yes,
I'll
throw
mine
in
there
first
and
then
because
it's
just
a
quick
little
actionable
item
there
and
then
I'll.
Let
others
take
her
with
theirs.
A
A
plus
Dev
syntax,
we've
already
approved
it
in
runtime
and
image
spec,
so
just
need
one
more
approval
over
here
for
doing
it
over
and
distribution
spec,
and
that
is
all
I
had
to
add
before
immersed
in
the
other
two.
So
if
you're,
just
getting
another
distribution,
spec
person
over
here
to
hit,
approve
and
we'll
get
that
knocked
out.
A
That's
pretty
much
it
for
me
today,
Aaron
I,
guess
you
had
the
quick
actionable
item
there.
1066
you
want
to
take
it.
C
Yeah,
this
is
a
pretty
small
one.
This
adds
the
artifact
type
field
to
image
index
so
that,
if
Set
a
yeah,
if
you
have
an
index
that
references,
multiple
NFS
and
you
want
that
to
be
sort
of
like
an
artifact,
not
reference,
not
necessarily
a
reflection
of
index,
a
rather
reflection
of
images,
but
a
collection
of
artifacts
you'd
have
some
sort
of
descriptive
for
that
and
have
it
associated
with
a.
A
D
C
A
C
We
have
plugins
that
are
published
for
a
variety
of
platforms
and
it
makes
sense
to
use
image
index
as
opposed
to
an
image
with
the
number
of
layers
for
each
of
those
plugins,
because
image
index
gives
us
the
ability
to
associate
each
manifest
with
a
platform
and
then
each
manifest
can
be
who
actually
needs
to
be
signed
as
independently
right
so
we'll
have
to
have
six
door
or
notary
certificates
for
the
Mac
OS
AMD,
64,
Mac,
OS
and
we'll
silicon.
You
know
so
on.
C
Each
one
of
those
is
going
to
be
its
own
artifacts
and
then
the
image
index
is
going
to
be
the
top
level
item.
A
C
Yeah,
this
is
just
picking
up
the
conversation
last
week,
I
think
there
was
discussion
about
moving
this,
this
language
to
the
distribution
spec,
but
there's
still
I
think
your.
C
Your
comment
regarding
our
registry
operator
is
going
to
be
supportive
of
a
standard
that
says
that
you
should
use
denyless
and
not
allow
us
so
that
you
know
things
like
Community
artifacts,
like
wasm
or
again,
going
back
to
like
s-bombs,
and
things
like
that
that
those
tools
can
sort
of
be
confident
that
they
can
use
oci
1.1
as
as
a
spectacular
plot,
but
I
I
think
before
I
make
a
PR
to
distribution
stock.
C
I
think
we
need
to
unblock
this
comment
from
you,
because
the
comments
can
apply,
regardless
of
which
repository
the
pr
is
open.
Again.
A
Yeah
just
know:
we've
made
changes
before
to
push
in
certain
directions
and
didn't
have
feedback
until
the
last
minute,
and
they
said.
Oh
no,
you
got
an
RC,
and
now
we
don't
like
what
you
had
in
the
RC.
This
one
I
feel
like
it's
going
to
go
even
farther
than
that
I.
Don't
think
we'll
hear
a
complaint
until
a
while
later
and
registry
say
we
just
don't
support
oci
at
that
point.
A
C
Right,
I
guess
the
I
think
the
analogy
I
think
of
here
is
if
oci
1.0
or
even
like,
going
back
to
the
the
docker
Manifest
this
patient.
It
had
a
field
like
what
the
base
image
is
and
that
base
image
by
default.
The
specs
that
you
have
support,
say:
slackware
I'll
use
a
an
older
distribution
as
the
reference.
C
C
If
oci
is
going
to
support
artifacts
the
specification
as
it's
written
doesn't
actually
require
that
artificiency
supported,
which
I
think
is
kind
of
the
fundamental
obstacle
and
I've
raised
it.
Numerous.
C
Except
say
that
there
is
a
ecosystem
that
wants
to
use
oci
as
a
means
of
Distributing,
artifacts
or
supply
chain,
security
for
package
managers
or
other
uses,
but
there's
not
a
standard
that
actually
says
that
they
have
something
they
can
use
right.
Knowing
that
a
registry
is
oci,
1.1
compliant
doesn't
actually
mean
anything
to
me
as
a
consumer
or
user
of
the
specification.
C
Isn't
that
the
purpose
of
specification.
C
I,
I
suppose
the
question
then
is:
do
we
have
a
strong
belief
that
there
are
Registries
that
are
so
firmly
opposed
to
this?
That
this
is
a
an
actionable
item?
I
I,
don't
get
the
impression.
That's
actually
the
case
and
my
understanding
is:
we've
got
maybe
some
older
notes
from
one
registry
that
indicates
that
they
are
not
interested
in
supporting
artifacts,
in
which
case
they
might
not
be.
They
might
not
be
interested
in
oci
1.1
at
all,
so
to
me,
I
think
as
a
specification.
C
A
So
I
would
say
that
today,
if
you
were
to
push
to
an
oci
1.1
registry
and
you're,
going
trucks,
I
hate
to
use
their
example,
because
they're
not
here
but
I,
can't
even
push
a
Docker
image
to
the
zot
registry.
They
don't
support
the
docker
media
types.
It's
not
in
our
spec.
We
don't
say
they
have
to.
A
F
I'm,
looking
at
10,
30
and
I,
don't
see
a
huge
problem
with
it.
I
have
a
question
about
the
image
index
media
type
diff.
So.
F
Yeah
this
one
I
have
personal
opinions
about
this,
but
other
people
have
counter
opinions
about
this.
F
The
Manifest
document,
the
image
index
document,
has
a
list
of
manifests
descriptors
and
you
would
sure
think
that
only
manifests
would
go
in
there
right,
but
other
clients
have
pushed
non-manifest
things
and,
as
written
the
current
specification
more
or
less
everyone
has
hard-coded
a
set
of
manifests,
but
they
know
how
to
parse
and
do
stuff
with
this
line.
F
I
think
is
the
only
place
where
you
might
annoy
or
break
things
where
registry
operators
assume
that
things
in
this
manifests
array
points
to
manifests
that
they
know
about
and
have
parsed
and
are
able
to
interpret
I.
Don't
really
have
strong
opinions
about
it.
I
think
it's
fine,
like
I
would
just
ignore
it,
as
as
the
specification
already
says,
but
you
might
encounter
other
registry
or
client
implementations
who
would
fall
over
if
you
started
pushing
an
image
index.
That
pointed
to
like
an
arbitrary
thing,
that's
my
only
comment.
C
Yeah,
that's
actually
in
this
the
line
question
the
mediatek
field
here
is
the
not
the
Manifest
media
type
right.
It's
the
right,
yeah.
F
Into
the
the
children
right,
yeah,
yeah
I
would
not
be
surprised
if
that
would
frustrate.
Some
implementations
to
have
like
non-expected
manifests.
C
This
is
actually
referring
to
manifest
media
types
as
opposed
to
content,
media
types
and
the
the
change
here
on
145
was
just
mechanical.
Finding
places
where
ignored
was
not
with
ambiguous
but
actually.
F
Caching
was
using
an
image
manifest
or
an
image
index
and
like
pointing
to
blobs
from
within
this
list
of
manifests
and
that
Brooks
and
stuff,
but
like
a
lot
of
Registries,
did
support
it
and
we're
just
ignoring
it,
but
in
like
obviously
like
clients
would
be
confused
when,
if
you
tried
to
actually
pull
this
thing
and
I
think
for
a
lot
of
reasons,
they
stopped
using
the
image
index
and
then
moved
to
an
image
manifest
I'd,
yeah
I,
don't
know
I,
don't
have
a
strong
opinion
here,
I
just
that
one
requires
some
thinking
on
my
behalf,
and-
and
maybe
someone
has
a
better
idea
for,
like
you
know,
manifests-
are
more
strongly
typed
than
blobs,
because
we
have
to
parse
them
a
lot,
because
the
manifests
field
has
the
word
manifest
in
it.
F
Is
it
a
hard
requirement
that
these
only
push
to
like
these
only
point
to
manifest
and
also
is
it
a
hard
requirement
that
those
manifests
are
things
that
we
specify
or
like?
Should
we
leave
this
open-ended
so
that
we
can
evolve
the
spec
to
have
like
a
new
type
of
manifest
and
some
implementation
reading?
This
would
just
ignore
it
or
not
generate
an
error
when
encountering,
you
know,
manifests
to
Todd
V2
or
whatever
and
again
I.
Don't
have
answers
I'm,
just
pointing
this
out
for
discussions.
A
I
know
when
we
looked
at
it
before
the
line.
27
was
saying
hey.
This
is
a
list
of
manifest,
not
blobs.
That
was
kind
of
one
of
the
things
we
hinged
on.
It
also
makes
me
wonder
if
this
is
another
one
of
those
cases
where
this
phrasing,
not
generating
error,
might
be
different
for
clients.
Reading
it
versus
registry
servers,
validating.
F
F
The
fact
that
we
link
to
manifest.md
from
this
description
of
the
manifests
field
isn't
like
normative
right,
like
it
doesn't
have
to
link
to
this
thing
and
also,
if
you
look
at
the
image,
layout.md
file
and
scroll
all
the
way
down
to
the
index
example
at
the
very
bottom.
This
is
an
example
of
an
image
index
and
one
of
the
things
it
points
to
is
application
XML,
which
is
not
one
of
the
two
defined
manifest
types
in
image
spec.
So
by
my
reading.
F
You
know
this
proves
that
the
the
the
language
and
under
the
Manifest
field
is
non-normative
around
like
what
what
can
be
in
this
list.
It
doesn't
have
to
be
just
image
index
or
image
manifest,
but.
F
No
I
don't
know
how
we
want
to
solve
that
discrepancy.
E
A
A
You
know
they
can't
generate
an
error
if
artifact
type
is
unknown
and
the
concern
I
have
on
that.
One
is
just
knowing
that
some
Registries
won't
typically
like
to
implement
a
loud
list
rather
than
deny
list
so
once
you
say,
you're
not
allowed
to
implement
a
allow
list
that
could
make
a
registry
uncomfortable
that
that
could
result
in
them
saying
they
don't
support
this.
F
The
the
actual
code
that
handles
all
of
this
stuff
doesn't
have
to
behave
any
differently
right,
so
there's
no
real
burden
on
a
registry
to
just
not
reject
certain
strained
values,
because
the
string
value
doesn't
actually
influence
what
a
registry's
obligations
are
to
the
specification
or
its
clients,
and
so
I
I
would
just
be
really
surprised
if
someone
actually
pushed
back
on
that.
F
Well,
I
mean
I
mean
that's
a
terrible
argument,
not
from
you.
You
know
that
it's
a
it's
a
silly
line
of
thought,
because
I
can
change
that
string
to
be
something
you
do
except
yeah
and
it
doesn't
change
anything
from
your
perspective
and
it's
maybe
worse
from
a
security
perspective
to
masquerade
as
some
other
thing
right.
So
yeah
I
would
push
back
on
that.
If
someone
complains
that.
G
C
I
think
that's
largely
what
we've
agreed
upon
with
artifacts
anyhow,
so
trust
me,
it's
an
image
is,
is
now
the
the
norm.
A
I
would
push
back
a
little
bit
on
people
saying
this:
does
this
needs
to
go
in
distribution,
spec,
I,
don't
know
how
to
cleanly
put
this
over
in
distributions
back
I
feel,
like
all
the
wording,
all
the
fields
were
setting
us
on
are
already
over
and
image
specs.
So
for
those
saying
that
it
needs
to
get
moved
over,
how
would
we
move
it
over.
C
Okay
Fonda:
do
you
feel
pretty
strongly
about
me
changing
that
line
in
the
image
index
Market
file,
or
should.
F
I
guess
I,
don't
personally
care
care
is
probably
not
the
wrong
word.
I,
don't
have
the
opinion
personally
I,
just
imagine
it
being
problematic,
Maybe
down
the
road
and
if,
if
it
is
at
all
possible
that
this
is
less
contentious
to
revert
that
one
line,
then
I
might
do
that,
but
also
like
they're
functionally
equivalent,
like
you
know,
be
ignored
and
not
generate
an
error.
So
I'm
fine
with
the
diff
I,
just
I
wanted
awareness
around
this
potential
stumbling
block
down
the
railing.
A
Yeah,
if
you
want
to
have
another,
take
on
that,
which
is
how
we
do
have
a
digest
near
right,
that
it's
a
whole
descriptor,
there's
a
digital
skill
in
here
somewhere
or
there
should
be
we're
going
to
have
a
manifest.
It's
going
to
be
in
a
list
here,
we've
got
the
Digest.
F
Yeah
I
could
see
that
being
a
problem,
because
a
lot
of
Registries
store
manifests
and
blobs
and
separate
like
digest
namespaces,
and
so,
if
they're
just
checking
like
does
this
digest
exist
in
my
manifest
store
and
it
doesn't,
then
they
would
fail
so
like.
If
we
want
that
not
to
happen,
then
we
maybe
need
more
even
more
language
or
slightly
different
language
around
like
oh,
you
know
this
isn't
stored
as
a
manifest
in
the
back
end.
We
need
to
skip
it
or
not
generate
an
error
or
whatever.
A
Oh
I
always
go
in
the
other
direction.
I
was
going
with
allowing
Registries
to
reject
this
if
they're
doing
validation
on
their
side-
and
the
thing
you
refer
to
is
not
a
manifest.
A
F
Yeah,
that's
what
I'm
saying
I
think
that's
bad
in
terms
of
flexibility
of
like
using
this
specification.
It's
it's
unfortunate
if
the
registry
would
reject
it,
just
because
of
like
assumptions
around
how
the
subject
of
this
descriptor
was
uploaded,
but
also
like.
Maybe
we
want
to
make
it
very
explicit
that
manifests
can
only
point
to
things
that
were
uploaded
as
a
manifest
to
the
registry
in
the
context
of
a
registry.
I,
don't
know
that
that's
the
case,
but
a
lot
of
people
have
assumptions
around
that
for.
A
A
Thanks
and
John's
got
a
step
away
for
a
second
there
Aaron
that
might
be
the
Outburst
of
us,
we're
looking
for
which,
if
I'm
thinking
about
the
same
way,
allows
us
to
say,
hey
we're
not
going
to
generate
an
error
because
of
this.
So
we
can
leave
this
line
as
is,
and
Registries
are
doing
something
funny
or
doing
something
sensible
can
do
it
for
different
reasons.
A
So
you
would
think
so
and
Kinda
Yeah
sorta,
but
people
have
debated
this
for
a
long
while
yeah
and
that
would
probably
be
on
your
side
on
this
one.
A
All
right,
John,
maybe
convincing
me
and
not
be
sure,
picking
on
line
34.
A
So
my
objection
there
might
be
slightly
going
away.
I
still
think
it
would
be
good
to
get
someone
from
a
registry
to
travel
on
this
one,
someone
from
a
major
registry,
so
ECR,
ACR,
GCR
or
gar,
now
whoever's
taking
over
that
one
someone
over
there
just
to
look
this
over
and
say
yeah
from
the
registry
operator
side
or
Docker
Hub
as
well
from
the
registry
operator
side.
No,
this
raises
any
red
flags
for
us
that
we've
seen
out
there.
A
F
I,
don't
think
pointing
to
blobs
from
an
image
index
is
out
of
spec
foreign
I.
Don't
think
I
don't
know,
I
don't
have
opinions
about
that.
But
in
terms
of
like
a
straight
reading
of
the
specification,
I,
don't
think
it's
forbidden
so
like
do
we
do
we
care
about
that?
Should
we
forbid
it
or
is
it
fine
I,
don't
know
no
I
think
it's
neat
for.
E
F
Well,
the
thing
about
image
spec
is
that
it
doesn't
know
anything
about
any
kind
of
API
right,
the
only
so
the
only
reason
it's
a
problem
is
that
the
registry
API
was
kind
of
a
mistake
in
that
it
it
separated,
manifests
and
blobs
into
two
separate
name
spaces,
and
if
that
weren't
the
case,
then
like
everything,
could
be
a
blob
and
you
wouldn't.
This
wouldn't
be
a
problem,
but
but.
F
Like
as
a
client,
you
need
to
know
which
one
and
like
falling
back
is
silly
and
also
you
can
I
mean
some
Registries.
If
you
ask
to
pull
a
manifest
by
digest
that
and
you
change
the
digest
to
a
very
large
blob,
they
will
crash
right
because
they
don't
separate
their
blobs
and
manifest
in
the
separate
name
spaces,
and
so
you
can
fetch
and
manifest
or
a
blob
through
the
manifests
or
blobs
handlers.
F
Is
that
good
I
don't
know?
Who
knows
we
don't
really
make
it
explicit,
whether
that's,
okay
or
not,
and
a
lot
of
registries
don't
care
if
you
reference
like
blobs
from
a
manifest
or
like
you
could
even
key
off
of
the
media
type
to
know
like?
Oh,
this
must
not
refer
to
a
manifest,
because
if
it
had
this
media
type
I
would
have
rejected
it.
You
know
so
Registries
could
know
which
Handler
it
was
uploaded
through,
but
not
clients
and
I.
Don't.
A
F
Where
I'm
going
with
this,
but
it
is
ambiguous
and
if
someone
has
a
strong
opinion
either
way,
we
should
change
the
specification.
But,
as
is
it's
not
forbidden
and
per
one
of
our
examples
in
the
specification
it
seems
like
it
should
be
allowed.
Not
Capital
should
just
solarcation.
C
I
will
say:
I
just
did
a
control
F
for
blob
and
found
that
online
the
line
number
might
actually
be
just
off
because
I'm
looking
at
my
other
PR,
but
around
line
70.
on
OS
dot
version.
A
A
C
G
F
Yeah
and
and
the
spec
doesn't
say
this
required
property.
It
contains
a
list
of
manifests
which
must
be
like
manifests.
It
just
says
it
does
contain
that
property
and
they
are
this,
but
but
there's
no
normative
language
they're,
like
does
legal
jargon
around
like
this
is
allowed
or
not
allowed
so
yeah
linking
to
a
markdown
file
does
not
convey
a
requirement
in
the
specification.
F
F
And
manifests
aren't
an
abstraction
in
the
image
spec.
Really
we
don't
have
a
notion
of
something
that
is
either
an
image
index
or
an
image
manifest,
and
so,
but
if
we
did
it'd
be
easier
to
expect
this,
but,
as
is
it
is
just
like.
Oh,
that
string
is
the
same
string
as
the
string
in
distribution.
Spec.
Therefore
I'm
going
to
make
this
wild
jump,
that
those
are
the
same
and.
G
And
let's,
let's
be
specific,
it
says,
manifests
in
this
case
are
an
array
of
objects
which
was
the
base
like
not
not.
You
know,
specific
image
indexes
no
Matt,
sorry
manifest.
C
I
may,
while
as
an
implementer,
it
expects
me
that
I
might
be
able
to
put
blobs
in
an
image
index.
That
is.
C
This
is
not
the
the
purpose
of
this
pmware,
and
so
I
would
I
would
ask
that
if
we're
gonna
have
because
in
this
case
the
purpose
of
this
PR
is
artifacts
and
image
manifest,
not
not
anything
to
do
with
this
manifest
field
on
image
index.
So
this
is
just
a
sort
of
cleanup
of
the
ignore
line
that
we're
looking
at.
So
maybe
we
could
have
a
separate
discussion
for
the
pr
and
for
the
the
metaphysics
of
manifests
and
blobs.
C
G
Yeah,
the
other
question,
as
you
said,
is
on
the
distribution
API,
the
expectation,
of
course,
being
that
if
I
were,
if
I
request,
the
Manifest
listed
or
the
object,
I'll
be
able
to
pull
it
and
if
you
say,
must
not
generate
an
error.
What
does
that
really
I?
Don't
I'm
not
seeing
it
ignored
me
in
store
at
least
right,
or
at
least
that's
this
context
of
ignored
before
in
other
in
other
similar
contexts.
G
A
A
Okay,
after
10
30.
B
Oh
thanks,
I,
just
kind
of
was
looking
for
qualification,
a
couple
of
things
that
we
discovered
first
I'm
I'm,
not
sure
how
much
we
covered
in
the
distribution
spec
for
garbage
collection,
and
some
of
my
colleagues
mentioned
that
there
is
not
a
lot.
But
the
scenario
specifically
right
now
is
coming
back
to
the
index,
manifest
right
or
manifest
index
when
we
do
referrals
and
we
use
the
Manifest
Index
right
every
time,
when
you
add
a
new
reporter,
the
Manifest
index
gets
updated
and
a
lot
of
registry.
They
don't
delete
the
old
one.
B
Now
you
have
multiple
manifest
index
that
may
be
staying
there
and
what
is
kind
of
the
guidance
for
cleaning
those
ones.
The
other
thing
that
we
were
looking
at
is
when
you
delete,
let's
say
something
from
the
registry
I'm
trying
to
remember
what
was
the
scenario
because
it
was
too
two
weeks
ago.
But
when
you
delete
most
of
the
clients,
they
just
delete
the
the
the
Manifest
and
they
leave
the
blobs
hanging
around
right,
and
the
expectation
is
that
the
blobs
will
be
cleaned
up
by
the
registry.
G
B
Yeah
now
we
come
to
customers,
especially
in
our
space,
where
they
say
wow
you're
charging
me
for
much
more
than
I
expect
you
to
charge
me.
So
those
are
kind
of
the
two
scenarios
that
I
think
we
discovered
and
there
was
no
Clarity
how
to
handle
it,
because
we
were
discussing
whether
we
should
add
into
auras,
like
gold,
Elite,
also
the
garbage
in
the
client,
or
should
we
have
something
in
the
specification
to
say,
clients
are
not
responsible
for
that.
B
A
So,
as
another
client
writer
my
take
on
this,
one
is
I:
don't
really
book
The
blobs,
because
I
don't
know
where
else
the
blobs
may
be
used,
and
so
someone
could
upload
some
content
say
it
references
this
image
that
same
content
could
reference
another
image.
If
you
upload
in
a
different
way
that
I
didn't
see
that
was
uploaded
just
in
a
different,
manifest
some
different
annotations
on
the
Manifest.
However,
they
upload
it
and.
G
G
B
G
A
So
so
I
still
have
my
hand
up
for
another.
One
of
your
comments
earlier,
which
was
you're
talking
about
refers
and
garbage
collection
refers
on.
My
own
personal
to-do
has
been
to
implement
something
that
would
allow
you
to
easily
look
that
an
image
that's
been
deleted.
Let
me
go
find
the
refers
type
of
points
to
something
that
no.
E
A
B
I,
that
is
actually
a
scenario
that
you
are
explaining,
I'm
more
looking
at,
like
let's
say:
I
have
an
image
right
and
I
attach
SPD
access
bomb
right
and
that
uses
the
Manifest
index,
because
one
zero
then
I
want
to
attach
Cyclone
DX.
So
I
need
to
go
to
update
the
Manifest
index,
but
the
update
means
I
need
to
create
a
new
one
and
theoretically
I
should
delete
the
old
one.
B
But,
like
I
was
talking
with
Jesse
the
other
day
and
he
said
we
don't
delete
all
ones,
so
you
normally
and
Docker
does
the
same
thing.
So
you
get
an
error
and
Docker
Hub.
Sorry,
you
get
an
error
that
says
so
yeah
we
created
the
first
one,
but
we
couldn't
delete
created
the
new
one,
but
we
couldn't
delete
the
old
one.
B
So
the
old
one
stays
right
and
if
I
can
like
the
first
thing
that
comes
to
mind
is
if
I
can
go
and
actually
tag
the
old
one
I
can
rewrite
the
new
one
and
remove
the
reference
to
the
second
TX.
That
is
one
thing,
but
so
it's
not
removing
the
blobs
this
time.
But
it's
just
removing
this
index
that
points
to
outdated
information.
A
Where
would
you
be
attaching
that
other
content
in
there?
Because
what
I'm
thinking
of
is
you
update
the
refers
index
you're
going
to
add
a
new
entry
to
there?
The
new
refers
manifest
is
going
to
have
all
the
refers
he
had
before,
plus
some
other
thing,
and
so
you
wouldn't
get
rid
of
any
of
the
other
artifacts
themselves.
You're
just
going
to
clean
up
that
index
that
had
one
less
entry
in
it.
D
Right,
this
is
also
with
how
Registries
don't
delete
any
manifest
right.
There's
no
guidance
around
pre-tagging
latest
and
keeping
that
around
so
I
think
the
the
general
problem
is
we
don't
Define
anything
to
do
with
garbage
collection
and
it
becomes
hard
to
describe
to
customers.
What
should
they
do?
With
these
old
manifests
and
I
mean
we
want
to
keep
them
around
for
making
sure
digest,
pools,
don't
fail.
We.
G
D
And
I'm
actually
ambivalent
about
GC
in
this
space
because
I
feel
it
is.
It
is
very
specific
to
how
you
implement
it,
but
an
API
to
indicate
whether
you
want
to
delete
stuff,
cascading
deletes
might
be
more,
maybe
something
we
can
think
about,
so
that
hey
I'm
deleting
the
rest
just
clean
up.
All
the
garbage.
Don't
keep
around
these
other
reference
tags
and
whatnot
right.
So
that
might
be
helpful
because
it's
implicitly
done
for
blobs,
but
it's
not
done
for
refers
right
now.
B
And
the
other
thing
that
may
be
helpful
is
having
a
way
to
discover
those
kind
of
random
artifacts
right
now
we
cannot
list
all
the
intact,
for
example,
images,
and
the
same
is
true
for
all
these
contact
index
manifest
right.
So
if
having
an
API
that
actually
allows
me
to
discover
all
these
things,
then
we
made
watercol,
then
say:
okay,
either
the
client
can
do
it
or
at
the
minimum.
B
There
is
some
visibility,
but
now
those
actually
remind
kind
of
hidden
in
the
registries.
A
G
D
The
distribution
has
a
nice
sample
implementation
of
tag.
History,
like
you,
look
at
a
tag,
and
you
know
what
are
the
digest.
It
was
referring
to
and
things
like
that,
I
don't
know
whether
anybody's
actually
considered
making
that
a
standard
where
the
history
of
the
tag
can
be
exposed,
because
it's
hard
for
customers
to
keep
this
data
right
over
time.
A
G
B
Okay,
I'll
look
at
this
yourself,
I'll,
something
just
for
just
for
kind
of
keeping
a
record
on
that
thanks.
A
C
I
just
want
to
say,
I
updated
the
pr
Brandon
thanks.