►
From YouTube: 🖧 IPLD Every-two-weeks Sync 🙌🏽 2021-05-24
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
B
A
So
in
no
particular
order,
I
guess
I'll
talk
a
little
bit
because
I
have
so
a
few
things
to
say.
I
have
the
same
joyful
report
of
working
on
documentation
website
content.
A
lot
in
the
last
couple
weeks,
there's
still
a
link
available
in
the
notes.
If
anyone
would
like
to
review
it,
I'm
hoping
to
launch
that
very
soon,
there's
just
a
few
more
things
that
I
want
to
get
ported
to
make
sure
that
they
don't
seem
to
disappear,
namely
some
of
the
specs
on
other
adls
that
are
not
widely
implemented.
A
But
still
the
specs
are
nice,
like
the
flexible
byte
layout.
I
need
to
get
that
into
the
new
docs,
but
I
think
they're
very
soon
ready
to
go.
So
if
anybody
has
red
flags
and
would
like
to
not
update
the
dns
entries
to
the
new
content,
it's
getting
to
be
time
to
like
speak
now
or
hold
your
piece
that
could
happen
in
the
next
week
or
so
internally
to
our
organization.
A
C
Cool,
I
can
go
next
so
as
a
bit
of
a
high
level
update
on
the
reflect
work.
So
I
did
get
all
the
tests
passing
about
a
week
ago.
So
that's
a
good
proof
that
it
actually
works.
But
it's
maybe
I
think
I
think
optimistically.
It's
about
two-thirds
of
the
way
there
in
terms
of
being
fully
complete
because
there's
quite
a
lot
of
to-do's,
especially
with
like
edge
cases
and
like
weird
methods
like
look
up,
look
path
by
segment
and
stuff
like
that.
C
So
there's
the
main
pr
which
has
gotten
quite
a
few
reviews.
So
I
think
it's
pretty
close
to
being
ready
to
merge.
I
know
it's
not
like
pretty
in
any
way.
There's
no
docs-
and
I
just
added
one
example
and
that's
pretty
much
it,
but
I
think
in
terms
of
like
the
first
chunk
of
code
that
we
can
merge,
it's
pretty
okay
and
then
the
next
thing
that
I'm
going
to
do
is
tests.
C
So
I
do
have
the
schema
django
tests
running,
but
they
needed
a
hack
and
the
better
version
of
that
hack
is
the
other
pr
that
I
posted,
which
is
the
deep
equal
ipld
api,
and
that
also
seems
to
be
pretty
close.
So
with
those
two
merged,
then
the
next
pr
is
going
to
be
using
both
of
those
to
run
all
the
schema.
C
Gen
go
tests
with
code
gen,
but
also
with
reflect
and
once
that's
in
then
I
will
start
chugging
away
at
add
more
tests
fix,
to-do's,
rinse
and
repeat
for
another,
probably
two
or
three
weeks
until
most
of
the
basic
stuff
is
covered,
and
then
the
trailing
20
of
to-do's
and
optimizations
and
so
on.
I
don't
think
are
going
to
be
urgent,
but
I
will
get
to
those
with
less
of
a
hurry.
I
guess
and
that's
as
far
as
the
update
goes
on
that
stuff,
any
questions,
any
comments.
C
Oh
and
in
terms
of
timing,
I
was
thinking
as
soon
as
I
have
the
basics
covered
and
decent
examples
and
okay
documentation.
I
think
that's
probably
good
enough
to
do
some
sort
of
hey.
This
is
a
thing
you
can
try
it
out.
If
you
want
with
npl
so
say,
assuming
all
the
stuff
gets
merged
this
week
say
end
of
next
week.
C
And
I'm
sure
somebody's
gonna
try
it
and
it's
gonna
panic
and
it's
gonna
blow
up
in
their
faces.
But
you
know
it's
just
gonna
happen
because
the
code
is
tricky,
but
I'm
also
looking
for
input
in
terms
of
like
how
the
api
should
look
like
in
the
end.
I'm
not
worrying
about
that
too
much.
Yet
because
I
haven't
I've
only
implemented
one
of
the
three
input
code
paths
so
far,
but
once
all
three
of
them
are
implemented,
I'm
gonna
be
looking
for.
Hey
is
this
intuitive?
C
Would
you
tweak
the
eight
the
signatures
anyway
and
so
on,
but
yeah
that's
pretty
much.
It.
C
And
yes,
I
will
send
something
that
I
mentioned
to
eric
earlier.
Is
that
I
will
actually
end
up
sending
that
pr
that,
for
that
api,
to
convert
an
ipld
node
into
like
a
basic
go
value
so
like
any
apld
map,
would
turn
into
a
go
map
and
so
on,
which
is
sort
of
like
the
reverse
of
qp
in
a
way
shouldn't
be
used
for
large
things.
But
quite
often
people
just
want
the
go
value
for
simple
things
like
hey.
I've
got
a
list
of
five
items
or,
like
I've
got
a
string.
C
I
just
want
the
string,
I
don't
care,
so
that
would
be
nice
and
the
one
question
for
that
would
be,
I
guess,
just
like
deep
equal.
It
shouldn't
return
errors.
It
should
just
panic
if
something
goes
wrong,
because
in
general
nothing
should
go
wrong.
C
A
A
I
think
this
would
also
be
the
the
inverse
of
fluent.reflect
method
right
now,
because
we've
got
that
thing
which
goes
from
arbitrary,
empty
interface
and
go
to
ipld
node,
with
lots
of
caveats.
Admittedly,
but.
A
I
don't
know
we
should
think
about
that
at
least
we're
starting
to
get
a
good
smattering
of
these
helper
methods
that
do
these.
These
useful
glowy
sorts
of
tasks-
and
it's
it's
unclear
to
me
where
they
should
go.
We
haven't
had
a
super
like
clear
and
consistent
line
for
if
they
go
in
the
ipld
main
package
or
the
fluent
package
or
one
of
the
other
places
we
should
think
about
where
we
want
to
put
that
line.
C
I
think
I
lean
slightly
towards
fluent
because
it
has
the
opposite
function
and
also
because
this
constructor
go
value
is
potentially
very
expensive.
Whereas
deep
equal
is
you
know
it
just
loops
over
things,
it
doesn't
construct.
Big
things
agree,
so
I
I
feel,
like
things
that
could
potentially
like
make
your
machine
go
out
of
memory
should
be
influenced
not
in
ipld.
C
Yeah!
That's
it
for
me.
B
I
don't
think
I
have
too
much,
I
guess
at
the
end
of
last
week
eric
and
I
had
a
discussion
about
enumeration
of
multicodex
and
reached
a
tentative
agreement
on
that
being
acceptable
in
some
way.
I
owe
you
a
pr
yes
cool
and
once
that
happens,
we
will
try
to
finish
the
ipld
in
ipfs.
B
It
sounds
like
there
is
also
work,
starting
in
ipfs
that
I
just
got
pointed
to
where
they
would
like
to
have
the
ability
to
get
individual
ipld
items
out
of
the
gateway
on
a
different
interface
or
api,
and
they
have
started
coding
that,
against
the
current
format
thing-
and
I
am
now
again
motivated
to
try
and
land
our
prime
stuff
so
that
that
doesn't
happen.
So
I'm
going
to
try
and
push
a
little
bit
harder
to
have
the
rest
of
this
ready
to
go.
B
I
think
that's
the
main
thing
there.
I
guess
the
other
one
that
is
relevant
to
this
forum
is
that
we
may
take
some
well.
I
guess
there's
a
couple
things
actually
so
so,
first
one
is
car,
so
we
have
a
new
member
on
the
data
systems.
B
Team
massey,
who
perhaps
with
daniel
over
the
next
couple
weeks,
will
take
a
bit
of
time
to
try
and
work
on
gokar
support
for
a
car
v2
variant,
which
would
be
the
current
car
v1,
but
with
an
index
after
it,
and
so
this
is
trying
to
make
a
as
minimal
as
possible
start
towards
an
upgrade
path,
namely,
it
would
be
sure
great
if,
when
you
saw
a
car
file
at
the
beginning
of
it
was
a
header
that
allowed
you
to
do
version
discrimination
and
a
library
that
could
load
both
the
current
car
and
a
subsequent
version
of
car.
B
We're
not
going
to
worry
about
the
features
that
we
might
want
in
car,
but
just
that
versioning
and
then
the
potential
support
of
being
able
to
open
a
car
into
a
read-only
data
store
that
you
can
do
read-only
access
to.
We
have
these
components,
but
linking
them
together
into
a
library
that
can
do
the
versioning
side
is
likely
a
useful
building
block
to
extend
so
that
we
may
see
some
work
on
that,
the
other
one
that
is
in
tangential
to
ipfs
or
ipld
space.
B
I
hacked
together
last
week
with
hannah's
help
a
library
called
legs
that
syncs
an
ipld
dag
between
a
publisher
and
a
subscriber.
It
does
the
like
work.
B
And
it
seems
to
work,
it
uses
all
of
these
various
technologies,
but
you
can
have
a
dag
and
then
you
can
add
things
and
have
a
new
head,
and
then
you
say
I
have
a
new
head,
it's
this
sid
and
then
on
the
other
side.
At
some
point
it
gets
an
alert
that
says
there's
a
new
head
and
it
gives
you
the
same
sit
and
it's
filled
out
and
sync,
the
data
storage.
I
have
those
new
items
and
if
the
large
subset
was
there
before
it
doesn't
retransfer
it.
B
So
it's
nice
in
that
subset.
It's
not
doing
that
much
with
iplt.
Specifically
it's
basically
the
go
data
transfer
layer
that
it's
thinking
rather
than
that.
A
Tangentially
related
to
cars.
If
anybody
is
thinking
about
test
fixtures,
I
would
not
mind
picking
up
that
discussion
again
and
trying
to
get
it
somewhere
too.
I
remember
doing
a
little
bit
of
a
survey
of
like
what
are
good
language
agnostic
test
fixture
formats
and
finding
roughly
that
everything
sucks
as
usual
in
the
computer
industry.
A
I
would
I'd
kind
of
like
to
pick
that
up
again.
I
was
thinking
about
doing
some
test
fixture
stuff
and
it
would
just
be
nice
to
have
a
format.
That's
good
for
this.
I
think
everything
that
I
looked
at
the
last
time.
I
reviewed
this.
We
had
some
interesting
candidates,
but
some
of
the
most
interesting
ones
also
still
had
some
issues
where
they
would
confuse
the
data
plane
and
the
control
plane
sometimes
like
you
could
have
a
piece
of
fixture
content
which
would
get
confused
for
a
file
name
header
and
create
a
different
file.
A
B
Cool
there's
also,
I
think,
starting
to
be
work
on
the
javascript
side
of
car
support.
So
one
thing
we
might
get
in
trying
to
suddenly
push
cigar
or
v2
as
soon
as
possible.
Is
that
that
work
that
happens
is
versionable
instead
of
just
a
car
v1
support,
and
then
someone
has
to
go
in
later
and
support
carvy
jews
and
end
up
only
half
supported.
That
seems
like
worse
than
if
they
just
do
one
development
push
and
get
to
car
v2
directly
possible,
we'll
see.
C
A
D
A
Hypothetical
audience
on
youtube.
There
is
an
exploration
report
about
this,
also
where
there's
slightly
more
complete
list
of
requirements
and
desires
in
it,
but
yeah
most
of
the
formats
we've
looked
at
seem
to
have
support
in
like
one
or
two
languages,
also
as
opposed
to
like
approximately
all
the
languages.
I
don't
know
why
this
is.
It
seems
like
we
have
a
common
yeah,
but
okay,
so
you
guys
have
seen
that
we
have
json
fixtures
for
the
selectors
tests
right
and
they're
great
except
the
first
time
any
human
being
looks
at
them.