►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2021-03-22
Description
A weekly 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
ipld
thing
meeting
it's
the
22nd
of
march
2021
and
as
every
week
we
go
over
the
stuff
that
we've
worked
on
in
the
past
week
and
discuss
things
that
yeah
open
questions
or
any
agent
items,
and
also
perhaps
ask
about
what
other
people
did
in
the
ipld
world.
Even
if
we
didn't
do
it
ourselves.
A
So
I
started
with
myself.
So
I'm
still
working
on
this
js
multi
formats
thing
in
js
ipfs.
A
Currently
it's
a
bit
on
a
break
because,
as
you
might
know,
there's
currently
this
effort
of
getting
type
type
script
types
into
js
ipfs
and
it's
close
to
being
finished
and
there's
currently
with
just
has
such
a
big
overlap.
That
just
makes
sense
for
me
to
pause
for
half
a
week
and
get
this
merged
first
and
then
I
resume
my
work
and
yeah.
So
I
still
hope
really
that
this
quarter.
I
will
finish
the
unix
fs
stuff
that
this
works
with
the
new
multi-formats
things
and
then
for
the
next
quarter.
A
The
plan
is
that
I
make
a
plan
because
I
won't
be
available
anymore
because
I'm
yeah
on
a
different
team,
but
have
a
plan
to
see
like
yeah,
also
to
estimate
how
big
it
is,
although
I'm
not
a
huge
fan
of
time
estimates,
so
I
will
probably
only
tell
how
big
it
is
and
not
how
long
it
will
take
and
then
see.
Is
it
a
proper
project?
Is
it
yeah
something
that
team
takes
on
or
we
will
see
but
yeah?
A
I
hope
it
will
only
be
a
friction
of
the
work
that
I've
I
did,
but
currently
I
also
have
the
feeling
that,
once
I
finish
the
unicef
s
stuff,
I
have
a
good
idea
because
either
everything
falls
into
place
or
I
find
out
that
yeah.
It
just
won't
work
and
it
will
take
another
year
to
do
so.
I
hope
fully.
You
will
reach
this
point
at
the
end
of
the
quarter.
It's
still
my
plan
and
I'm
yeah.
I
hope
to
get
there.
A
Therefore
yeah
I
don't
have
anything
else.
Next
is
eric.
B
I
think
there
might
actually
be
two
of
those,
because
we
have
two
different
layout
strategies,
I'm
not
sure
if
those
need
totally
divergent
code
pass
or
not,
there's
one
for
seeing
uncharted
directories
making
those
look
like
a
map
there's
another
one
for
traversing
the
hamps.
The
sharded
form
directories
so
now
we're
up
to
either
three
or
four
and
then
the
most
interesting
one
or
the
the
most
outlandish
one,
perhaps
is
the
last
one,
which
is
something
that
sees
through
the
directories
and
jumps
past
the
metadata
to
the
next
file,
and
this
fourth
or
fifth.
B
But
anyway,
final
one
is
the
one
that
I'm
hoping
will
make.
Unix
fsv1
style,
pathing
be
essentially
ipld
native.
So
if
all
those
things
work
according
to
dream,
it'll
be
really
really
cool
but
yeah.
I
would
love
review
on
on
that
road
map
and
seeing
if
it
makes
sense
to
people.
One
of
the
other
things
that's
really
interesting
here
is
that
one
of
those
adls
most
of
those
adls
will
have
a
reader
and
a
writer's
side,
and
that
last
one
won't.
B
A
Thanks,
that's
really
cool
because
yeah,
so
I
I
haven't
expected
expected
it
to
be
so
difficult
because,
as
I
mentioned
in
the
other
meeting
that
I
also
thought
about
doing
this
as
my
next
step
in
the
like,
either
javascript
or
us,
to
trying
to
implement
unicef
as
we
won
as
adl
and
I
haven't
thought
it
would
be
that
difficult
or
like
or
like,
not
that
difficult
like
so
many
pieces.
Basically,
so
I
thought.
B
A
Cool
next
is
scott,
hey,
real
sorry.
C
One
of
the
places
where
we're
hoping
to
expose
this
ipld
prime
in
ipfs,
and
yet
the
benefits
of
all
of
this
work
that
we've
been
doing
over
the
last
few
weeks,
is
that
there
is
a
set
of
dag
commands
that
interact
with
ipld
gag
objects
and
previously
have
interacted
with
dag
format,
objects,
and
we
want
to
allow
them
to
interact
with
ipld
prime
dag
objects
now
instead
and
so
we're
starting
to
look
at
how
that
api
gets
brought
up
to.
Prime
somehow.
C
C
C
Yet
I
submitted
a
pr
to
extend
the
dag
json
codec
to
also
support
the
non-dag
variant
by
just
ignoring
when
there's
a
link
and
making
that
just
the
normal
json,
which
I
think
is
what
the
decoder
needs.
C
A
Cool
all
right,
I
I
have
one
comment,
because
I'm
also
kind
of
in
favor
of
having
not
a
central
table
but
just
having,
like
implementations,
just
defining
their
identifiers
they
need,
although
they
of
course,
should
be
correct
like,
but
it's
still
like
it's
like,
I
think
it's
like
for
or
like
at
least
I
mean
for
our
libraries.
I
guess
it
makes
sense
to
use
just
a
conical
table,
but
I
think
so
I
would
say
like
from,
if
you
think,
about
ipld
or
bigger
things
as
if
you
use
it
from
an
application.
A
I
think
it
should
be
like
the
libraries
should
be
built
in
a
way
that
people
could
also
just
define
their
own
their
own,
constant,
somewhere
and
still
use
their
stuff
without
importing
like
a
full
table.
So
we've
kind
of
like
make
this
change
in
javascript
a
bit
like
this.
It
is
possible
just
a
note
for
in
case
anyone
else
implements.
C
Right,
I
guess
just
in
terms
of
the
way
multi-codec
or
multi-format
is
implemented
in
go.
There
is
a
registry
of
known
codecs
and
their
associated
names,
which
has
a
list
of
known
codecs
and
names
pre-registered
in
it
and
separately
from
this
ipld
prime
has
a
multi-codec
registry
of
known,
encoders
and
decoders,
and
so
it's
possible
for
a
plug-in
that
gets
included
with
ipfs,
to
define
either
additional
encoder
decoders
for
known
codecs
or
to
define
a
whole
new
named
codec
and
associated
encoders
and
decoders.
So
it
is
somewhat
piecemeal
in
that
sense.
C
But
if
you're
going
to
use
one
of
the
ones
that
is
in
that
table,
you
probably
should
use
the
same
names
and
codes
that
are
in
that
table
right.
So
the
reason
that
this
is
weird
is
because
the
table
defines
as
sort
of
that
core
set
of
known
ones,
that
there
is
something
called
deg.json,
that's
at
ox-129
and
there's
a
different
one
called
json,
not
dag,
that
is
at
ox200
and
then
in
the
ipfs
command
line.
They
have
their
own
little
map.
C
A
A
Nope
then
it
was
again
a
quick
one.
So
thanks
everyone
for
attending
and
see
you
all
next
week,
goodbye
everyone.