►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2019-09-30
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
Welcome
everyone
to
this
week's
I
believe
weekly
thing:
it
is
September
the
30th,
2008,
19,
I,
believe
and
yeah
as
every
week
we
sync
stuff
between
team
members
and
if
there's
any
other
Jen
Islands,
we
just
go
through
the
minute,
discuss
them,
but
we
start
with
coming
what
we
did
last
week.
So
I
start
with
myself
and
I
am
worked
mostly
on
the
like
zebra
stuff.
A
For
us
lamb,
there
is
prototype
for
it,
which
is
linked
in
the
notes
and
but
it
needs
a
special
version
of
the
sieve
of
Arzo,
which
probably
won't
be
merged
upstream.
So
it's
just
yes,
I,
said
a
prototype,
and
why
this
this
way
can
be
read
in
an
exploration
report.
I
wrote
and
have
also
the
quest
linked
to
the
notes
and
it's
so.
The
short
version
is
that
I'm
surveying
the
major
library
in
rust
that
has
the
civilization,
II
civilization,
doesn't
support
eggs.
But
that's
something
we
need
for
the
Seabourn
coding,
stuff
and.
A
B
Well,
I've
been
having
a
ball
lately,
mostly
miss
trying
to
figure
out.
Could
you
natively
typed
pleasant
to
use
builders
for
IP
OB
nodes
that
have
been
made
by
code
gen,
which
is
itself
a
mouthful
and
trying
to
figure
out
how
those
should
look
and
how
they
can
be
both
correct
and
good
performance
and
feel
good
holistically
like
be
organic?
Is
there's
really
turning
out
to
be
a
noodle
maker?
It
is
I,
think
some
of
the
territory
that
we
are
probing
with
this
is
legitimately
really
uncharted.
B
I've
been
comparing
to
lots
of
other
systems
that
do
some
kind
of
Cochin
in
go
and
lots
of
things
use
pointers
to
represent
optionality,
which
is
one
of
the
few
tricks
that
you
can
possibly
use
within
the
limitations
of
go
syntax
that
everybody
is
going
to
at
least
recognize,
but
it's
also
really
Genki.
It's
not
correct
to
our
model.
B
The
ergonomics
are
surprisingly
not
great,
and
the
performance
is
also
now
that
I've
been
looking
at
it
in
detail,
not
great.
If
you
have
to
always
have
something
that's
going
to
almost
certainly
turn
into
a
heap
allocation.
Every
time
you
want
an
optional
field,
that's
just
like
concretely
really
bad.
It
turns
out
some
of
my
first
drafts
of
different
ways.
We
can
go
there.
Patterns
I
was
trying
to
figure
out.
Oh
if
I
do
a
struct
literal
here
versus
functions
here
is
the
function
overhead
going
to
be
like
really
bad
and
painful
turns
out.
B
No
is
actually
totally
irrelevant,
like
nanoseconds,
that
can
be
disregarded
compared
to
the
cost
of
creating
a
bunch
of
pointers
that
fail
escape
analysis
and
cost.
Keep
allocations
represent
optionals
that
are
present.
That's
actually
the
dominant
cost
of
the
system
that
I've
tried
so
far
or
cosmic,
so
that's
kind
of
a
wild
like
that.
Just
blew
my
because
this
is
all
the
other
things
out
there
doing
like.
C
B
Thing
is
the
ergonomics
also
completely
suck,
though,
if
you
want
to
get
yeah
I
mean
sorry
they
do
like.
If
you
want
to
get
a
pointer
to
an
integer
and
go,
you
have
to
write
yourself
a
helper
function,
basically,
because
you
have
to
put
it
somewhere
in
some
names
variable
in
order
to
take
an
address,
so
you
can't
just
put
an
ampersand
in
front
of
the
number
one
that
doesn't
compile.
So
so
it's
just
it's
all
bad.
B
So
there's
a
gif
that
has
a
bunch
of
those
options
explored
at
least
it's
a
little
bit,
which
most
of
you
have
probably
already
seen.
The
performance
is
really
interesting,
and
so
out
of
all
this
I
still
don't
have
a
final
solution,
but
it's
questions
are
getting
asked
and
answered.
So
it's
getting
closer
I
hope.
I
would
really
like
to
do
something
that
is
more
ergonomic
than
what
it
seems
to
be
centering
it
around.
But
my
hopes
and
dreams
are
probably
for
a
barrier.
That's
impossible.
I've
been
thinking
fondly
of
Ruby
syntax.
Lately.
B
D
So
I
did
a
little
bit
of
scheme
of
stuff
last
week,
not
much
and
I
spent
a
lot
more
of
last
week
going
into
far
coin
and
trying
to
figure
out
how
it's
using
IPL
D
and
it's
blocking
Cody.
Oh
that's
off
interesting
I'll
say
that
it's
interesting
so
I
don't
know.
Yeah
I
don't
feel
like
I've
had
the
most
productive
week
like
producing
things.
I've
also
had
I
mean
I've
been
dealing
with
neck
neck
and
back
problems
for
four
months
now,
not
a
particularly
bad
week
last
week.
D
C
C
C
It
turned
into
a
bigger
hack
and
a
bigger
hack
and
a
bigger
hack,
and
now
it's
it's
really
starting
to
show
so
there's
just
a
much
better
approach
that
the
whole
thing
can
take
in
a
much
cleaner
one.
It
just
needs
to
happen,
so
that's
gonna
be
a
few
days
of
my
time,
just
kind
of
finish.
It
again
we'll
be
here
to
do
and
just
go
like
okay
so,
and
we
need
a
couple
days
to
read
it,
but
that's
like
a
few
days
where
I'm
not
making
progress
on
anything
else
and
yeah.
C
That's
that's
all
that
I
have
for
my
updates,
just
as
a
discussion
topic,
though
I
like
us
to
talk
about
documentation
in
particular.
We
we
really
just
don't
even
have
Docs
right
now.
We
don't
have
anything
that
I
would
like
call
Docs
and
it's
unclear
where
that
should
go
like
there's
an
empty
docs
repo
that
I
deleted,
there's
a
book
that
has
like
a
half
of
a
page
in
it,
but
there's
a
website
that
is
wildly
out
of
date.
We
we
need
to
kind
of
pick
where
documentation
should
go
in
q1
of
next
year.
C
We'll
probably
do
like
a
bigger
push
on
writing
it,
but
I
don't
want
to
stop
anybody
from
writing
documentation
this
quarter.
If
it's
something
that
you
feel
like
you
want
to
do,
or
you
know
we
we
end
up
talking
with
somebody.
You
know
like
I'd,
really
like
this
thing,
to
be
documented
better
before
I
talk
to
this
person
that
I
can
point
to
something:
I
wants
to
figure
out
where
that
should
go
now,
so
that
people
want
to
do
it
in
this
corner
they
can
and
they
are
blocked
on
it.
C
So
yeah
I
think
my
preference
at
this
point,
because
we
have
basically
nothing
there's
to
try
and
put
stuff
into
the
book
so
that
we
can
at
least
keep
in
mind
some
kind
of
linear
narrative
for
people
learning.
This
stack,
rather
than
just
a
hodgepodge
of
a
bunch
of
pages
on
things,
but
open
to
other
people's
suggestions.
C
C
C
B
D
B
C
Well,
yeah
I,
don't
know
no
well,
did
we
throw
any
more
I
mean
other
than
having
just
like
a
landing
repo
I.
Don't
think
that
we
really
use
it
yeah
everything
went
in
specs,
no
I.
Think
like
look
I,
don't
want
to
change
the
coordination
point
for
us
or
frankly,
for
other
implementers,
so
the
specs
remote
will
remain
the
place
where
we
document
things
for
other
implementers,
and
we
definitely
should
not
jump
to
writing
user-facing
docs
for
something
that
we
don't
even
have
documented
for
the
implementers.
C
This
whole
conversation
is
about
documentation
for
people
outside
of
it
for
people
that
would
want
to
just
use
something.
So
if
somebody
wants
to
use
schemas
and
not
be
implementing
schema
like
generation
libraries
of
parsers,
this
would
be
a
resource
for
them
and
I
definitely
don't
want
that
to
go
into
the
spectral
book.
I
do
want
to
maintain
that
separation,
but,
yes,
nobody
should
take
on
doing
this
unless
they
have
a
clear
reason,
like
they're
they're,
literally
working
with
somebody
to
to
adopt
an
assertion
to
make
that.
A
Sure
I
agreed
to
this
separate
repository,
but
currently
there
is
basically,
as
I
said,
there's
not
that
much
to
put
in
there,
because
I
Curley
actually
certainly
not
end-user
facing
because
like
well.
You
there's
no
implementation
for
you
like
for
most
of
the
stuff,
there's
no
implementation.
So
at
the
moment
you
I
mean
you
can
use
the
own
stuff
yeah.
C
So
it
depends
on
who
we
mean
by
like
the
audience,
for
this
is
very
broad
right
so
like
we
could
write
better
documentation
for
the
file
Korn
coin
folks,
who
are
using
schemas
right
now
and
keep
adding
features
that
don't
map
with
our
thing,
because
we
don't
have
our
thing
documented
for
them.
We
have
it
documented
for
implementers.
C
We,
you
know,
like
we've,
been
talking
to
you
through
them
folks
a
bit.
If
we
want
to
do
a
bigger
if
they
seem
open
to
actually
adopting
some
of
the
stuff
and
if
you're
in
them,
you
would
want
to
produce
better
documentation
for
them
as
well.
Along
similar
lines,
yeah
I
agree
that,
like
the
things
that
don't
have
the
implementations,
we
should
not
try
to
document.
C
A
C
So,
like
our
whole
way
of
thinking
about
building
data
structures
and
that
field,
E
is
not
really
documented
in
in
a
way
that
somebody
could
understand
like
it.
You
know
we
have
some
documents
in
this
factory
poem
that
outlines
and
vision,
stuff
and
some
other
sort
of
guardrails
but
like
unless
you've
been,
but
us
for
a
long
time.
You
don't
really
understand
that,
like
that's
where
we
reckon
style
with,
like
you
know,
Stephen
like
which
direction
that
things
are
going
in
right.
C
That
it's
just
not
clear
to
anyone
outside
of
this
group.
So
if
we
expect
people
to
adopt
it
or
understand
it,
we
believe
the
documentation
and
I
think
that
this
is
becoming
a
bigger
problem,
not
not
just
with
external
folks,
like
aetherium,
but
even
with
people
over
on
file
coin,
like
their
their
heads
down
doing
final
coin.
They're
not
like
you
know,
up
to
date
on
our
terminology
and
data
model
and
I.
B
Think
one
of
the
highest
value
ads
that
we
could
get
would
be
like
focusing
on
a
one-pager
approximately
amount
of
content.
That's
just
intentionally
an
introductory
like
narrative
structure
and
goes
over
a
bunch
of
those
things
you
just
enumerated
and
just
has
like.
Maybe
a
sentence
for
each
of
the
things
is
like
you
know,
I
appeal:
D.
We
have
this
concept
space.
It's
for
handling
this
task.
B
If
you're
interested
in
this
user
story
start
here
and
like
just
like
a
very
small
grabbing
information
like
that
and
then
just
dump
people
back
to
spec's
after
that
yeah,
that's
not
the
complete
documentation
story
well
in
the
long
run,
but
it
just
having
that
sort
of
table
of
contents.
That's
focused
on
user
stories
would
be
a
huge
step
forward.
I
think.
C
C
B
C
B
C
Yeah
I
mean
at
least
we
have
a
thing
to
point
people
at
like
it.
We
do
not
currently
have
a
great
landing
page
to
pointy
black.
The
website
is
not
really
in
line
with
our
recent
work.
Even
the
IPO,
the
landing
page
is
a
pretty
out
of
date,
and
so.
D
A
A
Obviously
people
would
go
like
if
people
want
to
get
like
like
universe,
the
book
they
will
go
to
the
website.
Obviously
I
mean
the
the
normal
entry
point
is
the
website.
I
would
say
and
then
yeah
this
fight.
Okay,
yeah,
that's
the
sort
of
interest
to
me
because
they
get
something
will
be
different.
So
let.
C
Me
kind
of
recalibrate,
let
me
kind
of
because
we
yeah
a
lot
of
this
stuff
needs
to
get
fixed,
I'm
targeting
kind
of
next
year
to
fix
most
of
it.
What
I
want
to
do
is
like
if,
in
the
next
three
months,
we
need
to
write
one
of
these
pages
for
a
reason
that
it
goes
somewhere
that
is
actually
working
towards
the
solution
of
these
larger
problems
rather
than
contributing
to
that's
that's
my
main
goal
like
I.
C
C
A
But
I
get
like
I
would
say:
that's
that's
not
gonna
work
anyway.
So
if
I
write
a
page
about
I,
don't
know
about
selectors
for
song,
because
this
is
what
I
could
work
on.
I
would
put
it
somewhere
in
the
book
repository
perhaps,
but
we
surely
find
out
that
this
is
not
the
right
place
for
this
thing.
So
I
don't
know,
in
fact,
if,
but
anyway,
like
I'm
totally
over,
so
I
don't
care
if
the
repo
service
called
talk
or
if
it's
called
book
whatever.
D
Something
along
the
lines
of
Eric's
suggestion
of
like
we're,
investing
a
lot
in
the
specs
repo
we're
putting
a
lot
of
stuff
in
there
and
and
we
are
trying
to
improve
the
even
the
user
facing
nature
of
a
lot
of
the
docks.
But
it's
not
discoverable.
It's
not
something.
People
are
going
to
go
digging
through
so
having
something
that
it
serves
as
a
jumping-off
point
for
more
detail
on
things
that
could
potentially
be
expanded
over
time.
D
But
it
goes
into
a
little
bit
of
detail
about
each
of
these
things
and
says:
if
you
want
more
information,
then
you
should
go
this
place
and
look
at
the
resource
and
then
and
then
we
know,
we've
got
one
place
to
have
detail
and
we'd
have
to
do
the
deduplication
if
it
I
just
I
mean
I
I,
like
the
idea
of
better
docks,
really
do
but
I,
don't
I,
don't
see
how
we
can
keep
something.
That's
verbose,
updated
as
we're
changing
stuff
in
in
multiple
locations.
D
C
So
like
the
thing
about
how
to
write,
schemas
is
just
the
readme
in
the
scheme,
this
directory
the
thing
about
how
to
read
selector
for
the
idea
behind
selector,
so
that
the
readme
in
the
selectors
directory
and
then
we
can
just
we
can
differentiate
for
now
between
all
user-facing
stuff
and
whorin,
implement
or
focus
stuff
just
based
on.
If
it's
a
readme
or
not
okay.
Let's
do
that
and
then
we'll
get
more
content
and
then
once
we
once
we
have
more
together
we'll
decide
what
we
want
to
do.