►
From YouTube: 🖧 IPLD Every-two-weeks Sync 🙌🏽 2021-10-11
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
B
Okay,
so
I've
got
some
fun
news
from
the
golang
worlds.
I've
I'll
put
the
bigger
thing
first,
I
guess
I've
been
kicking
around
on
making
a
cli
tool
for
a
while.
This
is
something
that
you
can
now
see
and
follow
along
on
the
progress,
even
if
it's
early,
because
it
has
got
a
new
github
repo,
it's
in
github.com
ipld,
slash,
go
dash,
ipld
tool,
a
more
creative
name,
maybe
coming
in
the
future,
but
naming
is,
as
everyone
knows
hard.
So
the
aim
of
this
is
to
make
a
the
easiest
way
to
explain.
B
It
is
if
you
know
what
jq
is
trying
to
do
that.
I
want
to
create
a
jq-like
sort
of
tool,
something
that
brings
joy,
something
that
you
can
use
in
a
playful
exploratory
way
in
in
your
show
or
some
environment
like
that.
Maybe
we'll
give
it
additional
like
give
it
a
rest
api
in
the
future.
I
don't
know
for.
A
B
But
it's
coming
along
pretty
slowly
because
I'm
dragging
other
features
out
of
the
go
libraries,
as
I
suddenly
like
directly
encounter
the
need.
So
it's
going
slowly
but
it's
good
and
that
it's
driving
other
work
as
well.
B
B
First,
in
glad,
pld
prime,
we
have
this
concept
called
link
system
which
gives
you
high
level
methods
like
load
and
store
where
you
take
a
node
and
a
link
prototype
which
basically
says
what
multicodec
to
use,
what
multihash
and
stuff,
and
then
it
does
the
thing,
and
you
can
configure
these
using
some
callbacks
called
like
block,
read,
opener
and
block
right
opener
and
they
sort
of
worked,
and
it
was
sort
of
fine,
but
nothing
implemented
that
interface
directly.
It
was
very
much
not
batteries
included.
B
You
really
had
to
bring
your
own
and
none
of
the
other
stuff
in
our
ecosystem,
historically,
really
like
fit
together
with
that.
So
it
was
not
fun.
The
amount
of
like
duct
tape
you
had
to
roll
was
like
was
not
fun
and
also
because
those
interfaces
used
a
couple
of
concrete
types
from
go:
ipld,
prime,
you
couldn't
implement
them
without
importing
part
of
that
repo,
which
was
just
like
you
know
it
was
possible,
but
it
wasn't
fun.
B
B
The
one
that
seems
to
me
was
the
most
important
was
called
go
dash
datastore
from
the
ipfs
repo
group
on
github.
That
was
the
thing
that
that
actually
mattered,
that
people
would
actually
implement.
B
Flatfest
file
store
the
badger
file
store
and
all
those
other
things.
Those
were
all
implementing
the
go.
Data
store
apis,
so
those
apis.
Well,
they
showed
their
age.
They
were
written
a
really
long
time
ago
in
go
live
terms
like
they
predate
the
invention
of
this
thing
called
context
which
is
just
ubiquitous
in
golang
now,
and
if
you
have
an
api
that
doesn't
use
it
you're,
basically
doing
it
wrong
at.
C
B
Point
and
a
bunch
of
other
more
detailed
issues
that
I've
written
up
in
a
pr-
and
I
won't
go
through
in
real
time,
but
there's
like
14
things
that
I've
been
able
to
improve
on
since
then.
So
now
we
have
oh,
the
other
problem
with
the
old
go.
Data
store
was
similar
to
what
I
accidentally
did
in
the
last
round,
pld
prime
stuff,
which
was
it
used
a
couple
of
very
concrete
types.
So
if
you
wanted
to
implement
it,
you
had
to
like
touch
this
dependency
tree
and
you
could
not
escape
it.
B
So
one
of
the
big
things
I'm
trying
to
fix
now
in
this
new
api
is
the
new
api
can
be
implemented
using
only
going
standard
library
types,
so
there's
no
dependency
tangles.
It
should
be
easy
to
implement.
The
whole
thing
is
designed
to
be
feature
detection
heavy.
So
we
can
have
the
most
basic
features,
be
the
core
set,
so
you
can
implement
it
easily
and
then
we'll
be
able
to
extend
things
from
there.
B
B
Included
bridges
to
all
this
stuff
now
for
the
first
time,
so
if,
if
you're,
some
downstream
user,
who
doesn't
care
about
any
of
the
architectural
things,
I
just
said
still
good
news:
there's
actually
batteries
included
for
bridging
stuff
together
this
time.
So
if
you
have
go,
data
store
code
from
who
knows
how
many
years
ago-
and
you
want
to
bridge
it
into
the
new
storage
system-
that's
a
one-liner
now!
Finally,
so
hopefully
this
is
good
reviews
welcome,
link
in
doc.
D
It's
my
my
time
has
been
largely
a
lot
of
time
spent
in
lotus,
far
coin
with
car
and
selector
work,
there's
a
release
coming
out
and
there's
a
lot
of
stuff
that
touches
selectors
and
cars
and
stuff
in
there
very
interesting
work,
probably
worth
discussing
more
at
some
point,
but
there's
more
to
do
there,
but
yeah
anyway,
I
have
been
trying
to
get
deeper
into
graphsync,
as
chris
may
be
interested
just
because
we've
really
got
one
person
that
knows
all
of
graph
sync
and
it
doesn't
really
scale.
D
So
hannah
has
got
a
lot
of
other
things
to
do,
and
but
graphs
keeps
on
being
a
very
needy
child,
so
trying
to
be
useful.
There
get
my
head
around
it
and
so
chewing
off
a
couple
of
sort
of
lower
risk,
prs
issues
to
do
to
learn
it.
While
I'm
going
also,
you
know
really
having
to
exercise
my
go
muscles,
which
are
not
very
strong,
so
also
doing
a
learning.
D
A
lot
of
learning
that
way
too,
because
there's
a
lot
of
advanced
go
in
in
graph
sync,
a
lot
of
heavy
go
routines,
a
lot
of
heavy
channel
usage,
custom
memory
management,
the
whole
lot.
So
it's
it's
probably
a
good
code
base
to
actually
learn
more
advanced.
Go
from
so
and
I
do
enjoy
hannah's
code.
D
So
it's
good,
but
very
taxing,
which
is
makes
it
interesting
that
now,
I'm
back
on
javascript
this
week
doing
updating
the
dag
api
in
the
js
ipfs
stack,
which
is
pretty
critical
in
the
http
client,
which
a
lot
of
people
use
to
talk
to
a
go
back
end.
D
It
really
updated
that
stack
to
have
to
see
ipld
code
and
rpl
codex
and
ipl
data
in
the
way
that
we,
as
an
ipld
team,
see
it
rather
than
this
funky
in-between
place
of
of
not
I
like
it
like
sort
of
at
the
ancient
ipld
idea,
pre-ipld,
and
so
the
dagger
api
and
go
ipfs
is
really
nice
now.
Well,
it's
nicer
and
now
the
js
ipfs
stack
is
completely
out
of
sync,
and
so
people
are
starting
to
report
errors.
Hey.
This
is
not
working
anymore.
D
I
upgraded
my
go
ipfs
backend
and
it's
all
broken.
So
that's
one
of
my
tasks
this
week
and
it's
actually
really
comfy
to
be
back
in
javascript.
After
being,
I've
been
go
for
it
for
many
weeks
now
and
and
it's
like
being
being
in
a
comfy
comfy
sofa,
comfy
lounge.
So
that's
that's
my
couple
of
weeks.
A
Thanks-
and
I
just
reminded
myself
that
I
have
an
update,
so
there
was
a
rust
multihash
release
with
only
a
signal
change,
but
a
braking
change,
and
so,
if
anyone
is
using
the
scale
coding,
this
is
now
like
properly
supported
it
was
it
was
supported
before,
but
now
it
doesn't
be
think
correctly.
A
So
it's
good,
but
it's
breaking,
but
it's
just
the
right
thing
now
and
so,
if
you
upgrade
and
you
don't
care
about
the
scale
coding,
so
it's
even
on
a
feature.
So
you
can
just
upgrade
and
you
will
be
fine
and
there's
another
issue
open,
which
I
don't
have
the
time
to
work
on
which
is
getting
a
hasher
by
code.
So
there
are
a
few
ideas
in
the
issue.
So
if
you
want
to
help
check
the
notes,
that's
all
I
have
so.
C
C
I
guess
no
real
updates,
but
I
am
curious
what
the
most
recent
advances
are
thinking
about,
ipld
as
always,
but.
A
B
With
help
with
help
there's
been
a
lot
of
stuff,
that's
improved
in
the
golang
usability,
especially
somebody
else
has
been
pushing
along
the
tools
you
can
use
to
bind
structs
in
golang
using
reflection
instead
of
the
whole
kojen
monstrosity
that
I
made
last
year.
So
it's
much
easier
to
use.
Now,
that's
been
a
really
big
improvement.
B
B
You
know
what
I'm
starting
to
make
a
cli
type
tool
for
like
I
want
something
that
lets
us
like
live
code.
If
somebody
wants
to
give
a
presentation
somewhere
about
like
here's,
what
ipld
is
and
how
it
does
and
how
it
feels
right
now,
you'd
have
to
write
a
bunch
of
code
and
like
have
an
ide
open
on
your
screen
share,
and
I
want
to
have
a
gadget.
B
I
just
dropped
some
other
links
in
the
bottom
of
the
dock
before
I
forget
about
them
again
too
of
other
stuff
that
community
folk
have
been
doing
in
js.
That
might
be
interesting
to
you,
folks.
I
don't
know
if
you've
seen
this
link-
and
I
don't
actually
recognize
the
authors
of
this
somebody.
D
B
Everything
in
javascript
recently
that
link
in
the
doc
there
appears
to
have
a
data
model
and
selectors
and
a
lot
of
code
I've
just
given
it
a
brief
skin
but
like
it
looks
very
correct
and
the
file
name
is
selectors.ts.
D
So
that
might
be,
they
wrote
a
retrieval
client
for
with
graphsync
and
everything,
and
it's
all
sort
of
bundled
into
into
one
thing.
Yeah.
D
A
B
A
Yeah
because
I
guess
yeah
so
certainly
the
the
rust
ecosystem
is
like
and
though
it's
actually
really
good,
because
there's
also
like
the
whole
question
about
the
the
the
rust
apolly
and
ibfs
ecosystem,
because
there's
different
libraries
and
so
on,
and
I
so
actually,
I
think,
probably
eighty
percent
of
the
questions
I
get
about
rust.
Ipod
is
about
like
which
repository
should
I
use.
So
it's
really
good
to
yeah.
I
have
some
documentation
there,
so
yeah
I'll.
Do
that
anything
else.
B
I
haven't
done
much,
but
some
other
folks
have
it's
a
bummer
that
will
isn't
here
to
share
with
us
this
week.
I
think
he's
working
really
hard
on
unix
of
sv1
as
an
adl
in
going
and
he's
got
some
cool
new
demos.
I
think
he
has
ads
of
sharded
file
systems
working
at
this
point.
I
haven't
checked
in
since
his
last
push,
but
that
is
steaming
along.
So
that's
kind
of
cool.
C
Cool
whatever
happened
with
that
hash,
was
it
a
dictionary
one
that
michael's
all
excited
about
this
is
about
a
year
ago?
Maybe.
C
D
Yeah
it
it
didn't
quite
get
over
the
line.
It
was
just.
There
was
some
sort
of
fatal
things
that
weren't
were
never
solved
and
michael's
sort
of
moved
on
to
other
things
and
that's
been
shelved
for
now,
but
it's
but
it's
I.
I
still
find
it
very
interesting.
It's
just
there's
there's
this
final
problem
of
it's.
It's
easy
to
attack
so
gonna
solve
that
before.
It
really
is
that
useful,
so.
C
D
Yeah,
no,
it
is
too
bad
because
there
are
a
lot
of
use
cases
for
that,
but
yeah
we
don't
we
don't
have.
We
don't
have
good
enough
reason
to
spit
to
invest
a
lot
of
time
in
it
right
now
compared
to
all
the
other
things
we've
got
to
do
so.
That's
that's
the
real
problem.
C
B
For
short,
you
should
start
a
conversation
with
one
of
the
people
in
this
call,
because
we
might
very
well
be
able
to
support
somebody
spending
focused
time
on
stuff,
like
sharded
maps
and
hamps
and
other
forms
of
data
structures,
there's
a
bunch
of
work
that
we
would
love
to
see
done,
and
I
think
it
might
be
possible
to
do
grants,
programs
or
something
to
support
it.
If
somebody
out
there
wants
to
do
this,
the
people
in
this
call
just
run
out
of
time
constantly,
but
we
would
love
to
help
somebody
tackle
it
more.
So.
A
I
have
a
question
about
something
that
we
also
wanted
to
tackle,
but
then
haven't
so
what's
the
most
recent
state
of
unix
fs
version
two
and
what
I
mean
by
it
is
not
like
like
how
like
like
what
we
actually
have
but
like
more
like,
like,
if
I
would
so
because
I
actually
thought
about
because
of
because
of
a
different
project,
just
like
just
do
something
like
just
in
my
free
time.
Just
like
take
all
the
like.
A
How
would
you
do
a
unix
if
s-like
system
today,
with
the
knowledge
we
have
about
like
how
we
want
ipod
to
be
and
so
on?
So
I
want
to
like,
because
I
I
of
course
could
start
from
scratch,
but
we
already
have
like
bits
and
pieces
there
and
I
want
to
like
do
we
have
any
place.
We
are
the
most
recent
bits
how
we
think
things
should
be,
or
should
I
just
like
search
and
find
you
know,
repost
random
bits
and
look
whatever.
A
We
have
because,
like
what
I
remember
is
like
what
we
talked
a
bit
about
was
those
like,
like
those
flexible,
vital
layout
stuff,
how
like
how
you
actually
chug
things
and
so
on,
but
what
I
recall
so
I
don't
recall
anything
that
we've
talked
about
the
actual
like
file
system
like
semantics.
If
we
spend
any
time
on
that
part
or
haven't
we
at
all.
B
I
think
we
have
some
exploration
report
docs
hanging
around,
but
they
were
mostly
punting
like
whenever
I
was
writing
any
of
those.
The
main
thing
I
was
trying
to
do
is
describe
how
one
could
specify
a
variety
of
approaches
to
metadata
rather
than
trying
to
pick
one
so,
but
if
you
wanted
to
just
spike
something
opinionated
out
and
see
how
it
works,
then
you
can
ignore
all
that
as
much
as
you
want.
Of
course,
you
just.
D
Yeah
and
then
there's
the
question
of
the
scalable
directory
layout
stuff.
Like
did
we
just
reuse,
the
unix
of
s
hamp
stuff?
Do
we
use
a
new
one
like
we
didn't
really
go
far
down
that
rabbit,
hole,
acknowledging
that
we've
got
a
lot
of
learnings
from
unix
best
v1,
but
we
also
have
a
lot
of
newer
opinions
about
how
to
do
things
better.
D
A
D
Probably
because,
because
you
know
one
of
the
flaws
of
unix
of
sp1
is
that
is
the
switch
point
between
hampden
or
no
hemp
and
that
that's
really
awkward
and
it's
it
shows
up
in
both
the
javascript
and
the
go
stack
and
incompatibilities
between
the
two
and
inconsistencies
and
it'd
be
nice
to
iron.
That
out
completely
and
maybe
just
say
it's
all
hand
and
but
maybe
there's
a
way
of
doing
a
compact
hand
for
the
simple
case.
So.
A
Yeah,
so
it
would
basically
be
a
hand
for
the
directories
and
a
flexible
byte
layout
for
the
chunking
of
the
files,
because
you
can
like
check.
However,
you
want
them,
and
then
you
just
need
some
like
some
like,
so
I
even
so,
I
think,
like
what
I
want
even
is
not
like
a
doing
cfs,
but
I
just
want
to
have
like
a
file
directory
abstraction,
I
would
say
like
I
don't
need
like
I
so
so.
This
is
not
that
I
have
like
processing
semantics
or
anything
it's
just
like
more
like.
A
D
It
I
think
it's
it's
hemped
plus
flexible
bite
layout
is
our
best
answer
right
now:
yeah,
okay,
I
I.
I
really
really
would
like
to
see
the
flexible
white
layer
done
in
the
in
as
an
adl
in
our
bld
prime.
It
wouldn't
be
that
hard,
but
it
would
be
really
interesting.
D
Tune
it
and
then
do
we
think,
do
we
have
any
implementation
of
it.
There's
a
javascript
one,
okay
cool!
I
I
think
it
matches
the
latest
spec
or
it's
close
to
like
it's,
but
it's
it's
in
like
it's,
not
it's
not
using
the
schema
language
or
anything
like
that.
It's
just
sort
of
like
a
javascript
implementation.
A
D
D
A
All
right,
I
think,
then,
if
there's
nothing
else,
I
close
the
meeting
and
so
goodbye
everyone
and
see
you
all.