►
From YouTube: 🖧 IPLD Every-two-weeks Sync 🙌🏽 2021-11-07
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
and
community
meeting
it's
November,
the
7th
2022.
and
as
every
two
weeks
we
go
over
the
stuff
that
people
have
worked
on
and
then
discuss
any
open,
Agenda
items
this
week.
I
actually
have
some
updates,
which
are
not
all
from
myself,
but
still
interesting.
So
the
past
two
weeks
there
was
like
big
protocols
and
ipvs
and
Falcon
things
happening
in
Lisbon
and
plenty
of
time
to
discuss
things,
and
so
I
spend
lots
of
time
discussing
CID
version
two.
A
So
then
I
spent
yeah
the
two
weeks
discussing
things:
I've
counted
the
hours
it
was
about
like
10
to
12
hours.
Really
disgusting
with
people
and
the
outcomes
are
several
proposals
and
I
have
the
hack
MD
linked,
which
contains
some
nodes,
currently
the
most
promising
one
which
seems
to
solve
all
the
cases
I'm
aware
of
is
so.
The
short
version
is,
we
will
not
do
a
CID
version
2,
but
we
will
do
something
else
instead
called
so
I
named
it
application
context.
A
But
if
anyone
has
a
good
name,
it
would
be
very
welcome
because
we
couldn't
have
who
couldn't
come
up
with
a
good
name,
and
you
want
to
do.
Is
you
get
a
new
multi
codec
and
you
say,
then
this
is
the
context
and
it
and
it
links
to
some
structured
data,
probably
an
iPlay
object,
which
contains
any
data
you,
like.
Probably
there
will
be
some
description
on
what
you
usually
put
there.
A
So
there's
yeah
emergence
and
people
kind
of
like
have
the
same
structure,
but
generally
it's
whatever
you
like,
and
then
afterwards
you
have
the
CID
and
then
so.
You
basically
request
the
city,
and
then
you
apply
the
context
and
it
could
do
whatever
you
like
use.
Cases,
for
example,
are
for
the
ipvm,
where
they
want
to
do
some
web
assembly
stuff
that
in
this
context,
they
describe,
for
example,
the
interface
of
your
assembly
program
of
your
web
assembly
program
or
what,
where
I
came
from,
is
when
I
traveled
to
the
alert
people.
A
A
So
this
is
a
good
idea
and
I
plan
to
write
this
like
out
in
a
proposal
and
so
on.
But
that's
the
rough
idea
and
what
like,
during
the
discussions
like
why
I
think
it's
a
great
idea
that
it's
not
a
CID
version.
2
is
because
it
means
that
it
won't
be
serialized
in
your
data.
A
We
just
pass
in
this
context,
and
this
other
thing
it's
a
dynamic
case
and
aesthetic
cases
you
really
want
to
have
it
in
your
ipld.
So
let's
say
you
have
some
data
structure
and
then
you
want
to
link
something
with
some
fixed
context:
yeah.
Well,
you
would
just
put
in
there
their
two
hashes,
like
one
hash
with
the
context
and
the
CD,
and
your
application
would
need
to
understand
that
this
is
the
context
I
applied
to
it
and
so
on.
So
that's
truly
the
rough
idea.
A
Yeah
and
yeah
I'm
pretty
happy
about
the
outcome
and
yeah
so
in
this
hmd
that
I
posted
is
also
like
different
ways.
How
we
thought
about
it
and
yeah
many
different
ideas-
and
the
last
thing
I
want
to
mention
in
this
regard-
is
for
the
work
project.
We
need
there's
the
need
for
more
parameterized
hash
functions,
which
we
already
have
in
the
multicolic
cable,
which
is
similarly
I.
Think
almost
everyone
agrees
that
that's
hard
to
scale
and
having
for
all
kind
of
parameters,
your
own
entry
and
yeah.
A
But
it's
also
like
part
in
the
document.
I
don't
go
too
deep
into
it,
because
I
will
probably
then
talk
about
it
once
I
have
a
proposal
and
then
I
will
talk
about
more
details
here
again
then
other
news
from
the
ecosystem,
which
is
like
not
really
to
me,
but
there
used
to
be
an
rust
ipfs
implementation
called
rust
ipfs,
which
was
sponsored
by
Proto
labs.
This
one
is
now
long
now,
no
longer
maintained
it's
archived
and
there
won't
be
no
further
development.
A
Alternatives
like
I
would
say
the
current
most
promising
one
is
iro,
which
also
God
has
his
first
release
published
during
ipfs
Campbell
last
week
or
the
week
before,
and
the
other
implementation
is
ipfs
embed,
which
doesn't
really
strive
for
full
compatibility.
But
it's
just
like
an
I
think,
interesting
project
and
also
like
worth
checking
out.
There
was
also
a
talk
at
the
ipfs
camp
about
ipfs
embed
in.
A
If
anyone
is
interested,
the
videos
should
be
up
soon
or
or
are
already
up,
I,
don't
know,
yeah
all
right
and
that's
all
I
have,
and
next
one
is
Eric.
B
Hello,
so
I
have
some
stories.
I
want
to
share
that
are
just
IPL,
the
in
the
wild
stuff,
not
really
core
developments.
My
pld
line,
it's
just
like
stuff
I'm
learning
as
I
try
to
use
the
Beast
so
I
had
a
project
unveil
at
the
ipfs
camp
this
last
week
also-
and
there
is
a
recording
of
orb
Forge
and
also
how
we
do
a
bunch
of
things
inside
of
it
and.
C
B
The
Middle-
that's
really
ipld
focused
so
there's
a
link
to
the
YouTube
thing
in
our
meeting
notes
and
in
particular
for
the
ipob
audience.
I
want
to
draw
attention
to
the
middle
starting
at
about
15
minutes
in
and
going
for
quite
a
while.
Basically,
every
place
with
a
background
slide.
Color
is
white.
There
is
a
section.
That's
talking
about
the
state
structure
called
catalogs
in
warp,
Forge
and
spoiler
they're,
just
a
huge,
huge
ipld
data
structure,
and
it
is
how
we
are
attempting
to
solve
a
distributed.
B
Naming
problem
and
package
versioning
and
just
sharing
metadata
problem
with
a
bunch
of
applied
iqb,
so
I
think
that's
kind
of
cool
and
should
be
a
fun
example
of
like
how
to
build
real
applications
using
ipld.
It
also
puts
some
ADLs
to
work,
or
at
least
I
hope
it
will
in
the
future.
I
want
to
use
probably
trees.
I
hope
that
we
get
an
implementation
of
those
we
can
plug
in
soon,
but
the
design
is
prepared
for
it
in
a
way,
yeah
lots
and
lots
of
IPL.
B
We
have
a
while
there
I
also
dropped
one
more
Link
in
the
meeting
notes,
which
is
to
the
source
repo
for
that
project,
where
we
have
a
big
ipld
scheme
file
with
I,
don't.
D
B
A
B
To
do
that
most
ergonomically,
so
we
tried
to
use
the
datalark
library
in
the
starlark
language
to
generate
this
data
and
also
have
types
from
the
IPL
V
schemas
on
the
fly
as
we're
doing
it's
turning
out
a
little
bumpier
than
I
had
hoped.
So
the
main
thing
that
we've
discovered
so
far
is
we
very
frequently
in
this
particular
user
story
want
to
generate
partial
fragments
of
data
like
we're
kind
of
solving
this
sort
of
a
templating
problem
in
our
and
and
like
the
application.
B
We're
developing
requires
us
to
crank
these
things
out
in
a
way
that
feels
like
filling
in
templates
and
the
trouble
here
is
that
then
applying
types
and
strictness
too
early
actually
doesn't
help
and
I
think
there's
some
kind
of
a
gradient
here
like
sometimes
it
does
help.
Sometimes
you
want
to
do
a
type
check
like
is
this
string
actually
matching
this
whole
set
of
unions?
Does
this
thing
parse
doing
that
early
and
providing
an
error
quickly
if
it
doesn't,
can
be
nice?
B
This
awkward
situation,
where
we
would
either
write
a
bunch
more
types
that
have
optional
fields
that
feels
bad
or
like
write,
some
partial
types
that
have
like
half
of
the
fields
in
them.
That
would
be
technically
correct,
but
like
feels
very
boilerplate
and
heavyweight,
or
we
could
write
a
bunch
of
data,
that's
totally
untyped
and
apply
types
at
the
end
and
I
think
that's
where
we're
going
to
end
up
continuing
to
try
to
work,
and
hopefully
the
datawork
libraries
are
actually
going
to.
Let
us
do
this
smoothly.
B
D
B
A
Thank
you
next
on
my
list
is
Museum.
D
Hey
everyone:
it's
been
a
while
since
I've
attended.
One
of
these
just
wanted
to
say,
hi
and
also
report
that
I
have
reworked
some
of
the
unmanned
stuff
that
I
was
working
on
the
last
few
months.
It
is
now
implemented
in
basic
node,
instead
of
being
part
of
traversal
or
parallel
reversal,
I
think
it
does
the
job
and
it
works.
That
definitely
would
appreciate
her
to
lose
and
go
from
there.
D
Part
of
it
is
not
quite
I'm
trying
to
implement
the
equivalent
of
traversal
from
within
basic
note
that
feels
a
little
hacky
and
ugly,
but
whenever
someone
gets
a
chance
to
look,
please
take
a
look,
and
let
me
know
that
was
it
for
me.
E
Sure
I've
just
got
a
a
small
one,
there's
a
PR
to
the
go
car
CLI
that
adds
a
pair
of
sub
commands
that
I
named
debug
and
compile
debug
will
take
a
car
and
dump
it
into
a
patch
file
like
syntax
and
we'll
put
each
block
in
a
dag
Json,
pretty
printed
format,
so
that
it's
largely
human
interpretable
things
that
are
just
bytes
if
they
are
ASCII
printable
will
just
be
raw.
E
So
you'll
get
like
the
contents
of
the
file
just
directly
there
and
then
in
the
patch
header,
it'll
say
if
it's
Json
or
Raw
and
then
compile
will
undo
that
and
put
it
back
in
a
car
file.
And
one
of
the
neat
things
is,
it
does
do
some
find
replace,
so
it
will
re-link
the
SIDS.
E
So
if
you
modify
some
sin,
it'll
see
what
points
to
the
previous
Sid
from
the
header
and
we'll
recompile
to
figure
out
what
the
newest
it
is
and
it'll
change
the
links
of
the
parents
to
re-link
them
to
where
they
should
be.
So
it
makes
it
relatively
easy
to
go
in
and
modify
some
piece
of
a
dag
and
then
get
a
new
still
linked
car.
A
Cool,
that's
really
exciting,
so
next
one
is
move.
C
E
If
not,
I
have
not
considered
very
much
at
all:
I
I
did
the
plus
plus
and
the
minus
minus
minus
so
that
I
could
run
it
through,
like
the
diff
commands,
I
had
and
get
nice
colors
and
stuff,
because
they're
good
at
doing
that.
I
am
not
overly
committed
to
any
format,
though.
C
Interesting
just
pointing
it
out,
as
that
might
be
something
just
interesting
to
have
focus
more
in
the
community,
so
we
can
be
like
hey.
Here's
like
the
way
to
diff
ipld
in
a
way
that
you
can
send
it
down
the
wire
or
whatever.
So.
E
So
the
interesting
thing
here
is
this
doesn't
actually
do
any
diffs
it.
It
prints
it
in
a
like
hunk
format,
in
the
same
like
here
is
a
file
that
we're
going
to
call
the
Sid
and
both
the
plus
and
the
minus
side
is
named
The
Sid,
because
the
Sid
hasn't
changed
necessarily,
and
then
we
do
the
little
at
signs
to
say
how
long
it
is,
and
then
we
just
print
the
file
so
we're
not
putting
like
we're
not
comparing
two
things.
It's
just.
E
C
Cool
okay,
I
guess
now
we
can
talk
about
my
updates.
So
last
week
was
the
end
of
lab
week,
2022.
C
C
I
did
a
couple
of
talks
on
what
ipld
is,
which
I
aim
to
have
like
a
high
level
intro
to
all
of
the
pieces
that
are
relevant
and
specifically
trying
to
make
it
accessible
to
people
that
are
new
to
ipld?
That
might
know
a
little
bit
of
the
ipfs
ecosystem
and
so
far
it
seems
like
there's
folks
that
have
been
like
enjoying
that
approach.
C
Had
a
lot
of
talks
about
folks
that
are
now
more
interested
in
using
ipld
I.
Think
there's
a
lot
of
talks
about
ipld
databases,
Eric
mentioned
before
excitement
about
prolly
trees,
I'm
also
very
excited
about
probably
trees
and
I'm.
Gonna
get
I'm
gonna
get
a
bunch
of
other
teams,
excited
about
probably
trees,
and
so
the
spec
for
that
is
actually
nearing
a
state
where
we're
going
to
PR
it
to
the
main
ipld
repo.
C
So
we've
just
generated
some
fixtures.
We
have
most
of
our
spec
text
written
out
and
that's
a
huge
thanks
to
Julius
from
I
guess
representing
herself,
and
also
can
the
Ken
Labs
team
from
I
think
mostly
China
and
Europe,
on
doing
all
the
heavy
lifting
on
implementing
all
of
that,
but
we're
hoping
to
have
that
submitted
as
a
PR
sometime
soon
and
we'll
be
really
excited
to
get
reviews.
C
There
is
an
initial
implementation
that
is
almost
ready
in
golang
and
we'll
probably
be
looking
at
doing
a
Dev
grant
for
a
rest
implementation,
soonish
outside
of
that
during
Lisbon
we
had
some
ipld
team,
Road
mapping
talks
where
to
be
honest,
the
past
year,
or
so
the
ipld
team
hasn't
really
existed
much,
but
that
might
change
and
part
of
that
is
going
to
be
having
an
actual
roadmap
of
what
we're
going
to
be
working
on
developed,
we're,
probably
going
to
be
hiring
up
to
increase
our
capacity
in
the
team
and
also
we're
going
to
be
starting
up
a
working
group
where
which
will
put
together
stakeholders
from
a
bunch
of
protocol,
Labs
related
teams
that
may
be
building
on
top
of
ipld
and
part
of
the
goal
that
there
is
to
like
find
out
where
there's
common
needs
and
try
to
get
those
needs
met,
so
we're
still
kind
of
figuring
out
what
this
will
be.
C
But
this
is
kind
of
like
a
bit
of
an
info
dump
of
the
conversation
I
had
during
the
event,
so
yeah
stay
tuned
for
that,
probably
within
the
next
two
weeks.
We'll
have
more
interesting
things.
Foreign!
A
Cool
yeah
I
forgot
to
mention
that
there
was
also
a
meeting
about
the
ipld
documentation,
so
we
had
a
run
through
from
Julia
from
protocol
Labs,
who
did
kind
of
like
the
ux
side
of
things
and
proposed
like
how
to
restructure
things,
and
then
we
had
so
in
the
meeting
were
also
people
from
the
protocol
of
stocks,
team
and
So.
The
plan
is
now
that
basically
there's
a
plan
on
how
to
we
could
restructure
the
documentation
and
then
we
move
it
over
to
their
platform,
which
is
also
on
my
downbase.
A
So
it
should
really
be
again
just
like
just
moving
files,
and
so
their
platform
also
supports
the
redirects.
So
we
make
sure
that,
for
example,
like
links
to,
let's
say
that
deck
sibo
spec,
which
is
heavily
used,
will
redirect
to
the
new
thing
if
the
URL
changes
and
the
new
system
or
like
what
they
use
is
Hugo
based
but
yeah.
It's
an
implementation
detail,
but
we
then
will
also
get
search,
for
example,
on
the
documentation
and
stuff
like
this
and
potentially
also
like
people
could
translate
this
stuff
and
basically
so.
A
We
kind
of
like
hand
it
over
to
the
docs
team,
which
is
kind
of
nice,
that
they
kind
of
like
take
care
of
it,
and
so
the
agreement
was
that
so
they
don't
really
put
effort
into
like
improving
the
documentation
now,
but
the
first
step
is
really
only
like
restructuring
it
to
a
way
we
obviously
rod
and
Julie
have
worked
on
which
makes
sense
and
they
do
the
kind
of
like
the
in
digital
import,
and
then
we
go
from
there
and
I
also
volunteer
to
basically
review
PRS
or
something
and
yeah
stuff
like
this,
and
then
we
can
go
from
there
and
but
it
won't
happen
soon.
A
C
All
right,
if
I
may
add
to
that
real
quick
also
during
the
road
mapping
sessions.
It
got
brought
up
that
just
outside
of
the
look
and
feel
of
the
docs.
It
might
be
useful
to
add
some
new
docs
that
are
a
little
bit
more
beginner
friendly
or
have
like
a
more
gentle
on
route
to
the
more
details,
oriented
content,
that's
already
on
there.
A
Yeah
there
is
also
like
already
like
Rod
mentioned,
that
he
wrote
already
dogs
for
the
Launchpad
program,
which
are
not
part
of
the
ipolito
documentation,
but
they
will
be
moved
over
then
into
the
products,
so
yeah
right,
cool,
all
right,
cool
anything
else.
A
A
No
then
thanks
everyone
for
attending.
We
now
close
the
broadcasted
meeting
and
we
go
to
the
after
party
and
yeah
for
everyone
else.
We
see
us
again
in
two
weeks
goodbye
everyone.