►
From YouTube: 🖧 IPLD Every-two-weeks Sync 🙌🏽 2023-01-16
Description
An every two weeks meeting to sync up on all IPLD (https://ipld.io) related topics. It's open for everyone and recorded. https://github.com/ipld/team-mgmt
A
Welcome
everyone
to
this
week's
ipldc
meeting,
it's
the
first
meeting
in
2023
and
yes,
every
two
weeks.
We
go
over
the
stuff
that
people
have
worked
on,
I,
think
now
in
the
past
four
weeks
or
so
and
then
discuss
any
open,
Agenda
items
which
we
actually
have
today.
A
So
the
nice
thing
is
that
today,
even
I
have
an
update
because
I
dare
to
work
the
full
past
week
on
only
multi
formats
and
I
believe
stuff.
So
therefore,
I
have
an
update.
So
first
thing
is
Rod,
actually
contributed
and
negative
codec
test
features
which
you
probably
will
also
talk
about,
implemented
it
for
JS
and
go
and
I
did
the
rust
implementation
for
them
and
also
then
did
run
them
on
the
Codex.
A
B
A
So
yeah,
that's
quite
a
relief,
then
on
Wednesday
this
week,
I
I
was
asked
so
protocolabs
has
this
thing
called
a
Launchpad
which
is
kind
of
like
a
boot
camp
for
web
3
and
interplayer
things,
and
they
asked
me
to
give
a
shallow
dive
talk
into
iple,
which
I
will
do
on
Wednesday
and
I
have
already
like
prepared
the
slides
not
fully
done
yet,
but
I've
already
linked
them.
So
I
need
to
make
a
few
sites
a
bit
nicer.
Still
that's
the
contents
and
it's
so
that
the
audience
is
non-technical.
A
So
it's
really
high
level
and
I
try
to
explain
things,
hopefully
in
an
easy
way,
we'll
see
how
this
goes
and
because
so
it's
basically
the
talk,
20
minutes,
plus
q
a
and
then
in
the
Q,
a
I
will
find
out.
If
it
was
good
or
not,
I
will
tell
you
in
two
weeks
and
last
but
not
least,
I
wrote
up
the
application
context
proposal,
that's
a
thing
at
the
lab
week
and
ipfs
camp
and
where
many
people
from
the
ipld
world
and
really
little
things
met.
A
A
This
is
something
that
many
people
yeah
worked
on
and
have
discussed
with
me
about,
and
this
is
kind
of
like
a
first
draft.
I've
made
it
in
a
way
like
the
interplanetary
Improvement
proposals,
because,
like
it's,
it
is
ipld,
but
still
like
it's
I
mean
you
need
to
ask
yourself
the
same
questions
as
an
on
an
ipip
proposal.
Basically
so
use
this
format.
It's
linked
in
the
notes.
A
It's
really
like
the
first
version
that
I
finished
today.
I,
certainly
don't
know
how
much
time
I
will
have,
but
it
would
be
great
if
people
could
have
a
look,
especially
recorded
would
be
great
to
get
early
review
on
like
if
this
makes
sense
or
basically,
if
you
can
follow
what
I'm
talking
about
and
then
basically
so
my
plan
would
be
to
send
this
out
to
the
people.
I've
discussed
this
thing
with
and
get
feedback
and
then
make
an
official
proposal,
kind
of
which
relates
to
a
discussion
topic.
A
We
have
about
CID
version
2,
because
I
would
just
retire.
This
PR-
and
this
is
kind
of
the
alternative
and
I
would
say
the
yeah
most
prom
missing
or
the
most
worked
on
I
guess,
but
we'll
see
yeah
so
feedback
is
welcome,
so
yeah.
If
people
have
a
time
to
look
at
it,
we
can
also
discuss
it
in
two
weeks.
For
example,
cool
yeah,
that's
all
I
have.
C
So
lots
of
little
things,
but
two
two
of
the
bigger
things
in
the
last
I
guess
this
year
done.
Oh
sorry
and
a
couple
of
interesting
bug,
reports
by
gazada
Rockley
in
the
mainly
coming
out
of
the
JavaScript
stack,
but
one
of
them
was
the
fact
that
highlighting
the
fact
that
our
JavaScript
codex
will
allow
decoding
of
duplicate
map
keys
without.
C
Having
a
problem
with
it,
particularly
daxby
born
dag
Jason.
So
if
you
give
it
a
map,
if
you
feed
it
a
block
in
the
mat
and
then
there's
duplicate
map
Keys,
then
the
only
the
second
one
will
be
used
or
the
last
one
will
be
used.
So
you
can
have
as
many
duplicates
as
you
want
and
yeah.
C
So
the
go
codex,
don't
do
this.
There
they
go
codex,
there
will
reject,
and
so
that's
that's
bad
data.
Okay,
so
we
released
a
new
version
of
a
new
major
version
of
dag
Jason
and
Jack
siebel
that
will
reject
duplicate
map
keys
in
the
blocks,
not
that
I've
ever
seen
them
before.
C
I,
don't
know
we're
not
aware
of
any
of
these
in
the
wild,
but
it's
one
of
these
ways
of
you
know
hiding
data
or
you
know,
adding
extraneous
data
to
blocks
to
get
different,
cids
and
yeah,
but
just
it's
not
a
huge
deal,
but
it's
sort
of
closes
one
of
those
very
weird
Corner
cases,
yeah
so
and
then
out
of
that
work
as
well
came
negative
test
fixtures
which
I
just
sort
of
bit
the
bullet
and
finally
did
that
after
we
had
two
two
of
these
reports
about
codex
and
and
they
were
both-
they
both
the
kind
of
things
that
would
be
nice
to
have
negative
test
fixtures
for
so,
and
we've
been
talking
about
it
for
ages,
but
we
want
to
have
failure,
cases
and
actually
I
think
I've
linked
to
the
wrong
pull
request
there.
C
So
there's
a
the
broadcast
I've
linked
to
is
for
negative
test
fixtures
for
the
duplicate
map
keys,
but
the
one
I'm
going
to
link
now
is
actually
that
is
actually
the
original
one.
C
So
so
the
idea
with
these
is
they
are
failure
cases
for
codex
where
there's
two
modes
for
these
get
running.
C
One
is
where
you've
got
a
block,
that
is,
the
bytes
are
bad,
so
it's
their
targeted,
specific
codecs,
where
you
will
have
a
some
bytes
and
a
codec,
and
it's
supposed
to
error,
and
there
are
error
messages
in
the
fixtures,
but
they
are
they're
optional
for
codecs,
so
codex
will
may
or
may
not
use
those
error
messages,
so
just
based
them
on
I
think
I
based
them
originally
on
the
JavaScript
errors
in
dagpb
most
there
are
many
error.
C
Cases
are
the
same
between
the
go
and
JS
codecs,
because
they're
they're
sort
of
written
to
match
each
other,
but
the
stacks
are
different
enough
that
the
error
messages
are
not
always
consistent
and
then
the
other
case
is
where
you
have
a
data
model
form
in
memory
and
you
want
to
encode
it,
and
so
there
are
many
cases
where
you
have
something
in
memory
that
you
can
encode,
particularly
for
dag
PB,
because
it's
such
a
restrictive
codec.
C
You
can
have
lots
of
forms
in
memory
that
you
can't
you
can't
put
in
today.
Pb,
that's
just
how
it
works.
So
the
those
go,
the
other
way
where
we've
got
data
model
form
written
in
some
other
data
at
some
other
form,
so
either
dag
Json,
because
it
goes
nicely
in
Json,
fixtures
or
I.
Think
I've
got
a
hex
version,
so
hex
for
think
Dax
evil
you
can
do.
C
You
can
represent
Dax,
ebola's,
hex
and
and
instantiate
that
into
the
data
model
and
then
be
able
to
put
that
into
the
the
codec
that
you're
trying
to
test
and
then
tested
an
error
on
the
way
in
so
yeah
those
those
two
things
are
in
there.
There's
there's
lots
more
cases.
I
mean
this
is
a
an
area
where
we
could
failure.
Cases
are
almost
infinite,
I
think
but
be
judicious
in
what
you're
at
so
that's
in
there
lots
of
stuff
to
do.
C
A
Thanks
does
anyone
else
have
any
updates
or
want
to
give
any
updates?
A
If
not,
then
we
go
to
the
agenda
items
all
right.
So
on
the
list
we
have
the
next
steps
for
cidd
version.
Two,
so
I
think
that's
the
pr
I'm
aware
of.
Let
me
quickly
pull
it
up.
C
Yeah,
so
we
put
this
on
the
on
the
agenda
just
coming
out
of
some
ideally
triaging.
It's
noting
that
we've
got
at
least
two
issues
and
pull
requests
open
talking
about
the
idv2
and
it's
not
clear
where
we're
going
next
and
so
actually
put
it
on
the
agenda,
because
you've
taken
most
of
the
responsibility
for
yeah.
A
So
I
would
so
I
would
I
so
so,
as
the
so
I've
also
talked
with
the
person
that
created
the
poor
request
or
regionally
with
John
at
that
week
as
well,
and
he
basically
said
also
like
he
like
he.
He
even
doesn't
think
himself
that
this
way
is
a
good
idea
anymore
for
his
use
case.
So
he
wouldn't
push
it
further
and
I.
A
Have
this
other
proposal,
so
I
would
like
I
would
be
able
to
just
close
it
and
then,
like
probably
like
put
when
I,
have
a
pro
proposal,
put
a
link
in
there,
but
it
can
also
be
closed
beforehand
because
well,
like
I.
Can
then
think
if
people
find
it
but
I'm
happy
to
close
it,
because
I
don't
think
it's
going
anywhere
and
but
I
can
like
what
I
can
do
is
like.
A
B
C
So
there's
the
pull
request
and
then
there's
the
original
crdv2
proposal
that
came
in
as
an
issue
from
Michael
in
IPL.
The
ipld
I
think
it
was
oh.
A
But
is
it
like,
but
is
it
the
same?
Oh
that's.
The
okay,
yeah
I
will
oh
yeah
I
would
is
there
and
I
put
the
IPL
d.
A
C
Cool
okay
and
then
the
next
one
was
actually
and
I.
Think
you're
you're
more
over
this
as
well,
but
okay.
But
it
was
this
jwk
JCS
pull
request.
I
just
didn't,
have
the
brain
space
to
be
able
to
process
this.
So
the
the
interesting
thing,
the
interesting
thing
about
this
that
I
thought
was
especially
this
challenge
of
signaling.
C
C
There
are
additional
rules
for
how
you
encode
and
I,
actually
think
that's
a
positive
improvement
over
Jason
that
we
could
people
could
find
use
for
in
the
multi-codic
table,
not
that
anyone's
actually
requested.
That
specifically,
but
then
this
is
a
it's
like
a
schema
on
top
of
canonical
Jason
and
they
wanted
a
codec
for
that,
but
I
think
you've
dived
into
it
a
bit
more
and
come
to
some
conclusions
about
it.
A
Yeah
so
I
I,
so
then
I
might
have
misunderstood
what
they're
doing,
because
I
thought
it's
so
in
the
does
message,
basically
so
I.
So
basically,
I
was
also
like
having
a
hard
time
following
what
they're
actually
doing.
But
what
I
understood
is
that
what
they
really
want
to
do
is
they
kind
of
want
to
use
it
as
a
what
I
call
multi-codec?
Well,
obviously,
just
like
it's
a
prefix
for
something.
A
So
it's
not
somebody,
it's
that
what
follows
is
so
basically
the
bytes
that
follow
are
listen
this
kind,
and
this
is
what
they
want
to
have
the
prefix
for
so
basically
put
in
multi-coding
in
front.
So
they
know
the
following:
bytes
are
this
and
this
I
mean
it's
really
so
this
was
really
about
the
key.
Only
I
thought.
So
it's
really
about.
A
Let
me
see
I
need
to
check
it
in
so
I
thought
it's
really
about
this
key
yeah,
so
so,
basically,
a
prefix
bytes
with
this
identifier.
This
is
all
they
do.
I
thought,
but
I
might
have
misunderstood.
C
Yeah
I,
maybe
maybe
we
need
Clarity
because
it
because
they
have
asked
for
it
as
a
key
tag
and
yet
in
the
original
message
they
want
it,
for
this
proposes
a
codec
for
all
jwk
types,
which
yields
a
deterministic
output.
A
So,
okay,
good
question:
oh
so
I
thought
it's
so
basically
what
I
thought!
If
you
look
at
the
last
comment
in
there,
like
the
comments
before
buying
the
pr
from
Ellen,
Horvath
and
there's
a
link
to
this,
did
method
key
thing
and
like
the
the
and,
if
you
scroll
up,
you
see
like
it's
Dad,
colon,
key
colon,
Something
and
I
well,
I
understood
is
for
this
end
code
like
this
was
some
bytes
somehow
and
I
thought
for
this
encoding.
They
just
wouldn't
have
identified
at
the
front.
B
B
So
so
I
think
that
that
did
so
did
key
uses
is
just
the
the
the
prefix
the
first
few
bytes
just
tell
you
which
what
the
key
type
is
as
I
understand
it
in
did
key
sorry,
I
I
had
not
read
this
beforehand.
I
am
trying
to
parse
this
on
the
fly,
but
I
know
Alan,
so
I
feel
Duty
bound
too.
C
So
so
so
one
to
clarify
our
concerns
here
is-
and
this
is
a
really
tough
area,
because
we've
got
these
gray
area
around
it,
but
really
at
the
heart
of
it.
What
we
don't
want
to
be
doing
is
registering
codec
codes
that
get
used
in
cids.
C
If
the
intention
is
to
identify
something
you
know
for
some
other
purpose
like
like,
if
it
really
is
just
a
prefix
within
the
did
format
that
says
all
the
bytes
that
follow
are
going
to
be.
You
know
you
do
something
else.
I
mean
it
is
a
codec
really,
but
it's
not
the
kind
of
thing
that
you
would
see
end
up
in
cids
that
that
sound
I
know
that
sounds
a
little
bit
weak,
but
that's
that
sort
of
gets
towards
the
heart
of
the
concern
here.
C
The
fact
that
they
asked
for
it
as
a
key.
It
does
suggest.
Maybe
that's
that's.
It
is
separate
yeah.
So.
A
If
you
read
the
last
comment
before
mine,
where
he
writes
that
they
understand
cads
and
like
like
to
me,
please
comment
basically
with
the
last
sentence
was
which
basically
convinced
me
that
they
know
what
they're
doing
and
just
yeah.
Okay,
don't
want
to
use
it
as
a
CID,
but
really
as
a
prefix
for
the
key
yeah.
C
Yeah
and
ultimately,
this
is
this:
is
their
dilemma?
Isn't
it
is
that
really
the
the
this
should
be
a
shared
Common
Table,
that
people
register
that
you
know
unique
identifiers
and
we've
got
to
be
careful
gate,
keeping
it
too
strictly,
but
we
do
have
this
dilemma
of
people
want
to
use
it
for
signaling
and
cids
all
the
time,
so
they
want
to
make
a
custom
codec.
That's
the
thing
we
want
to
be
careful
of,
and
that's
really.
C
A
Yeah,
so
in
in
regards
to
this,
like
so
in,
regards
to
the
like
the
whole,
like
what
do
you
put
in
cids
and
so
on
also
kind
of
like
touches
my
application
context
proposal
because,
like
as
it
enables
many
new
use
cases
I
think
it
makes
I've
also
put
it
in.
There
makes
the
cads
like
Tighter
and
easier,
and
so
I
would
hopefully,
if
this
accepted
say
that
c
IDs,
so
the
codec
field
in
the
cads
is
really
only
about
was
two
things
still
two
things.
A
A
So
this
is
also
like
kind
of
really
pretty
too
like
how
strict
can
we
be,
and
so
on.
I
actually
have
a
question
for
you
Rod
in
regards
to
this,
because
what
with
thought
about
this
whole
Topic
in
the
past
week,
I
thought.
Currently
we
have
the
also
like
Json
and
Seaboard.
It's
called
I
mean
like
not
deck
Json,
but
really
Jason
and
seabor,
and
which
currently
is
kind
of
like
more
or
less
like
raw
from
hard
Works.
C
Well
so
bro
this
and
this
this
is
this-
is
my
slight
disagreement
with
one
of
your
other
comments
on
the
multicolic
type
in
the
last
week.
Is
it
is
more
about
just
getting
links
out
of
it?
There
is
about
conversion,
the
process
of
converting
to
the
data
model
that
has
become
how
we've
relied
on
yeah.
A
Which
I,
basically
I
discovered?
Basically,
when
I
like
wrote,
this
application
I
call
this
proposal.
I
then
discussed.
No.
Actually,
when
I
did
my
talk
about
I,
probably
for
the
non-terminal
people,
I
thought
about
like
how
do
I
explain
things
and
there
I
discovered
as
well
yeah
that
you
are
right.
It's
not
only
about
links,
because
if
you
basically
do
par
thing
through
ipld
within
path,
you
really
want
to
get
into
the
structured
data
and
you
need
to
know
how
to
decode
the
structured
data,
because
else
you
can't
get
into
it.
A
Obviously-
and
so
I-
agree
that
it's
more
like
this,
but
it's
but
I
kind
of
would
say,
is
IPL
the
data
model
or
getting
links
out,
because
the
links
could
even
be
well.
You
could
say,
links
are
the
iPod
data
model,
I
mean
as
a
sub,
so
links
are
a
subset
of
the
iPad
data
model.
You
could
argue
so
whenever
a
codec,
so
they
can
only
be
things
where
you
can
extract
things
into
the
iPad
data
model.
It
does
need
to
be
the
full
data
model
kind
of
yeah
yeah,
but
like
the.
A
What
I
would
put
to
ask
was
what,
if
we
would
allow,
for
example,
in
Json
and
cboard,
if
we
would
allow
links,
because
it
would
then
I
mean
it-
would
then
open
up
the
use
cases
that
also
dig
is
after,
which
is
I,
have
like
sometimes
horrible,
like
you
get
all
those
problems
with
custom
things
and
so
on,
but
it
would
at
least
like
I
think
it
would
fit
into
the
current
way
of
how
we
think
about
things,
because
then
Json
is
really
a
serializer,
which
is
not
the
full
data
model
but
still
has
links
it's
which
is
useful.
A
C
And
I
mean
stable
is
easy,
because
it's
a
tag
and
we've
registered
a
tag
42
in
the
Seaboard
table.
So
it's
legitimately
you
could.
You
could
do
that
with
someone
now
you
could
say
Okay
C
board
is
is
what
is
freeform.
It
doesn't
really
have
as
many
rules
other
than
you
need
to
be
able
to
get
it
into
the
data
model,
and
that
can
come
with
links.
So
we
could
definitely
do
that
with
C4.
C
Jason
is
different,
though,
because
it's
when
we,
when
we
do
dag
Jason
one
of
the
reasons
it
has
to
be
different,
is
because
we're
restricting
the
the
range
of
what
Jason
can
represent
and
if
we're
saying
we
recognize
dag
Jason
links
in
the
Json
one,
then
we're
actually
restricting
Json
itself.
C
So
I
don't
know.
If
we
want
to
do
that
to
be,
it
could
be
something
that
you
do
as
a
post-processing,
but
then
I
don't
think
it
belong
to
the
code.
A
C
Because
because
you
want
a
data
model
form,
you
want
to
be
able
to
instantiate
something
into
the
Dynamo.
So
I
want
to
link
to
a
blob
that
doesn't
that's
terminal,
so
it
doesn't
contain
any
links,
but
it
has
structured
data
in
it.
So
I
want
to
path
in
even
potentially
path
into
that
blob,
okay
and
get
something
out
of
it.
So
the
data
model,
like
the
data
model,
is
I'm
so
much
more
than
links
and
that's
the
whole
point
of
iPod
is
yeah.
C
A
Which
I,
like
I,
had
a
discussion
with
rebar
like
like
a
year
ago,
or
so
probably
already
that
about
like?
If
we
should
also
like
introduce
the
distinction
between
like
terminal
things
and
not
terminal
things
like
somehow
like
again
like
in
an
abstract
way
like
somehow
or
somewhere,
yeah
yeah
yeah
yeah.
There.
B
C
Let
me
see
if
there
is
an
example
of
of
this
hard-coded
into
code.
That
is
I
think
is
instructive.
I
always
point
to
this
as
one
of
the
ways
in
which.
B
Because
that's
he's
asking
for
a
link
that
without
following
it,
you
know
it's
going
to
give
you
a
jwk
like
a
Json
object
that
isn't
bad
Json.
That
doesn't
keep
going
and
it's
you
know
like
a
string.
That
is
a
points
to
a
blob.
That's
terminal
like
this.
This
string
only
leads
to
a
bump,
so
I
think
he
might
be
asking
for
that.
B
C
Yeah
I
mean,
but
if
it's
an
if
it's
part
of
the
data
model,
so
if
it's
back
to
the
back
to
that
one,
it
is
its
terminal
doesn't
contain
links,
so
we
would
say
that's
Json
and,
and
specifically
they
want
to
use
Jason
canonical.
So
then,
if
you
were
to
have
a
CID
to
represent
that,
you
should
have
Jason
canonical,
because
then
that
gives
you
the
ability
to
turn
that
into
data
model
form,
but
yeah
I.
A
Yeah,
but
coming
back
to
the
the
ID
thing,
so
is
it
so
is
the
key
a
hash
of
something
or
is
it
the
actual
data
in
the
key.
B
C
C
The
kind
of
use
for
multi-coded,
where
it's
like,
okay,
you're
doing
something
interesting,
go,
go
ahead
and
do
it
we
care
about
cids.
This
is
not
cids,
yeah,
yeah
I
get
that
and
it's
not
they're,
not
after
the
ipld
or
even
serialization
tag.
So
that
does
say
something
else.
So
I
think
in
this
case,
Stick
it
to
the.
If
it's
got
the
key
tag,
you're
doing
something
novel,
you
know
we
shouldn't
have
to
be
concerned.
So
you
just
step
very
close
to
something
that
we
tend
to
get
concerned
about.
I
think
is
the
holdup.
C
A
A
C
Terminal
blocks
and
stuff,
the
code
has
changed
in
jsrpfs,
but
there's
been
like
a
couple
of
blocks
of
clothing
JavaScript,
particularly
where
for
decoding
dags
and
walking
through
dags,
where
we
we
hard
code,
a
list
of
codecs
that
are
supported,
but
we
say:
don't
bother
decoding
them
when
you're
traversing
a
dag,
because
he
won't
find
anything
useful
in
them
and
we
hard
code,
Seaboard,
Jason
and
raw,
and
so
when
you're
doing
a
dag
walk.
C
If,
if
you
encounter
a
CID
that
has
one
of
those
codecs
so
there's
a
bunch
of
like
other
codecs,
you
might
encounter
that
we
can't
decode
because
they're
not
loaded
like
they
might
be
loaded
or
not
into
the
system.
So
we
don't
bother
with
them.
But
since
we've
got
those
codecs
loaded
into
the
system,
if
you
encounter
a
block
a
link
to
a
block
that
has
that
codec,
then
it
is
hard
code.
C
It
goes
to
this
hard-coded
list
and
says:
oh
it's,
one
of
those
codecs
I
won't
even
bother
looking
I'll
grab
the
block
because
it's
part
of
my
dag
but
I
won't
bother
decoding
it
because
there's
no
point
I
won't
find
links
in
it
and
I.
Think
that's
one
of
the
most
interesting
things
about
this
question
of
links
versus
no
links.
C
B
So
is
that
list
of
three
codecs
for
terminal
for
for
end
Leafs?
Is
there
you
refer
to
it
as
like
a
for
for
legacy
reasons?
Is
there
a
desire
not
to
add
any
more
of
those.
C
These
things,
but
I
did
have
a
thought
if
we
were
doing
something
like
this,
then
because
we've
been
talking
about
switching
Json
and
sibor
to
the
tag
serialization
in
the
multicodic
table
rather
than
ipld
and
I
was
I
was
thinking
that
if
we,
if
we
bumped
into
a
case
like
this,
we
want
to
go
back
to
this
case
and
fix
it
up,
and
we,
instead
of
having
a
hard-coded
list,
you
could
take
the
output
of
the
multicodec
table
and
say
is:
is
this
tag
serialization
or
is
it
tag
ipld?
C
If
it's
serialization,
then
it's
a
terminal
block?
It's
not
going
to
contain
any
links,
so
you
could
actually
use
that
as
a
flag
and
then
you
could
do
it
for
every
codec.
We
could
actually
apply
that
as
a
strict
Rule,
and
so
you
want
to
and
whether
or
not
your
system
supports
those
codecs.
You
still
have
the
information
about
it,
hey
and
then
you
could
actually
provide
information
to
the
user
like
if
the
user
says
I
want
you
to
collect
all
of
my
dag
and
and
the
system
gets
to
a
CID.
C
That
is
tag
ipld
and
it
doesn't
have
the
codec
it'll
say
to
you.
Look
I
can't
get
all
your
dag,
there's,
probably
more
dag
behind
this
block,
but
I
can't
decode
it
or,
alternatively,
it
gets
to
a
leaf
and
the
tags
is
zero
realization
and
it
doesn't
have
the
code
again.
It
says:
look
I
I,
don't
have
the
codec
for
this,
but
I
can
still
get
the
block
and
I
know.
There's
no
terminal,
there's
no
links
behind
it.
C
So
I
you've
got
your
complete
data,
so
that's
something
we
could
do
with
those
those
tags
in
the
multicode
table.
B
C
Yeah,
because,
because
in
ipld,
we've
got
these
two
modes
that
we
I
find
useful
to
consider,
one
mode
is
something
like
a
pinning
service
or
a
a
dag
storage
service
like
filecoin,
where
the
assist
all
the
system
cares
about,
is
being
able
to
get
the
dag
and
sometimes
to
get
the
dag
in
a
predictive
predictive
order.
So
you
know
a
a
canonical
order
of
a
dag.
Sometimes
that's
that's
useful.
C
C
Like
a
pinning
service,
they
don't
need
to
understand
the
data
in
other
than
how
do
I
get
links
out
of
it,
sometimes
in
in
the
right
order
to
get
all
all
the
blocks
and
then
there's
a
second
mode,
which
is
where
the
particularly
application
developers
where
their
structured
data
becomes
important.
So
I
want
to
get
the
dag,
but
I
also
want
to
go
into
the
blocks
to
get
the
structured
data
out
so
I
I.
C
Finally,
I
find
it
useful
to
think
of
those
two
separate
modes
when
considering
these
questions
because
they
do
come
into
play
but
separately
very
often,
we've
got
these
intermediate
things
where
we
just
want
to
transfer
blocks
and
then
understand
the
DAC.
That's
all
we
don't
want
to
know.
What's
in
it,
we
just
want
to
know
how
to
piece
it
together
and
and
that's
that's
a
useful
map
because
you
can
be
really
efficient
there.
But
then
you
come
into
these
questions
of
okay.
I,
don't
have
the
codec
for
that.
C
B
Jcs
might
be
I
mean
I,
I'm
I,
don't
really
know
exactly
why
this
guy
is
my
friend
Ellen
is
requesting
JCS
be
marked
explicitly
different
than
Json,
but
it
is
sort
of
like
more
structured
data.
It's
like
more
deterministic
Json
because
Json
could
like,
if
it
isn't
JCS
to
the
the
same
data,
could
be
represented.
Two
different
ways
in.
C
C
And
that's
why
that
was
my
comment
in
there
that
if
somebody
wanted
a
JCS
or
Jason
canonical
whatever
we
call
it
entry
in
the
multi-coded
table,
that
makes
sense
to
me.
But
if
I
was
to
represent
I'm
Jason
for
ipld
purposes
and
I
wanted
canonical
forms,
I'd
just
go
with
dag
Jason,
because
that
that's
one
of
the
things
it
does.
It's
got
a
canonical
form.
C
Jcs
is
like
canonical
it's
like
diagnation,
that
was
written
for
Jason
general,
not
ipld,
because
in
the
ipld
data
model,
we're
more
restricted
from
the
Json
data
model
or
we're
more
restrictive
than
the
way
people
use
Json
in
the
in
the
wild
right
I'm,
actually,
not
that
much
more
restrictive,
but
dag
Jason
serves
that
purpose.
But
if
you
were
to
have
structured
data
that
you
didn't
care
about
links
and
you
wanted
to
represent
it
as
a
ipld
block,
and
you
wanted
to
have
rules,
then
JCS
would
make
sense
to
me.
C
Yeah
yeah,
yeah,
yeah,
so
I
think
it's
a
legit,
codec
and
and
what's
more
you
if,
for
our
purposes
like
all
these
intermediate
systems,
you
could
treat
it
just
like
Jason
Because.
Unless
you
are
doing
the
encode
thing
decoding
it's
easy,
like
decoding
just
uses
a
Json
code,
we
could
use
mostly
reuse
the
deck
Json
decoder,
even
if
we
wanted
to
or
just
a
Json
Json
decoder
to
get
the
data
out
for
looking
at
it
and
inspecting
into
it.
C
A
Yeah
so
I
I'm
I'm,
not
sure
about
this
one.
So
I
would
argue
it's
not
a
proper
coding,
the
meat
Force
again
into
the
like
other
thing,
which
I
hope
to
solve
with
the
application
context
because
like
to
be
still
Json.
So
it's
especially
kind
of
Json,
but
it
should
be
signaled
somewhere
else
and
not
with
in
the
CID
but
yeah.
Let's
open
for
discussion.
B
A
C
Would
you
but
yeah
Jason's
schemered
version
of
Jason?
That's
the
thing:
it's
okay,
when
you
start
applying
schemas,
then
like
okay,
you've
got
the
codec,
but
then
you've
got
a
scheme
on
top
of
the
code.
That's
when
it
gets
problematic
because
you're
you're
wanting
to
Signal
your
schema
within
the
codec.
That's
that's
not
what
that's
the
problem
but
Jason
canonical
is
a
is
a
subset.
It's
really
a
subset
of
Jason
in
a
sense
yeah
anyway.
Maybe
it's
not
yeah.
A
But
I
mean
I
can
see
the
point.
This
would
be
a
tough
one
and
I
agree
that
there
might
be
a
point,
but
okay,
so
put
it.
Please
I
agree
that,
like
a
good
point
that
you
made
is
that
there's
a
difference
between
like
a
subset
of
a
codec
and
like
yes
scheme
on
top
of
a
codec
or
like
a
stream
that
a
schema
that
defines
what
the
code
it
should
do
but
yeah,
but
is
it
like,
but
yeah
yeah
anyway,
we
can
discuss
this
yeah.
C
But
but
the
fact
that
we
keep
on
coming
back
to
these
discussions
and
we
keep
on
having
these
interactions
with
people
in
the
ecosystem
that
want
to
do
things.
It
keeps
on
saying
that
we
haven't,
we
haven't.
We
either
haven't
figured
out
the
right
answers
here,
or
we
haven't
solved
the
right
problems
or
have
the
right
tools,
so
we
really
do
need
to
to.
We
need
to
make
this
whole
thing
go
away
by
either
having
answers
yes
or
having
tools.
So,
let's.
A
It's
so
so
so
so,
basically,
the
the
the
rough
idea
is
that
so
it's
just
so
so
the
yeah,
so
instead
of
having
it
in
the
cad,
you
have
it
somehow
external
and
use
it
as
a
signaling
mechanism
and
then,
of
course,
implementations
need
to
understand
this
additional
thing.
A
It's
still
that
simple.
It
should
stay
like
this,
at
least
for
those
cases,
and
if
you
have
additional
cases,
then
you
do
this
more
powerful
thing
which
is
outside
of
it
and
not
always
civilized
with
it,
because
so
the
other
use
case
is
doing
it
dynamically.
So,
for
example,
you
want
to
have
so
you
have
the
really
like
the
same
data,
but
you
want
to
process
it
somehow
differently.
So
you
want
to
have
to
a
different
kind
of
traversal
or
you
want
to
have
it
processed
in
a
different
way.
A
So
there
you
basically
Supply
the
context
of
I,
want
to
process
it
this
way,
but
it's
the
same
CID
and
you
don't
process
this
other
way,
but
the
same
CID.
So
it's
kind
of
like
you
can
kind
of
have
it
not
down
to
read
the
data,
but
so
it's
things
that
are
not
directly
part
of
the
data.
Basically
that's
kind
of
the
rough
but
yeah
but
feel
free
to
read
the
proposal
and
then
yeah.
We
can
discuss
it
in
two
weeks.
A
C
But
this
this
thing's
been
bubbling
for
a
while.
It's
this
whole,
this
whole
idea
that
you,
you
don't
show
up
to
data
you
know,
and
data
is
not.
Data,
isn't
doesn't
tend
to
be
just
free
floating.
C
A
lot
of
the
troubles
we
get
into
is
by
conceiving
data
as
free
floating
out
there
that
you
show
up
to
magically.
You
happen
across
data,
and
you
want
to
look
at
it.
You
know
we
it's
sort
of
like
the
the
archaeologist
form
of
data
like
you've
dug
down
and
you've
found
this
piece
of
data
and
I
want
to
look
into.
Oh
look.
What
could
this
be?
And
oh,
it's
just
an
array
of
numbers
and
strings
whatever
and
bytes?
What
do
I
do
with
this?
You
know
that.
C
That's
that's
how
we
as
sort
of
particularly
those
of
us
who
you
know,
create
iple
tools.
We
tend
to
think
about
data,
but
that's
not
how
data
works
in
the
real
world
data
is.
Data
tends
to
be
used
within
an
application's
context,
so
an
application
has
a
notion
of
what
the
data
is
used
for.
So
when
it's,
when
it
shows
up
to
that
all
the
data
shows
up
for
the
system.
It
brings
this
notion
of
what
am
I
doing
with
it.
C
So
that's
all
this
context
that
comes
in
okay,
I've
got
a
block
and
it's
an
array,
and
it's
got
some
numbers
and
bikes
in
it,
but
I
know
exactly
what
to
do
with
it,
because
because
my
context
is
contained
within
my
application,
but
but
very
often
there's
a
very
often.
You
want
to
signal
that
context
to
another
person,
so
people
say
well
I
want
to
give
my
CID,
but
I
also
want
to
pass
on
some
additional
information
about
it.
So
here's
my
Cod
and
he's
a
schema
so
I
want
to
I.
C
B
C
Want
to
they
want
to
express
application
context
or
data
context,
along
with
the
data
itself.
Here's
these
two
pieces.
So
that's
where
the
original
CID
V2
proposal
comes
from.
Here's
a
here's,
a
link
to
the
block
and
how
you
decode
it
into
dialer
model,
but
here's
something
else
about
it:
that
I
want
to
glue
together
to
it
and
I
want
I
want
these
two
things
to
be
expressed
together
and
maybe
I
want
to
store
those
things
or
maybe
I
want
to
pass
them
on
to
someone
else.
When
I'm
talking
about
my
data.
B
Right
I
mean
I,
do
think
you
know
in
a
way
like
that,
isn't
mutually
exclusive
because
see
like
I
like
the
way
you
put
it
with
Seaboard.
We
don't
have
this
problem,
but
Json
refers
to
this
whole,
like
loosey-goosey
non-deterministic
like
there's,
there's
a
lot
of
dirty
messy
Json,
that's
useless
without
that
external
context,
and
JCS
is
one
of
many
more
deterministic
subsets
like
Doug
Json.
That
was
made
for
context
like
this,
where
maybe
you
need
the
data
to
be
legible
to
apologize
100
years
from
now
and.
C
Like
jwk
I
think
I
think
jwk
expresses
it
better.
I
mean
JCS
is
I'm
sure
not
quite
as
clear,
but
so
let's
say
I
encode,
my
key
as
a
block
and
it's
a
jwk
key
encoded
as
a
Json
block
and
I
give
it
to
you
and
I
say
this:
the
codec
is
Json,
so
you
can
grab
my
block
decode.
It
and
you've
got
a
structured
object,
but
you
don't
know
what
to
do
with
that.
Until
I
tell
you.
Oh
it's
a
jwk,
so
that's
the
additional
bit
of
context
is
I.
C
I
can
tell
you
how
to
decode
it,
how
to
instantiate
it
into
memory
into
the
data
model.
Okay,
now
I've
got
these
fields.
I've
got
a
map
and
I've
got
these
named
fields.
In
my
map
and
they're.
You
know
these
values
great,
but
so
what
it's?
It's
then
I
say:
oh
by
the
way
it's
jwk
and
then
you
say
now:
I
know
what
to
do
with
it.
Your
key
is
in
here
and
it's
in
this
algorithm
and
all
that
sort
of
stuff.
C
So
that's
the
additional
context,
and
so
in
a
sense,
that's
that's
the
schema
for
Json,
but
it
also
tells
you
what
you
can
do
with
it,
and
we
have
this
problem
as
well
with
my
favorite
example
is
the
filecoin
chain.
The
final
coin
chain
is
Dag
sibor
and
it
uses
a
Blake
2
hash.
But
that's
beside
the
point
except
for
the
fact
that
all
the
cids-
all
they
tell
you
if
you,
if
you,
if
you
link
to
any
Block
in
the
filecoin
chain.
C
All
you
know
is
that
it's
dagsy
ball
and
it
was
hashed
with
Blake
too.
You
can
get
the
bytes
and
you
decode
the
bytes,
but
they're
all
arrays,
there's
no
maps
in
it
and
there's
no
names
of
fields.
There
are
rays
of
random.
Looking
data,
it
really
is
ugly
data
if
you
just
decode
it
into
Dax
ebook.
But
when
you
bring
the
schema
of
each
of
the
different
blocks
in
that
chain,
you
can
bring
a
schema
and
then
you
can
transform
those
arrays
into
Maps,
because
you
can
it
says:
oh
well,
you
know
field.
C
One
is
this
field?
Two?
Is
this
field
three?
You
know
in
the
array
they
actually
transform
into
these.
These
struct
objects
and
you
can
do
that.
But
there's
no
way
of
if
I
give
you
a
a
key,
a
a
CID
to
a
random
block
on
the
farcoin
chain
and
just
say:
go
and
get
go
and
get
this
and
do
something
with
it.
You'll
look
at
it
and
you'll
say
it's
an
array
of
random
data.
C
B
C
Map
and
suddenly
you've
got
these
fields,
so
you've
got
a
schema,
but
then
all
the
additional
context
is
you
know.
The
key
bit
of
context
is
oh
by
the
way,
that's
a
block
in
the
file
coin
chain
that
that
itself
is
a
bit
of
context
that
you
that
I
have
to
communicate
to
you,
and
but
this
this
is
not
a
horrible
in
the
wild,
because
no
one
is
giving
random
blocks
of
the
file
coin
chain
to
each
other.
B
C
Yeah,
it's
the
right
area
like
you're
thinking
in
the
right
place,
but
mime
type
ends
up
being
the
codec
like
okay.
How
do
I
do?
How
do
I
turn
it
into
something?
I
can
look
at,
but
then
there's
all
this
additional
stuff,
so
mine
type,
mime
type,
does
push
beyond
what
iple
codecs
do,
because
you
can.
You
can
double
up
with
mine
types.
C
You
can
have
text,
but
then
you
can
have
all
these
other
things
that
apply
different
variations
of
text
but
yeah
anyway,
a
block
is
going
to
present
something
in
the
coming
week
or
so
it
sort
of
sums
up
some
of
these
discussions.
A
Yeah,
okay,
so
this
was
the
agenda
item
where's
my
hqd,
so
this
was
the
hni
about
the.
So
what's
the
what's
our
conclusion
on
the
jwk.
C
A
A
Cool
yeah,
all
right,
okay,
cool
anything
else.
People
want
to
discuss.
You
still
have
a
few
minutes
left.
A
Oh
yeah,
so.
C
And
that
is
interesting
actually
because
I
feel
the
URLs
do
some
of
this
work
and
there
is
a
double
upper
functionality
there
with
the
crdv2
desires,
where
you
can,
where
being
able
to
express
a
CID
and
additional
things
as
a
URL
does
actually
give
you
some
of
this
power.
C
So
if,
if
ipld
URLs
became
a
standardized
thing,
maybe
a
lot
of
these
concerns
would
go
away
because
if
I
can
give
you
CID
and
then
query
parameters
that
stack
up
and
and
a
predictable
form
like.
Oh
here's,
my
schema
and
here's,
my
ADL
and
here's
another
layer
of
schemas-
and
you
know
this
stack
of
ways
to
interpret
this
data
and
and
here's
a
path
once
you've
interpreted
the
data.
This
way,
I
want
you
to
go
down
into
this
path
to
get
this
piece
of
dial.
C
A
And
with
thanks
for
bringing
it
up
because
they
have
on
me
on
this
document,
I
have
a
long
and
just
where
I
thank
people
and
I
forgot
to
put
a
move
in
there,
because
they
were
also
part
of
the
discussion
like
so
I
did
so.
I
did
think
about
like
how
many
hours
I've
spent
at
lab
week
discussing
those
things
with
people
and
I.
Think
I
came
with
something
to
like
16
or
20
hours
or
so.
A
I
have
discussed
this
whole
thing
with
different
people,
so
many
people
yeah
but
yeah
so
I
would
also
say
it's.
It
is
certainly
related
and
also
Yeah,
so
basically
yeah
they're
also
part
of
the
discussion.
So
we
really
want
to
get
yeah
something.
Nice
worked
out,
cool
all
right,
yeah,
then
I
guess
I
closed
the
meeting
and
we
see
us
again
in
two
weeks
and
then
discuss
the
hopefully
the
proposal,
yeah
and,
of
course
like
after,
like
we
used
to
live
five
minutes.
A
So
if
you
want
to
stay
for
the
after
party,
if
you
have
anything
that
shouldn't
be
recorded,
feel
free
to
stay
all
right,
then,
and
goodbye
everyone
and
see
you
in
two
weeks,
bye.