►
From YouTube: 🖧 IPLD Every-two-weeks Sync 🙌🏽 2022-01-17
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
A
A
So
as
every
every
two
weeks
we
go
over
the
stuff
that
we've
worked
on
or
plenty
worked
on,
plan
to
work
on
and
then
also
discuss
any
open
agenda
items
we
might
have
and
for
me
it's
a
great
start
into
this
year,
because
I
even
have
have
ipld
updates
this
time.
So
currently
I
spend
quite
some
time
on
last
ipod
things
and
yeah.
So
it's
already
started
in
in
the
past
year
that
and
there's
lots
of
stuff
going
on
on
the
rust
multi
formats
stuff.
A
If
anyone
is
interested
check
out
the
next
branches-
and
there
are
things
there
are
many
things,
but
the
most
notable
ones
are
and
we're
moving
to
cons
generics
sar
are
in
the
form
that
we
need
them
are
a
stable
feature
in
rust
now
and
also
better
support
for
no
standard,
which
means
that
you
don't
need
to
have
the
standard
library,
which
is
mostly
important
also
for
work.
A
Oh,
I
forgot
to
mention
that
rust
ipod
moved
from
its
own
org
into
the
ipl
org.
So
now
you
can
find
the
most
current
version
on
github
dot
com,
slash,
ipld,
lib
ipld,
that's
the
roster
implementation
and
yeah.
We
spent
some
time
on
it
and
currently
it's
yeah
it's
in
development,
but
plenty
of
things
will
change
and
the
most
notable
one
again
is
that
we
trying
to
move
to
use
30,
which
is
the
standard
serialization
library
for
us
and
those
who
have
been
following
these
meetings.
A
A
But
if
you
have
an
implementation
of
a
format
which
is
understands
how
cads
work
or
understand
the
cid
type,
then
everything
is
fine.
So
what
it
means
for
the
end
user
is
you
can
use
30?
You
can
use
the
the
micro
derives
and
if
you
have
types
that
serialize
to
30,
they
automatically
end
up
correctly,
formatted
in
hyperlink
and
so
on.
The
only
thing
is:
if
you
want
to
use
c
board,
you
can't
use
a
stock
cyborg
encoder,
but
you
use
the
dag
zebra
one
which
you
would
want
to
use
anyway.
A
But
given
all
this,
the
tweaks
for
your
format
to
in
order
to
work
with
the
ipod
world
should
be
quite
minimal.
So
even
if
we
say
we
won't
have
a
new
codec
which
is
not
cbore
but
let's
say
amazon
iron.
It
should
be
a
matter
of
a
day,
patching
it
or
something.
So
it's
not
like
a
huge
development
effort
all
right
so
but
this
is
currently
pushed
to
random
branches,
but
the
plan
is
to
really
get
it
properly
done
and
that
it
actually
works
and
yeah.
A
So
this
is
kind
of
huge
news,
yeah
and
that's
all
I
have
for
now
from
the
rost
world.
So
next
on
our
list
is
danielle.
B
So
I've
been
pretty
heads
down
on
graph
sync,
I'm
sort
of
now
phasing
that
into
some
more
ipld
work,
not
not
being
centered
around
crafting
so
much,
but
some
of
the
things
I
landed
over
the
last
couple
of
weeks,
which
I
did
mention
at
the
last
call
already-
is
support
for
enums
and
any,
and
I
also
ended
up
making
enums
that
represent
themselves
as
integers,
potentially
allowing
them
to
bind
to
go
integers,
which
is
one
of
those
cases
that
you
say
like.
B
Putting
protobuf
go
versus
ipld,
prime
with
taxiware
and
bind
node,
and
it
is
slower,
that's
to
be
expected
because
protobuf
is
very
well
optimized
and
they
don't
have
the
abstraction
layers
that
we
do,
but
we're
only
about
two
to
three
times
as
slow,
which
is
good
news
in
the
sense
that
we're
not
that
far
and
we
haven't
optimized
many
of
the
libraries
a
lot
just
yet
and
it
seems
like
graphsync
is
on
track
to
using
apld
and
shipping
soon.
But
I
think
rod
will
talk
about
that.
B
B
C
Why
don't
we,
let
me
get
I'll,
get
a
different
headset?
Why
don't
you
skip
me
I'll
be
I'll?
Go
next.
C
Okay,
all
right,
sorry,
sorry
about
that
yeah.
I
think
thanks
all
yeah,
I'm
big
leopard
or
steve
and
yeah.
I
know
my
first
time
at
this
meeting,
thanks
for
letting
me
join
more
on
here
on
the
management
end
just
more
in
general,
across
pl's,
some
of
the
pl's
teams
focused
on
some
recruiting
efforts
and
just
flipping.
Some
more
of
our
communication
is
happening
in
public
that
will
apply
to
ipld,
but
this
is
an
ex
exclusive
ipld
effort.
C
So
hopefully
I
have
more
to
share
at
the
the
future
meeting,
but
that's
kind
of
where
I'm
at
thanks.
A
Thank
you
next
is
the
road.
D
Yes,
now
I
don't
have
peeps,
but
one
thing
to
discuss
anyway
did
some
minor
things
in
javascript
land,
the
last
couple
of
weeks,
mainly
around
js
multiformats,
our
core
library,
that
we
use
for
ipld
things.
Gazala
contributed
some
types
fixes.
D
This
is
just
ongoing
drama
with
typing
exporting
typescript
types
from
our
javascript
libraries,
and
we
find
situations
where
they
don't
they're,
not
exported
properly
or
they're,
not
generated
properly
or,
and
it
turns
out
to
be
something
that's
really
difficult
to
test
for.
We've
got
tests
for
some
of
these
things,
but
they
it
just
depends
on
how
you
consume
them,
and
it's
a
bit
crazy.
So
and
then
the
same
thing
goes
for
our
es
modules
versus
common
common
js
exports.
D
I
think
alex
is
starting
to
migrate,
some
other
javascript
libraries
to
pure
es
modules
and
I'm
seeing
also
seeing
some
typescript
pure
typescript
work
going
on.
So
one
solution
to
all
of
this
is
just
to
write
everything
in
typescript
and
export
only
as
es
modules,
and
then
a
lot
of
these
problems
start
to
disappear.
But
for
now
this
is
this.
D
Is
our
call
library
that,
if
you're
touching
anything
to
do
with
ipld
and
therefore
anything
to
do
with
ipfs
in
javascript,
then
you're
using
this
library,
so
we
sort
of
want
to
make
it
maximally
compatible?
D
We
had
we
had
at
least
one
book
release
that
was
thankfully
caught
within
a
few
hours
that
we
managed
to
fix
as
we
try
and
tweak
and
fix
some
of
these
types
things
anyway.
That's
just
ongoing
this
ongoing
dance
that
we
do
with
that
library,
and
then
we
take
the
what
we
learned
there
and
apply
them
to
other
libraries.
D
Aside
from
that,
I've
been
doing
playing
around
with
daniel's
excellent
bind
node
stuff
thanks
to
the
graph
sync
messaging
migration
and
picking
up
some
problems
to
throw
over
the
fence
to
daniel
to
have
a
look
at
which
sounds
like
he's,
got
some
work
on
mainly
to
do
with
pointers
and
nullables
and
optionals.
D
So
because
the
original
schema
that
daniel
put
together
didn't
have
any
nullables
and
I've
been
trying
to
make
the
messaging
protocol
more
complete,
because
this
message
is
where
some
of
the
elements
are
admitted
so
trying
with
option
trying
nut.
What
was
I
doing?
D
Optionals
first
and
then
things
go
missing
from
the
struct,
which
means
the
struct
is
shorter,
and
then
the
sebor
encoding
doesn't
come
out
right
because
bind
node
was
reporting
the
the
length
of
the
map
to
be
the
length
of
the
struct
with
all
the
fields,
but
then
they
can
get
the
encoders
shorter,
and
so
that
resulted
in
a
pull
request,
333
to
ibili
prime,
which
builds
in
that
check
to
the
c
ball
and
and
even
the
the
json
which
might
not
make
sense.
D
But
it's
just
one
of
these
checks
where,
if,
if
a
and
a
node
is
reporting
a
map,
node
is
reporting
a
link,
and
then
it
doesn't
give
you
that
many
elements
that
should
be
an
error.
That's
like
a
fatal
kind
of
error,
because
you've
got
a
programming
problem
there,
so
that's
going
in
there
and
those
tests
are
currently
failing.
Well,
yesterday
were
anyway
with
by
node
and
a
couple
other
things
there.
I
I
did
want
to
talk
about,
and
maybe
this
is.
D
This
is
a
discussion
topic,
but
I
want
to
talk
about
the
schema.
So
daniel
did
a
first
pass
of
the
schema
for
the
ipld,
so
yeah
the
dxe
ball
messaging
in
graph
sync,
it's
it's!
It's
a
very
it's
a
it's
a
bulky
schema
as
in
it
uses
maps
and
even
though
the
keys
are
shortened,
it's
still
it's
way
more
than
the
protobuf
like
yeah,
and
it's
way
more
than
what
you
could
do.
If
you
say
you
say
we
chose
tupples
and
the
other
part
of
that
discussion
is
the
versioning.
D
So
we've
got
this.
This
migrations
concept
of
that
of
that
migration
stock.
D
That
eric
wrote
up
a
couple
of
years
ago,
that's
in
our
ipld
documentation,
repo
with
some
best
practices
for
versioning,
and
but
we
have
this
additional
thing
where
we
we
can
version
within
the
protocol
where
we're
talking,
we
can
send
a
version
string
ahead
of
time
to
switch
on
different
versions,
but
we
have
the
opportunity
now,
as
we
do
this
major
migration
from
protobuf
to
dag
sebor,
where
we
could
say
well,
let's
make
it
just
one:
dag
siebel
version
where
we,
our
decoder,
our
daxybor
decoder,
can
do
the
version,
so
we
can
use
schemas
to
do
versioning
within
that
single
protocol
version,
or
we
could
rely
on
protocol
versioning
to
switch
between
different
message
formats.
D
So
that's
that's
a
discussion
I
wouldn't
mind
having
not
necessarily
on
this
call,
but
we're
getting
closer
to
being
able
to
ship
something,
and
I
don't
really
want
to
lock
in
a
a
bulky
schema
or
one
that
is
less
flexible
than
we
want.
Yeah.
E
E
I
don't
have
a
ton
of
updates
because
I
think
I'm
still
kind
of
recovering
from
the
winter
hiatus
a
bit,
I'm
skimming
the
schema
that
ron
was
just
referring
to
and
I
think
you
kind
of
already
broke
down
all
of
the
the
potential
choices
and
trade-offs,
or
at
least
most
of
them
right.
So
I
guess
the
questions
will
mostly
be.
E
How
far
do
we
want
to
shift
between
binary
illegible
but
highly
compact
and
more
textual
more
self-describing
easier
to
eyeball?
Maybe
the
solution
will
be
somewhere
in
the
middle
too.
We
have
the
option
of
doing
verbose,
map
keys
and
like
the
outermost
objects.
And
then,
if
you
go
deeper
into
the
more
highly
repeated
objects,
then
you
can
go
tuples
and
see
if
that
strikes
a
balance.
E
Other
updates
for
me,
I
actually
do
not
have
a
ton
right
now,
melcin
and
I
have
been
chatting
a
lot
lately.
We've
been
starting
to
yeah,
I'm
calling
you
outside
we've
been
starting
to
work
on
outlines
of
what
we
might
want
from
an
ipld
patch
spec,
so
I'm
starting
to
at
least
think
out
loud
about
what
we
might
try
to
pursue
in
more
going
apis
for
updating
objects.
E
E
A
Cool
thanks
does
anyone
else,
have
any
updates
or
anything
to
share,
or
I
don't
know
to
say
before
we
get
into
more
questions.
A
Nope
cool
yeah
I
saw
on
on
the
chat.
I
saw
that
steve
had
some
questions.
I
can
quickly
answer
so
yeah,
so
the
current
just
ipod
effort
is
driven
by
the
fi
coin
virtual
machine
and
which
is
also
the
reason
why
I
currently
spend
time
on
it
because
I'm
currently
towed
in
a
totally
different
team
and
but
I
was
asked
or
like
if
I
would
like
to
help
out-
and
I
obviously
wanted
to
and
so
the
plan
was.
A
I
helped
out
till
the
end
of
the
year,
which
obviously
is
over
now,
and
so
I'm
finishing
some
things
up
and
yeah.
We
just
need
to
discuss
how
much
time
I
will
spend
on
this,
but
so
my
current
plan
would
be
that
I
spent
something
like
a
day
a
week
or
something
on
those
things
and
but
we'll
see
so,
let's
just
yeah
and
discuss
it
with
my
manager
and
so
on,
but
we'll
see,
but
I'm
as
you
can
see.
A
A
Features
that
we
have,
I
make
it
pass
with
the
old
version,
but
the
third
version
is
basically
the
next
step
is
to
make
it
work
against
the
fixtures,
but
I
already
have
the
rust
code
running
the
whole
machinery,
so
the
basically
once
it
ships
it
will
pass
all
the
tests
that
we
have
in
the
test
features
so
yeah
cool,
all
right,
so
yeah
is
there
anything
else.
People
want
to
discuss
or
have
questions
so
also,
oh
I've.
I
saw
that
there's
a
question
on
the
live
stream.
A
Oh,
this
is,
is
it
a
new
question?
I
don't
know,
but
it's
a
general
ipfs
question
and
so
the
question
for
those
who
don't
see
the
live
stream
is
the
question
is
about
someone
who
is
a
flutter
developer
and
wants
to
know
how
to
use
ipfs
for
storing
the
data.
I
can't
really
tell,
but
I
would
refer
to
the
we
have
discussions
forums
for
ipfs,
so
I
suggest
asking
the
question
there:
there
might
be
better
chances
of
people
helping
all
right
anything
else.
A
No
all
right,
then
it
was
a
quick
meeting
and
we
see
us
again
same
time
in
two
weeks,
so
goodbye
everyone
and
thanks
for
attending
bye.
Everyone.