►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2019-08-05
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
A
A
Thanks
rod,
it
would
also
be
cool
if
at
one
point,
someone
else
and
I
take
notes,
preps,
but
that's
something
for
next
week.
So
we
start
with
going
through
on
updates
and
what
we
did
and
things
we
plan
to
do
so.
I'm
the
first
one
I
should
start
with
it.
So
I
found
out
that
there
is
a
registry
for
seaboard
hags
and
we
use
for
SIBO.
We
use
tag
42
for
C
IDs,
and
it's
already
taken
back
when
it
was
decided
to
use
this
taken
wasn't
taken.
A
Now
it
is,
and
we've
opened
an
issue
on
the
repository
of
the
people
have
registered
the
tag
and
yeah
we're
currently
discussing,
and
we
hope
that
so
the
hope
is
that
we
might
be
able
to
get
this
tag
for
our
stuff,
but
we'll
see,
and
then
I
did
a
bunch
of
fun
stuff
in
the
JSI
poly
world
and
updated
and
LD
take
pearl
called
buffer
and
chase
I
Conley
and
released.
It
then
I
also
opportunity
to
the
exhibits
to
use
those
Reese's.
Those
were
also
already
missed
by
Alex.
A
So
now
the
only
missing
thing
is
updated
in
case
activist,
which
sounds
simple,
but
isn't
because
we
use
a
new
version
of
ipfs
repo,
which
is
now
using
a
base
in
Kuwait
instead
of
comics,
and
so
this
needs
to
go
through
all
the
code
base
and
a
lot
of
ipfs
stuff
is
using
IPS
s,
repo,
even
in
the
p2p
does.
So.
A
B
So
I
got
some
new
information
from
some
of
the
other
ipfs
nodes
running
in
the
wild
this
last
week
about
performance
stuff
and
getting
a
bunch
of
paper
off
files
dumped
from
production.
Let
me
identify
some
bottlenecks
that
were
previously
not
so
obvious
in
some
of
the
refund
code
and
the
older
generation
of
I
peeled
the
interfaces.
B
We
I
think
all
of
us
did.
A
lot
of
work
in
the
last
week
on
PR
is
to
specs
documents
about
like
basic
principle
stuff
as
well
and
I.
Think
there's
still
like
three
or
four
or
so
some
minor,
some,
not
so
minor
alterations
that
are
proposed
to
that
right
now,
which
I
think
we
should
probably
do
a
bunch
of
possibly
synchronized
review
time
on
after
this,
it's
I'm
really
glad
that
we've
started
doing
some
of
that.
C
There's
my
audio
am
I
on
yep,
so
I've
been
a
go
programmer.
This
past
week
got
the
hashmap
partially
implemented
on
top
of
go
at
building.
Prime,
so
far,
I'm
I
can
iterate
over
all
the
the
key
values.
You
know
in
an
existing
hash
map
data
structure
having
quite
wired
up
the
bit
where
you
go
to
a
particular
one
but
getting
to
it,
but
learning
a
lot
about
the
way
that
Eric's
done
his
eye,
peeled
the
implementation
and
I'm
trying
to
figure
out
how
to
adapt
to
that.
C
Also
getting
my
head
around
some
of
the
challenges
that
go
programmers
are
bringing
to
the
discussions
were
having
so
it's
it's.
You
know.
I
had
a
moment
last
week
where
I
had
to
click
in
my
head
with
some
of
these
discussions
started
to
make
a
little
bit
more
sense,
not,
but
not
that
they're
nonsensical,
but
they,
you
know
they're,
there's
this,
there's
baggage
that
we
all
bring
and
I
could
sort
of
see
the
pain
that
you
go.
Programmers
are
bringing
to
the
discussion.
C
As
I
had
it's
like
yesterday,
looking
at
portability
of
a
large
test
fixture
data
for
testing
across
languages,
I
want
to
do
language
independent
test
fixtures
that
can
that
we
can
do
the
same
assertions
on
in
tests
in
multiple
languages
so
and
that's
for
complex
style,
and
not
just
these
trivial
little
things
that
we
tend
to
build
for
unit
tests
so
yeah,
that's
in
some
experiments
there
and
also
some
experiments
with
them
just
graph
filtering
and
storage
stuff.
So
that's
that's
it
for
me.
D
My
notes
here-
okay,
yeah,
so
I've-
been
off
for
a
few
weeks
for
vacation,
but
right
before
that
we
did
have
the
okay.
Our
review
call,
which
was
much
more
just
kind
of
a
general
project
that
you
call
so
went
over
with
a
lot
of
people,
sort
of
where
we're
going
and
recently
I've
been
sharing
that
feedback
with
different
individuals
and
also
working
a
lot
of
that
into
some
upcoming
stuff
that
we're
doing
so.
One
is
a
sort
of
rebooting,
the
the
some
of
the
UNIX
FS
conversations.
D
We
have
like
a
bucket
called
UNIX
52
that
a
lot
of
things
have
been
dumped
in
for
a
long
time,
and
one
thing
that
I
realized
recently
is
that
some
of
those
have
very
different
priority
than
others,
and
some
of
them
could
be
done
as
in
51.
Some
could
be
worked
into.
You
know
a
mid
version
of
UNIX
at
sp2.
If
we,
if
we,
if
we
know
that
we're
gonna
sign
up
for
another
update
at
some
point
in
the
future,
we
could
do
something
in
the
interim.
D
That
was
actually
pretty
good
performance,
but
it
all
depends
on
sort
of
what
the
priorities
are
of
all
these
individual
items.
So
I've
done
the
work
of
breaking
all
that
about
linking
to
a
lot
of
the
history
for
all
of
those
and
put
that
into
a
markdown
document
that
I
shared
out
that
we'll
be
going
through
in
meeting
on
Thursday
with
the
ipfs
folks
to
try
and
get
really
distinct
priorities
and
understanding,
and
it
should
be
individual
issues
so
that
we
can
then
figure
out
what
the
best
plan
of
attack
is.
D
Also
there's
this
project
Advisory
Committee
thing
that
we've
been
setting
up.
We
I
think
eventually
we're
gonna
have
them
across
all
the
protocol
house
projects
but
I
think
we're
up.
I'm
do
I'm,
accelerating
the
timeline
for
ours,
because
there's
it's
a
good
way
to
gather
feedback
from
other
projects,
and
we
need
to
start
doing
that
a
little
bit
more
of
a
holistic
web.
So
the
first
meetings,
actually
next
weeks,
I've
been
preparing
all
the
agenda
for
that.
D
So
if
any
of
you
all
have
things
that
you
want
to
have
surfaced
from
other
projects
or
questions,
you
would
like
to
ask
about
projects.
Let
me
know
about
that.
This
week,
I've
also
test
a
few
people
with
just
some
items
for
that
agenda.
That
I
can't
write
up
myself,
because
it's
the
projects
and
y'all
are
working
on
and
not
me
and
then
the
last
time
I'll
talk
about
a
little
bit.
Is
this
just
kind
of
like
little
nights
and
weekends
thing
that
up
and
hacking
on
called
bundle?
D
Sync,
so
the
basic
idea,
so
JavaScript,
client-side
bundles,
are
gigantic.
They
keep
getting
bigger
because
web
pack
makes
it
too
easy
to
depend
on
things.
So
as
these
get
bigger,
they
become
much
more
problematic
to
reload
over
and
over
and
over
again,
whenever
something
even
minor
changes,
and
because
the
bundles
are
just
a
bunch
of
the
same
pack
and
just
packed
together
all
the
time,
it's
sort
of
an
ideal
case
for
rabbin.
Actually,
because
if
you
make
minor
changes
to
your
bundle,
it
would
actually
only
change
a
few
hashes
and
a
big
rabbit
piece.
D
D
All
of
these
ideas
down
into
these,
like
really
tiny
libraries,
for
just
just
to
get
the
syncing
piece
up
and
running
and
I've
been
working
with
CloudFlare
workers
actually
to
do
the
EM,
storage
and
peace,
because
then
all
of
the
parts
that
are
in
that
ramen
bundle
are
also
edge.
Cached
and
all
of
the
syncing
logic
is
also
on
the
edge.
So
you
don't
lose
any
of
that.
D
Nice
CDN
hang
stuff
because
Consular
has
this
nice
worker
thing,
but
also
cleft,
where
workers
have
like
no
debugging,
it's
like
it
either
works
or
it
doesn't,
and
if
you
want
to
debug
something
you
have
to
like
put
it
in
the
response
body.
So
that's
been
really
fun
to
work
with
development,
but
it's
it's
been
really
illuminating
for
me,
just
in
that
we
have
a
lot
of
separations
that
are
conceptual
in
a
lot
of
our
documentation
and
then
we've
realized
love
those
separations
in
code
and
then
coming
at
it
from
a
completely
different
angle.
D
We
don't
have
that
code
that
shows
the
separations
figuring
out
where
those
different
pieces
really
belong
has
been
really
really
interesting,
like
I've
had
to
actually
go
and
rent
a
new
block
format
that
is
like
compressed
and
doesn't
require
a
bunch
of
doesn't
require
any
external
hash
functions
and
stuff
like
that,
and
it's
interesting
how
well
a
lot
of
the
conceptual
layers
hold
up,
even
when
you
don't
have
our
kind
of
code
layers.
So
that's
been
really
great
learning
a
lot
from
that
and
that's
it
from
my
update.
D
Okay,
Rob
asked
what
pack
means
pack
is
a
project
Advisory
Committee,
that's
what
it
stands
for.
So
the
idea
of
these
these
packs
is
that
we
gather
the
internal
stakeholders
like
in
protocol
labs
to
the
other
projects.
Essentially,
and
those
project
leads.
We
have
a
much
more
structured
environment
for
us
like
updating
them
and
getting
their
feedback
because,
as
these
projects
grow,
you
can't
just
like
understand
everything.
D
A
E
E
D
Yeah
so
to
Eric's
point
in
scheduling,
just
a
call
for
us
to
iterate.
On
the
last
two
points,
I'd
like
to
go
to
a
car,
we
actually
knock
through
kind
of
all
the
specs
in
that
repo,
because
there's
a
bunch
of
older
ones
that
we
should
just
look
at
and
just
decide
to,
merge
or
not
because
there's
like
stuff
in
there
for
dag
peepee
that,
like
we're
not
changing
it,
we
should
probably
just
mark
it.
A
D
That's
that's
the
best
idea.
I
was
trying
to
knock
it
out
this
week,
but
I
actually
had
you
have
a
lot
of
stuff
on
my
plate
this
week.
So
that'll
give
us
plenty
of
time
to
do
anything,
review
everything
it's
there
and
then
we
can.
B
B
Yeah
I
think
might
benefit
from
like
at
least
two
sessions
like
we
want
to
land
all
of
the
smallish
ones
that
are
out
now
smallish
but
impactful,
and
then,
like
the
backlog,
grooming,
I
think
we
should
make
maybe
a
separate
day.
So
we
go
into
that
one
fresh
exhaust,
that's
I
would
love
to
get
us
down
to
inbox
zero
on
issues
and
PRS
I
dislike
that
number
being
anything
more
than
absolutely
none.
B
Maybe
we
can
do
the
thing
where
we
do
it
get
merged
where
we
do
us
ours,
flags
like
stays
in
history
that
doesn't
contribute
to
the
deafening
Lord
or
etc,
because
there
is
there's,
definitely
lots
of
stuff
out
there.
That's
like
that,
that's
good
ideas,
I,
just
don't
want
it
to
be
acting
like
it's
in
an
inbox
when
it's
obviously
not
being
acted.
E
E
B
E
E
D
We
have
like
a
bunch
of
spec
refining
issues
from
Nicola
and
2016
that
we
can
probably
just
close
out
this
way.
Just
being
stale
I
mean
they're
stale
at
this
point
like
they're
yeah,
there's
not,
we
would
need
to
to
create
anyone
in
order
to
okay,
cool
yeah
I
mean
a
lot
of
clearing
out
these
issues.
We
can
just
do
like.
We
don't
need
to
have
them.
You
do
about
that,
but
it's
Beck's
required
before
discussion,
either
cool.