►
From YouTube: 🖧 IPLD Every-two-weeks Sync 🙌🏽 2021-07-05
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
ipld
sync
meeting:
it's
exit
full
screen,
it's
july,
the
5th
at
2021
and
as
every
two
weeks
we
go
over
the
stuff
that
people
worked
on
ipali
and
then
discuss
any
open
agenda
items.
A
I
can't
start
with
myself
because
I
haven't
done
any
ipad.
You
work
so
next
on
my
list
is.
B
Cool,
so
I
don't
have
that
much
to
report,
because
I
did
spend
the
majority
of
the
last
couple
of
weeks
working
on
car
v2,
but
I
can
give
up
some
high
level
overview
of
that.
Essentially,
we
have
we're
this
week,
we're
finishing
the
api.
Most
of
the
major
features
are
there
and
by
major
features
I
mean
what
will
worked
on
in
the
separate
two
repos,
we're
kind
of
just
putting
things
together
here.
B
Something
of
note
in
the
ipld
sense
is
that
I
worked
on
an
api
and
goes
the
id
called
cid
from
reader,
because
there's
an
api
currently
in
master
call
cd
from
bytes
and
it
only
consumes
the
amount
of
bytes,
that's
that
are
necessary
for
the
cid,
but
it
only
works
if
you
have
the
buffer
already
in
memory.
If
you
have
a
reader-
and
you
don't
know
how
many
bytes
there
are
in
the
reader,
you
couldn't
really
do
that
for
now
until
now,
so
there's
a
pull
request
open.
B
If
anybody
wants
to
review
it
and
also
as
an
fyi-
and
I
meant
this
for
rod
mainly-
but
I
guess
I'll
I'll
ping
I'll
ping
him
on
this
afterwards,
but
it
turns
out
that
filecoin
has
been
using
a
commit
off
of
gokar
in
a
in
some
dead
branch
that
doesn't
exist
anymore.
That
was
forked
off
like
a
year
ago
and
what
that
branch,
what
that
commit
did
was
it
allowed?
B
No
null
padding,
I.e,
zero
bytes
at
the
end
of
a
curvy
one
and
the
reader
essentially
ignored
those,
and
we
do
have
a
similar
thing
in
carvey
too.
It
allows
for
padding
after
the
carvy
one
and
before
the
index,
but
it's
different
when
you,
you
know
when
you
read
a
car
v1,
it
expects
that
to
end
with
the
of
it
doesn't
do
anything
with
no
bikes,
but
the
spec
does.
This
does
leave
that
somewhat
open
as
a
door,
because
you
know
it's
a
sequence
of
frames.
B
So
what
do
you
do
when
you
reach
a
copy?
One
frame,
that's
length:
zero.
Do
you
skip
it?
Do
you
assume
that
that's
the
of
it's
sort
of
up
from
interpretation,
so
we
we
agreed
that
the
implementation
should
skip
those
and
just
keep
on
parsing,
but
in
that
issue
I
outlined
that.
I
think
we
should
change
the
cardio
and
spec
to
essentially
say
a
decoder
once
it
encounters.
B
A
null
frame
is
free
to
assume
that
that's
an
aof
to
stop
parsing,
because
that
would
allow
us
to
essentially
be
efficient,
because
right
now
we
have
to
keep
parsing
every
single
byte
as
a
var
end,
which
is
really
slow.
If
we
decide
not
to
do
that,
then
the
plan
b
is
to
take
a
shortcut
like
read.
You
know
4k
nulls
at
a
time
and
just
quickly
skip
over
those
assuming
that
there's
no
non-zero
bytes,
but
if
we
can
avoid
that,
that
would
be
nice.
It's
just
a
matter
of
the
spec.
C
It's
I
think,
it's
very
fair
to
say
that
once
you
start
hitting
these
null
bytes
you're
not
going
to
put
valid
cids
after
it
and
that
when
you're
encoding
that
you
shouldn't
be
actually
interleaving
an
encoded
null
sid
with
your
real
data
that
can
go
at
the
end.
If
you
need
to
reference
that
somehow,
but.
B
Yeah,
I
agree.
I
essentially
wonder.
B
Yeah
essentially
like
the
addition
to
the
spec
that
I
want
to
do
should
be
as
small
as
possible
and
I
think
it
should
be
like
you
can
have
some
padding,
but
as
soon
as
the
reader
gets
an
old
bite,
you
know
that's
where
it
ends
and
aside
from
that,
I've
been
sort
of
putting
the
ipld
reflection
in
bind
node
to
the
side
for
the
last
couple
of
weeks,
just
because
of
the
curve
v2
work,
but
it's
still
in
the
same
state
as
I
reported
last
time,
which
is
that
I
was
working
on
inferring
schemas
from
go
types
and
that's
still
a
work
in
progress.
B
A
Thanks,
although
I
haven't
done
any
work
on
iprd,
it
might
still
be
interesting
for
the
call
that
there
is
a
bit
of
development
going
on
in
go
store
the
hash.
So,
if
you're
interested
in
storing
things
by
cid,
basically
ipdata
data,
it
might
be
interesting
to
look
at
because
it
now
has
support
for
also
updates
and
deletes
which
it
previously
didn't
have
yeah.
C
Else,
I
think
that's
a
lot
of
the
active
work.
I'm
aware
of.
I
guess
the
other
thing
that
I
threw
up
randomly
as
a
very
early
attempt
at
understanding
sort
of.
C
We
have
a
lot
of
data
that
involves
adls.
All
of
our
ipfs
data
is
actually
understood
through
a
unix
fps
adl
that
runs
on
top
of
the
sort
of
underlying
dag
pp
baseline,
that
that
is
how
those
sids
are
actually
encoded
and
in
filocoin
we're
making
a
lot
of
use
of
hamps
where
we
can
sharper
large
maps
of
data
and
we're
expecting.
C
I
think
that
we
need
some
sort
of
recommendation
of
how
to
pack
data
meaningfully,
as
we
start
having
these
large
32-bit
chunks
of
data,
and
I
think
we
expect
that
you
know
in
terms
of
things
that
we
have
seen
libraries
and
support
and
tooling
for
hamps
and
or
the
unix
of
s.
Things
are
likely
going
to
persist
for
a
while
and
so
it'd
be
really
nice.
C
If
we
had
useful
ways
to
do
selectors
that
worked
with
them-
and
that
seems
like,
if
we
sort
of
don't
do
anything
special
that
may
be
a
ways
off,
but
one
thing
you
could
imagine
is
in
a
selector.
You
could,
at
the
point
that
you're
at
a
node
say
interpret
this
node
as
an
adl
and
we
can
make
a
registered
map,
as
we
have
done
with
many
other
things
of
known
adls
that
we
expect
there
to
be
implementations
of,
and
then
we
can
say
we
expect.
C
So
I'm
trying
to
think
because,
because
adding
that
to
the
selector
implementation
looks
like
it
won't
actually
be
too
too
much
work
in
on
first
glance,
I'm
trying
to
understand
a
if
there's
things
that
cause
us
to
be
reluctant
to
do
this.
Does
it
cause
us
to
feel
like
we're,
shooting
ourselves
in
the
foot?
Are
there
issues
with
potential?
C
I
don't
know
complexity
or
like
this
leads
to
some
sort
of
weird
unbounded
application
of
adls
in
a
way
that
we
can't
like
back
out
of
it
or
end
up
doing
more
work
than
we
were
anticipating
in
evaluating
selectors,
that
we
get
scared
of
the
the
other
one
that
I
thought
I
was
thinking
of,
as
I
started
going
here
is,
let's
say:
you've
got
data
that
is
in
a
codec
that
you
don't
understand
necessarily
or
in
a
schema
that
you
don't
understand.
C
So
not,
I
guess
not
a
codec
but
a
schema
per
se.
So
you
know
one
thing
we
could
imagine
doing
as
our
path
to
allowing
a
entity
to
do
a
selection
over
data
where
some
of
it
is
in
schemas.
They
don't
understand.
Is
the
selector
could
point
in
sort
of
a
similar
way
to
a
sid,
that
is,
data
of
the
ipld
schema?
C
And
then,
when
you
get
told
use
this
type
of
node,
you
load
the
ipld
schema
and
parse
it
into
a
schema
which
we
need.
Our
schema
schema
to
be
finished,
but
we
could
then
do
and
then
we
could
use
binode
to
actually
get
the
schema
generated
off
of
that,
and
then
we
could
use
that
as
the
thing
that
we
use
as
our
node
assembler
to
pull
into.
C
So
you
could
potentially
have
a
not
needing
full
sort
of
vms
or
something
totally
crazy
and
I
think
relatively
concrete
path
where
you
could
allow
data
that's
stored
in
arbitrary
codecs
to
end
up
being
a
basis
for
selection.
Over
with
the
like
caveat
that
you
would
have
to
sort
of
note
it
in
the
selectors.
C
So
you
end
up
with
longer
selectors
and
overloaded
selectors
a
little
bit,
but
there's,
I
think
you
know
the
potential
if
we
give
up
on
the
selectors,
are
agnostic
to
all
these
other
things
that
that
can
be
a
place
that
we
can
provide
some
hints
and
potentially
get
a
lot
of
the
functionality
that
we've
been
hoping
for,
but
sort
of
see
as
a
long
way
off
to
pull
up
to
be
things
that
we
can
start
doing.
Much
sooner.
B
B
You
know
that
thing
where
you
like,
you
start
talking
and
then
I
have
a
thought
about
it.
So
I
start
thinking
to
myself
and
then
I
noticed
that
I
haven't
been
listening
to
you
for
30
seconds,
so
I
could
have
lost
for
the
rest
of
the,
but
I
was
thinking
something
along
the
lines
of
what
peter
was
saying,
which
is
that
hand.
B
Sorry
adls
are
not
really
a
canonical
central
registry
of
behavior
and
if
you
look
at,
for
example,
just
filecoin,
they
have
the
hempt,
but
they
have
a
hand
that
behaves
in
one
way
with
some
parameters
in
the
older
actors
version.
I
guess
you
would
call
it
and
then
the
newer
one
with
different
parameters.
So
how
would
you
represent
all
of
that
with
just
you
know,
canonical
strings.
C
That's
a
great
question.
I
my
first
response
is
we
say
the
ibl
de-hamped
in
so
so
there's
two
things
we're
doing
this
only
for
reading
in
the
context
of
selectors,
and
I
think
you
don't
actually
need
the
things
like
bit
width
on
the
read-only
thing,
because
it's
actually
encoded
in
the
notes.
C
C
So
that
was
so,
I
that
was
going
to
be
my
initial
proposal
was,
I
think
there
is
a
version
of
hampton
where
you
can
just
say
that,
and
the
root
note
of
the
hand
will
have
enough
to
do
the
hashing
properly
and,
if
that's
true,
then
we'd
say
that's
the
one
that
we're
going
to
standardize
and
because
this
is
only
going
to
apply
to
data
like
stored,
rather
so
like
backwards
compatibility
to
change
state,
that's
not
actually
stored
as
deals.
C
C
And
then
you
know,
I
know
that
some
aggregators
stored
a
bunch
of
files
either
with
a
hampton
or
with
unix
of
s,
and
I
want
to
logically
say
give
me
file
named
x
out
of
this
unix
fs
directory,
or
I
want
to
get.
You
know
the
item
keyed,
whatever
out
of
the
hamp,
that
the
guy
stored,
without
necessarily
retaining
the
top
level
information
up
it
was
stored
at
you,
know,
child
five
of
child
seven
of
child
three
and
having
to
store
the
metadata
of
that
sort
of.
I
don't
know
not
pertinent
to
my
interests.
D
So
my
my
reaction
to
this
is
that,
like
I,
I
actually
jumped
to
what
had
implemented
as
her
like
you
know:
proto
unix
of
sedl,
which
effectively
like
it
didn't
support,
hands
originally
and
effectively.
D
It
was
a
very
specialized
hard
coded
select
like
jq
level,
select
over
gomarklet,
and
it
feels
to
me
that
jumping
straight
into
atls
and
not
implementing
the
simpler
thing,
which
is
the
select
which
is
actually
you
know
universal
and
agnostic
like
I
want
a
thing
that
looks
like
this
other
thing,
and
then
I
want
to
continue
like
literally
the
way
g2
doesn't.
D
We
are
like
going
to
like
not
fill
out
the
the
best
app
so
to
speak
curve
because,
like
there
is
going
to
be
a
lot
of
stuff
that
can
be
done.
That
happens
to
be
just
weird
enough,
like
somebody
maybe
did
stuff
with
some.
I
don't
know
like
like,
like
in
my
in
my
experience.
I
I
I've
actually
never
run
into
hands,
and
I,
like.
D
Explicitly
never
produce
sharded
directories.
I
basically,
I
have
no
problem
saying
like
oh,
this
thing
is
just
too
big.
We
have
limitations
just
like,
like
there
are
file
systems
that
you
have
to
give
six,
you
know
enters
per
directory
and
that's
that
and
that's
fine,
and
if
I
cannot
like
represent
it,
I'm
just
not
going
to
represent
I'm
going
to
do
some
work
out
or
something
like
that
and
in
general,
in
order
to
get
the
director
into
into
hamp
territory.
D
You
are
looking
at
like
I,
I
don't
remember
exactly
numbers,
but
you
know
something
like
on
the
order
of
10
000
entries
or
something
like
that.
C
Cool
I
mean
if
this
isn't
a
real
problem,
that
you're
running
up
against
great,
less
less
work
to
try
and
pull
up,
but
we
can
revisit
when
we
start
getting
more
complaints.
I
guess
or
more
concerned
consternation
around
this.
D
Like
the
the
reason
that
my
you
know,
retrieval
plc
works
the
way
it
works
and
and
like
after
I
presented
on
the
google
markets
thing
they
were
watching
builders
thing
I
got
like
four
or
five
questions
like
oh:
when
will
it
do
stuff
by
name
but
I'm
like?
D
Well,
we
can't
do
stuff
by
name
because
we
don't
have
selects,
but
the
only
reason
I'm
doing
it
with
integers
is
because
we
have
actually
have
only
passing
selected
go
here
and
then
go
here,
and
I
go
here
and
I
don't
know
like
from
my
perspective.
An
adl
is
like
overkill
for
what
is
actually
like.
The
immediate
need.
B
Daniel
I'm
thinking
to
myself-
and
this
might
be
like
too
generic,
but
you
know,
will
was
talking
about
things
that
you
get
from
miners
and
then
they're
useful
when
you
use
them
through
an
adl
not
directly
through
the
data
model.
C
B
C
Only
thing
beyond
I
don't
know
the
I
have
we
haven't
done
anything
for
ipld
in
ipfs
in
the
last
couple
weeks,
but
that
should
start
up
again
fairly
soon
optimistically.
C
Now
that
ipfs.9
is
shipped
finally
that
that
was
sort
of
what
we
were
waiting
for.
We
now
can
get
some
of
dean's
time
back
and
use
that
to
get
the
ipld
prime
stuff
through
so
that's
exciting.
I
did
I'm
sort
of
like
paging
back
in
since
the
last
time.
This
call
happened.
C
I
made
a
variant
of
the
dag
json
codec,
because
there
was
a
thing
I
wanted
that
it
wouldn't
do,
and
that
was
I
wanted
to
dump
json
for
debugging
purposes
and,
namely
I
had
roughly
a
three
level
deep,
ipld
node
that
had
a
link
to
another
ipld
node.
I
just
wanted
that
whole
dag
as
a
json
thing,
and
so
if
I
was
to
dump
it
with
dag
json,
I
would
just
get
a
sid
to
the
secondary
node
and
I
wouldn't
get
the
whole
dag.
C
And
so
I
made
a
variant
called
dump
json,
which
is
exactly
the
same
thing
as
dag
json,
except
it
does
not
require
a
sid
link.
As
the
like
explicit
type
cast,
I
will
only
deal
with
links
called
sid
link,
which
has
been
somehow
hard-coded
into
the
dag
json
codec,
but
instead
it
will
take
any
link
and
it
will
just
print
out
what
the
link
tells
it
to.
And
then
I
made
an
immediate
link,
which
is
a
link
that
contains
the
node
that
it
points
to
and
then
just
recurses
on
it.
C
So
it
does
an
inline
printing
of
whatever
the
link
is
to,
and
that's
just
a
different
link
system
right,
like
a
bunch
of
the
pieces
of
ipld.
Prime
machinery
actually
do
work
reasonably
well
in
allowing
for
this
sort
of
adaptation.
C
B
Well,
could
you
do
this
by
wrapping
your,
so
I
assume
you
have
a
node
that
you're
printing
with
this?
Can
you
not
wrap
it
in?
Could
we
not
have
a
wrapper
note?
That's
that's
like
flat
link,
flattener
or
something
like
that,
and
it
just
resolves
the
links
and
instead
of
having
cids
it
just
has
the
children
nodes
directly
in
there.
B
B
C
Well,
my
hope
was
this
thing.
Also
without
much
work
could
work
for
most
codecs
in
particular.
C
The
thing
that
I
ended
up
deciding
that
I
wanted
was
instead
of
json,
currently
does
a
type
assert
on
links
and,
if
they're
a
sid
link,
it
does
the
special
case
of
printing
out
the
like
open
map,
key
string,
slash
sid
as
the
string
version
of
that
close
map
key
and
instead
I
said
I
made
an
interface
for
links
and
I
try
and
say
is
this
a
link?
That
is
a
that
follows
this
interface
and
the
interface
that
I
thought
was
actually
reasonable.
C
Here
is
that
we
should
parallel
all
of
our
other
nodes
and
ask
for.
Can
I
ask
for
the
representation
of
this
link
and
so
then
a
sid
link?
The
representation
would
be
a
map
whose
key
is
a
is
the
string
slashed
and
the
value
is
the
string
of
the
sid,
but
I
can
have
a
different
type
of
link
system
where
I
have
a
different
link
that
has
a
different
representation.
C
And
so
if
we
say
links
have
a
representation
that
might
also,
I
don't
know,
yeah
might
trip
us
up
in
new
and
exciting
ways
or
it
might
be
great.
B
A
No,
then
I
closed
the
meeting
and
yeah.
So
there
will
be
another
ip
meeting
in
two
weeks
without
me,
but
probably
with
other
people,
so
goodbye.