►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2021-04-12
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
B
A
It's
april
the
12th
2021,
and
as
every
week
we
go
over
the
stuff
that
yeah
people
worked
on
and
have
or
haven't,
actually
worked
on,
but
have
news
from
other
teams
and
share
it
here
I
start
with
myself,
so
I
was
still
working
on
this
js
multi
formats
in
js
ipfs
thing,
it's
still
the
same,
pull
requests
and
the
plan
looks
like
this,
so
the
problem
or
like
one
big
thing
is
also
that
in
js
ipfs
we
also
have
plenty
of
examples
and
they
use
some
other
bundler
for
their
stuff
and
with
the
whole
effort
of
getting
the
js
multi-format
stuff
in
is
also
combined
with
a
problem
that
js
multi-formats
is
written
as
es6
modules
and
combining
es6
modules,
with
common
js
modules
in
javascript
is
already
difficult
and
it
gets
even
more
difficult
if
you
have
typescript
typing
in
them.
A
Yeah
the
problems
are
all
over
the
place,
but
also
certainly
one
is
the
bundlers,
because
often
they
do
either
support
well
common
js
or
me6
modules,
and
so
on.
So
this
might
be
difficult,
and
so
my
pull
requests
are
probably
good
enough.
Not
all
tests
pass
yet,
but
it
should
be
possible
to
build
the
the
examples
and
run
the
examples,
so
we
could
at
least
try
out
if
this
whole
new
system
can
work
together
and
hopefully
the
result
will
be
that
it
works,
and
then
we
can
polish
those
pull
requests
again
and
yeah.
A
So
and
if
I
say
we
I
mean
the
others,
because
finally,
I'm
moving
full
time
off
to
the
other
team,
so
I
won't
do
javascript
iphone
these
stuff
anymore
and
also
the
maintenance
responsibilities.
I
have
are
moved
over
to
aching
brain
and
rod
and
we
will
do
it
just
like
on
an
ongoing
basis.
A
So
whenever
there
is
something
that
needs
to
release
that
I'm
responsible
for,
I
will
then
hand
over
the
maintainership
to
them
and
they
will
do
the
release
because
there's
basically
no
point
of
proactively
going
through
all
the
repositories
I
might
be
the
maintainer
of
because
there
are
plenty
and
there
might
be
even
ones
where
we
don't
release
the
next
few
years.
So
that's
the
approach
and
yeah
and
hopefully
those
two
pr's
will
eventually
be
merged.
A
We'll
see
other
news
which
probably
rod
would
have
talked
about
if
he
would
be
there
and
he
spent
time
on
chase
multi-formats
j
stack,
bb
and
js
x,
seabor,
making
them
compatible
with
this
whole
typescript
thing
and
commentaries,
and
me
six.
A
They
are
pr's
currently
and
I
think
they
look
good.
They
still
need
approval,
but
then
I
think
when
he's
back
and
those
will
be
merged
and
then
again,
the
pr
mentioned
previously
can
also
be
updated,
and
then
we
should
have
typing
properly
done
for
the
whole
new
js
multi-formats
stack
that
we
have.
B
Eric
okay,
I
get
to
be
a
little
bit
excited
this
week
after
some
doldrum
times,
because
I
found
some
tooling
that
I
have
wanted
to
find
for
the
longest
time
and
I'm
happy
with
it
and
we're
gonna
get
some
more
docs
and
specs
website
work.
For
me,
I
found
a
new
static
site
generator
tool
that
I'm
very
excited
about
that.
Has
it
just
checks
all
the
boxes
and
features
it
is
still
javascript
based?
So
we
can
do
all
sorts
of
extensions
in
there
like
we
can
bring
along
the
syntax.
B
B
B
I've
tried
eight
different
static
site
generators
to
the
degree
of
hands-on
trying
it
not
just
reading
about
it
but
built
the
demo.
Eight.
This
one
is
good,
I'm
so
happy
so
anyway,
so
I'm
gonna
be
doing
a
bunch
of
work
on
that.
My
dream
is
still
to
be
unifying
a
bunch
of
different
repos.
B
As
I
go
through
this
and
getting
more
of
this
content
in
one
place,
I
will
still
keep
things
organized
into
docs
directories
versus
specs
directories,
because
the
writing
style
and
the
audience
and
even
the
contribution
flows
might
be
rather
distinct
for
those
things,
but
I'm
gonna
get
them
in
one
repo
and
then
also
do
a
bunch
more
documentation
of
all
the
other
stuff
that
is
in
our
periphery,
like.
I
want
to
start
gathering
links
to
all
the
different
cool
tools
that
are
not
in
core
libraries
per
se,
but
like
are
in
our
ecosystem.
B
So
I'm
looking
forward
to
that-
and
I
will
also
warn
everyone
in
the
area
that
this
will
involve
me
chasing
people
about
merging
any
prs
that
are
in
the
specs
repos
or
the
docs
repos
or
anything
around
there,
because
I
want
to.
B
B
So
lots
of
people
got
lots
of
emails
about
that
from
github.
I
think,
and
I'm
gonna
keep
chasing
people
and
it's
a
darn
shame.
Rod
is
off
today
because
he
has
several
and
yeah
that's
mine.
My
big
excitement.
C
Cool
so
we're
continuing
sort
of
in
a
slower
way
to
land
the
remaining
things
that
need
to
happen
in
this
ipld
and
ipfs
work
stream,
and
in
doing
these
things
and
code
reviews
and
so
forth,
a
couple
things
that
came
up
as
interesting.
C
Now
that
we're
using
ipld
prime
codecs,
it
has
become
apparent
that
we
can
no
longer
do
this,
because
our
json
codec
does
not
actually
implement
the
part
of
the
dag
json
spec
in
which
you
can
have
bytes.
So
you
cannot
make
the
bytes
field
in
the
data
key
of
a
dagpv
thing,
and
so
it
then
complains
and
will
never
allow
you
to
represent
the
schema
that
one
could
turn
into
a
wpb
object.
C
It
would
be
nice
if
this
was
possible
still
upon
update
puppy
eyes,
okay,
so
that
was
the
request.
One
second
thing
that
that
I
want
to
note
that
we
ran
into
when
talking
with
the
dean
about
interfaces.
Is
we
have
selectors
in
ipld,
prime,
as
a
x
like
a
compiled
thing
that
that
has
a
data
representation?
That
is
a
node
and
then
the
from
the
node.
C
You
parse
this
lecture
and
you
get
a
selector
there's
a
reason
on
things
like
the
request
to
fetch
a
dag
based
on
this
lecture,
that
what
you
might
want
is
the
data
representation
of
it,
because
that
still
may
go
across
a
network
and
need
to
be
in
its
data
format
before
it
is
executed
and
turned
into
a
selector
like
you
may
need
the
data
representation
of
it.
C
But
one
thing
you'll
note
is:
when
you
do
that,
you
end
up
with
an
interface
where
it's
like
fetch
of
node,
comma
node
as
your
type
signature,
and
then
the
person
who
gets
the
type
signature
hint
is
like
which
one
is
the
selector
and
which
one
is
the
dag
root.
Node
that
I'm
doing,
because
these
are
the
same
types
and
so
question.
C
Go
data
transfer,
slash,
grab
sync
land
that
you're
receiving
a
bunch
of
blocks
right
now.
The
way
that
happens
is
it
puts
it
into
a
badger
data
store
and
then
at
the
end
it
runs
a
traversal
over
that
and
serializes
it
into
a
car
and
the
overhead
of
writing
it
once
into
badger
and
then
reading
it
all
again
and
putting
it
into
a
car
and
having
the
badger
not
clean
up
necessarily
has
led
to
complexity
and
people
being
somewhat
unhappy,
and
so
there
was
a
request
of.
C
But
I
did
a
first
pass
at
an
implementation
of
a
thing
that
will
also
support
put
by
appending
them
on
and
appending
to
a
insertion
sort
based
index
so
that
you
can
do
that.
And
then
you
can
get
a
single
car
and
carbs
at
the
end.
It
does
make
an
invalid
car
in
that
it
does
not
put
any
roots
in
the
header
unless
you
specify
them
in
advance,
which
is
so.
I
guess
you
can
make
a
valid
car,
but
you
can
also
make
an
invalid
car.
C
You
can
also
just
sort
of
put
blocks
that
aren't
referenced
anywhere,
so
that
could
be
bad.
You
can
also
put
them
in
some
weird
order
that
isn't
the
same
order
that
a
traversal
would
end
up
putting
them
in.
So
if
so,
it's
not
necessarily
going
to
hash
the
same
thing.
So
you
may
still
need
to
do
a
re
read
over
that
car
with
its
index
into
another
car.
C
If
you
want
to
make
sure
that
your
hashes
match
what
you
would
expect
for,
like
the
we
have
a
single
canonical
thing
that
the
state
ends,
it
sounds
like
the
current
go.
Data
transfer
does
receive
blocks
in
in
order,
and
so
you
could
directly
do
this
and
skip
the
additional
read
and
write,
but
you
might
want
to
at
least
verify
so
there's
there's
some
other
work
in
sort
of
how
you
use
this.
It
has
sharp
edges,
but
yeah
seemed
like
a
relevant
thing
to
do
on
cars.
C
There's
a
conversation
going
on
like
is
this
enough:
do
we
want
to
do
the
dar
based
thing
and
where
is
that
all
heading
or
car
v2
or
whatever
there
continues
to
be
some
conversation
on
cars?
I
think,
if
you're
interested
in
that
discussion,
raul
is
probably
going
to
continue
to
be
the
point
person.
A
A
Then
I
have
an
agenda
item
which
is
not
super
exciting
because
we've
talked
about
it
briefly
last
week,
but
I
wanted
to
make
it
official
that
so
we've
talked
about
if
we
should
make
this
meeting
really
so
we
skipped
last
week
if
we
should
do
this
meeting
every
two
weeks
only
so
I
now
would
like
to
ask
officially
like,
should
we
do
this
meeting
only
every
two
weeks,
as
we
don't
have
that
many
updates?
So
is
this
a
yes
okay?
A
B
I've
looked
at
that
pr
where
you
have
the
two
different
kinds
of
nodes
and
they're,
both
the
word
node
in
the
goeng
contract,
and
I
agree
that
that
is
confusing
and
sucks.
I
don't
know
what
we
should
do
about
it,
though
it's
kind
of
also
the
truth
of
the
matter
like
you've
got
these
two
data
model
trees
and
like.
C
Sort
of
unfortunate
I
mean
we
put
in.
B
Names
of
the
variables
and
that
helps
right
but,
like
the
the
golang
type
checker,
can't
really
do
anything
useful
to
help
you
either
because,
like
that's
a
that
selector
node
tree,
where
have
you
been
able
to
verify
this
right,
and
how
can
we
tell
the
compiler
about
it?
I.
C
Don't
think
I
want,
I
don't
think
I
care
I'm,
not
I'm
not
trying
to
get
rest
level
stack
typing
it's
much
more
for
the
programmer
who's
using
it
right
of
like
just
it's
very
clear
to
them,
which
order
to
put
the
arguments
when
they
call
this
method.
Like
that's
a
that's
a
thing
for
the
person
not
for
the.
B
High
overhead,
if
you
didn't
want
it
on
dec,
json
bytes,
so
yes,
there's
definitely
a
missing
feature
in
the
globally
prime
codec
implementation.
Here.
Were
you
able
to
narrow
down
whether
the
legacy
feature
in
ipfs
that
we're
trying
to
support?
C
A
A
A
B
I
I
think
that
we
should
just
force
that
decision
immediately
and
then
stick
with
it.
This
is
also
one
of
the
things
that's
currently
an
open
pr
in
the
specs
repo,
which
I
just
discovered
during
my
review,
of
which
things
I
need
to
chase
people
about
and
so
yeah.
There
are
now
multiple
reasons
why
I
want
that
to
be
decided
and
land.
A
A
A
What's
what
this
look
where
that
was
all
the
items
we
had?
I
guess
so
I
think
so
anything
else.
A
C
C
It
allows
I
made
I
I
should
I
don't
know
if
I
should
register
this
in
multi
codec
or
something,
but
I
I
use
a
first
byte
uvarium
to
select
what
type
of
format
it
is
because
I
tried
a
few
different
ones.
I
think
I
didn't
overlap
with
the
space
of
other
multi-things.
C
Like
you
can
serialize
that,
just
as
like
a
fixed
width,
if
you
know
that
all
of
your
sids
are
the
same
hash,
then
you
know,
then
you
can
just
say
great
for
this
file.
It's
going
to
be
like
32,
bytes
of
hash
and
then
8
bytes
of
offset,
and
now
you
can
stride
it
very
easily.
If
they're
different.
If
you've
got
multiple
types
of
hashes,
then
you
can't
do
that
of
course.
So
it's
got
a
sort
of
a
selector
at
the
very
beginning
of
like.
C
Is
this
one
where
you
can
do
the
striding
on,
or
is
this
just
like?
We
put
it
in
a
hash
map
and
we
call
it
gob
hash
on
it
and
it's
whatever
crazy
thing.
Golang
has
decided
to
represent
it
in
as
its
memory
or
is
it
so
like
I
yeah
there
were
a
few
different
ones.
I
tried
to
get
relative
size
and
performance.
A
Okay
and
is
the
yeah,
because
I
was
asking
because
like
when
I
did
some
indexing
stuff.
I
did,
for
example,
only
store
the
like
a
pre,
like
the
the
smallest
smallest,
not
common
prefix,
of
the
cads
of
the
file.
A
A
C
C
So,
if
you're,
if
you're,
trying
to
export
your
content,
discovery
side
things
of
like
what
is
on
this
node,
can
I
just
give
you
an
index
which
is
essentially
at
that
point
all
I
need
to
give
you
is
the
list
of
cids,
but
hey
I've
got
this
convenient
thing
already.
That
is
the
list
of
cids
and
then
some
ants,
but
you
don't
care
about
the
ants
but
hey.
This
is
basically
the
list
of
cids
that
you
care
about
so
depending
on
purpose.
Yes,
I
agree.
A
Yeah,
okay
yeah,
although
even
then
I'm
not
sure
if
anyway
yeah
it's
a
simple
discussion
but
yeah
it's,
but
it's
like
also
like
yeah.
You
can
certainly
add
those
things.
So
if
you
end
up
with
the
problem
of
the
index,
is
too
big?
You
can
of
course
do
something
about
it,
but
as
long
as
it's
not
a
problem,
it's
not
a
problem.