►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2020-12-07
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
It's
I
don't
have
that
much
of
an
update.
I
can
also
still
work
on
my
blog
storage
kind
of
thing
for
content,
address
data
and
currently
mostly
ficoine,
and
it's
so.
The
exciting
news
is
that
it
now
actually
works.
So
if
you
go
to
the
repository,
you
can
try
it
out
and
play
with
it,
because
I've
now
verified
it
with.
So
it
was
a
dump
of
so
a
car
file
from
frye
coin,
with
around
750
gigabytes,
and
I
was
able
to
recreate
the
file
based
on
my
index
and
also
like.
A
I
have
a
tooling
that
kind
of
prints
out.
What's
in
there
and
it's
like
sounds
looks
now.
It
sounds
correct
because,
like
first
it
was
too
good
to
be
true
and
it
actually
was
too
good
to
be
true.
But
now
it
looks
sensible,
so
yeah
so
check
out
the
source
code,
and
currently
the
work
goes
into
a
ffi
that
I've
done
in
now,
like
friday,
we
work
on
doing
a
go
binding,
so
we
can
try
it
with
the
benchmarking
suite
for
lotus
to
see
how
fast
it
is
compared
to
other
stores.
A
So
I'm
excited
to
see
the
results
there
yeah,
but
so,
if
anyone's
watching
this
one
and
it's
not
into
filecoin,
it
is
really
about
like
storing
content-based
data,
so
it
could
also
be
used
for
ipld
or
even
ipfs.
So
that's
certainly
also
something
I
will
look
into.
If
we
can
yeah
how
good
it
will
fit.
Those
use
cases-
that's
all
I
have
next
on.
My
list
is
danielle.
B
Cool,
so
something
we
started
with
last
week
was
the
big
refactors
in
ipld,
prime,
as
in
the
backwards
and
compatible
changes.
The
first
one
was
removing
the
error
returns
from
the
as
boolean
as
string
and
so
on
methods.
B
I
actually
got
pretty
far
in
that,
because
we
wanted
to
automate
the
changes
downstream
from
all
the
live
to
all
the
libraries
that
use
ipl
d,
prime.
But
after
talking
to
eric
for
a
while,
we
realized
that
we
actually
do
want
to
still
keep
the
error
returns
around.
And
I
don't
know
if
you
want
to
talk
about
that
later,
but
I'm
not
going
to
get
into
the
details
right
now,
but
the
gist
of
it
is
adls.
B
Adls
do
want
to
use
the
errors
and
removing
the
errors
from
the
adl
is
a
bad
idea
so
now
on
to
the
second
0.7
breaking
change,
which
is
to
use
n64
for
sizes,
because
in
a
bunch
of
places
right
now,
they're
just
integers,
which
is
going
to
be
bad
and
on
32-bit.
B
I
also
worked
with
martin
quite
a
bit
on
ci,
because
he's
sort
of
leading
an
effort
to
make
our
use
of
github
actions
a
little
bit
more
consistent
and
that
sort
of
goes
in
line
with
what
I
was
thinking
of
defining
what
the
best
practices
for
ci
for
go
are.
So
I'm
helping
him
review
and
test
that
stuff
and
we're
using
the
ipld
work
as
a
sort
of
guinea
pig
for
this
stuff.
B
So
I
might
continue
to
do
that
with
the
more
complex
ones
if
he
needs
that
it
doesn't
take
a
lot
of
my
time
and
there
was
also
a
proposal,
a
sort
of
draft
go
proposal
that
I
started
two
weeks
ago
stemming
from
something
that
I
think
it
was
an
ipfs
developer,
brought
up
on
slack
about
a
common
bug
that
they
have
with
type
assertions
and
on
map
of
map
indexes.
So
that's
the
link
on
hackmd.
B
So
I
think
maybe
I
should
propose
it
as
a
some
sort
of
static
analysis
check,
either
in
vet
or
in
something
like
static
check.
But
I
feel
like
both
of
them
would
tell
me.
No,
so
I'm
kind
of
I'm
not
sure
what
I'm
gonna
do
anyway,
and
the
last
thing
is
that
I
happened
to.
I
happened
upon
how
go
ipfs
use
channels
for
iterators,
and
I'm
really
not
happy
about
it.
B
So
I
left
them
a
nice
comment
explaining
how
I
think
they
could
do
it
better
because
channels
and
go
exposing
them
in
apis
is
possible,
but
it's
very
thorny
and
I
think
it
should
be
avoided
and
the
way
they're
doing
it
is
just
to
avoid
writing
some
boilerplate,
which
is,
I
think,
the
wrong
trade-off
to
make
for
goei
apfs,
which
has
you
know
so
many
users,
and
that's
it
for
me.
C
Eric,
yes,
we
tried
to
do
some
api
changes
this
week
and
as
daniel
mentioned
we
backed
down
when
we
got
closer
to
it.
C
I
think
he
already
summarized
it
pretty
well,
we
were
trying
to
remove
a
bunch
of
errors
from
the
core
node
interface
in
the
new
go
libraries,
because
errors
are
frustrating
and
it
turns
out
that
we
really
can't
primarily
for
the
use
case
of
adls,
and
we
even
were
flirting
with
the
idea
of
like
well.
Okay,
maybe
maybe
adls
could
panic
and
use
that
as
their
error
handling
pathway,
but
like
no.
C
If
we
want
the
overall
contract
of
the
node
interface
to
include
adls
can
be
operated
on
transparently,
and
you
don't
need
to
know
that,
that's
what
you're
doing
then.
We
don't
want
to
have
feature
detection
for
this
and
we
don't
want
to
have
different
error
handling
strategies
for
them.
So
we
are
still
stuck
with
returning
errors
from
the
core
node
interface,
so
we're
just
going
to
have
to
find
more
ways
to
build.
Helper
libraries
and
convenience
functions
around
that.
C
C
Can't
be
done
all
right
moving
on
so
as
we're
still
preparing
to
do
a
couple
of
other
minor
api
changes
well
more
minor
than
that
one.
I
updated
the
change
log
for
everything.
That's
happened
since
the
last
time
we
tagged
or
released
in
that
repo,
which
has
been
a
while.
C
I
found
a
little
bit
of
unfinished
work
around
codegen
struct
types
were
not
finishing,
the
validation
that
all
required
fields
are
present.
So
now
it
does
will
had
actually
done
some
work
on
this
for
the
representations,
but
we
haven't
done
it
in
the
type
level.
So
I
put
it
in
there
as
well.
Maybe
error
messages
nicely,
tell
you
missing
field
name
and
the
serial
form
as
well.
If
those
are
different.
C
C
So
in
go
ipld
prime.
I
think
we're
ready
to
tag
the
0.6
probably
now
and
then
after
that,
we'll
start
doing
the
interesting
changes
and
I'm
thinking
unless
anybody
else
has
other
direct
feedback,
I'm
probably
going
to
keep
pushing
on
some
of
the
new
codec
work
and
trying
to
move
towards
that
refactor
of
the
linking
api.
That's
been
kind
of
a
long-term
goal
and
try
to
make
some
progress
on
that
the
rest
of
the
week.
C
I'm
kind
of
hoping
that's
going
to
be
a
january
thing,
but
we'll
see
I'm
probably
going
to
want
to
make
sure
that
we
do
things
right
and
get
lots
of
benchmarks
in
this
and
stuff.
So,
like
the
timing
is
tbd,
that's
it
I'm
starting
to
review
rod's
coolness
stuff,
but
I
haven't
got
much
yet
so
sorry,
I'm
slow.
A
Thanks
next
is
rob.
D
So
just
minor
stuff
for
me
and
had
a
little
bit
tiny
bit
of
time
off
so
mostly
go
actually
reflecting
back
on
the
week,
lots
of
little
maintaining
things,
helping
fix
bugs
in
go
cid
and
other
places
related
to
ipfs
participating
in
discussions
with
file,
coin
actors,
people
about
hamps
and
amps
algorithms
and
data
layouts
and
stuff.
So
one
interesting
thing
bubbling
out
of
that
for
awareness
is
that
the
actors
version
three
will
have
the
kind
of
union
implemented
and
the
keyed
union
removed,
which
is
nice
because
it'll
save.
D
I
think
I
think
I
worked
it
out
as
96
bytes
per
full
node
on
the
hand
and
and
gets
rid
of
the
only
place
where
maps
are
used
in
dioxibor
in
falcoin,
but
that
that
brings
up
other
questions
which
we'll
get
to
later
in
the
meeting
about
adls,
because
there's
now
two
different
formats
of
hands
there's
also
two
different
formats
of
amts.
D
And
oh
yeah,
dag
pb
I've
cleaned
up
work
that
I've
been
working
on
for
way
too
long,
so
this
tag
pb
and
go
stuff.
I
cleaned
that
up
for
with
that
ipld
front
end
I
said:
go
iply
prime
front
end
and
it
works
as
a
codec,
not
super
happy
with
it.
D
E
Right
hi
guys
so
not
not
much
from
me
on
type
you'll
decide,
we
are
even
closer
to
the
mudra
becoming
becoming
a
thing.
Finally,
we
have
some
test
deals
that
went
through
correctly.
People
are
getting
their
power
increased,
so
things
are
working
more
work
on
trying
to
figure
out
exactly
how
we
want
to.
E
I
mean
how
I,
how
I
want
to
store
the
chain
in
a
way
that
will
allow
basically
this
this
thing
to
grow
to
at
least
100
terabytes,
without
without
rearranging
anything.
E
I
think
I
have
the
very
final
schema
now
in
place
that
captures
everything
that
we
need
from
multiple
work
streams,
so
both
being
able
to
pull
a
bundle
of
blocks
so
basically
have
like
a
mini
mini
selector,
with
with
a
fixed
depth
of
source,
directly
directly
increment
on
database
level
being
able
to
navigate
just
the
chain
itself
without
getting
into
into
the
width
of
status
and
so
on,
and
so
forth
being
able
to
do
actual
chain
exports
as
well,
almost
directly
from
the
database.
E
I
did
drop
a
link
to
the
preliminary
schema
in
fill
in
the
in
the
analysis
channel,
so
it's
posted
there
as
well
and
yeah
other
than
that
I've
been
with
got
one
to
a
number
of
work
streams
around
the
base
with
spike
and
stuff
like
that
messaging
around
that
and
that's
taking
an
obscene
amount
of
time
so
yeah,
that's
pretty
much
all
I
have,
and
I
have
an
agenda
item
for
later.
F
I
I
cleaned
up
the
graphql
stuff,
that's
in
a
repo
in
ipld,
or
I
should
talk
with
martin
and
ann
about
getting
all
of
these
fancy.
Github
actions
and
workflow
checks
enabled
on
that
repo.
I
saw
the
github
repo
and
I
guess
I
need
to
pr
there
to
have
it.
Do
a
action
to
submit
prs
to
my
repo,
so
I
will
work
through
that
figuring
out
testing
strategies
for
that
other
than
that
front-end
stuff,
keeping
the
service
up
thinking
a
little
bit.
F
I
I
started
on
the
design
dock
around
how
we're
dealing
with
messaging
the
stuff
peter's
been
doing
the
infrared
side.
People
are
all
very
excited
for
this
to
exist,
so
a
lot
of
trying
to
run
interference
to
have
us
not
build
other
things.
While
we
wait
for
it.
F
A
Thanks
and
I
can
see
that
chris
doesn't
have
an
update,
so
thanks
for
letting
me
know,
and
so
we
come
to
the
agenda
items
first,
one
is
a
gohan
adl
question.
Oh
several
questions
yeah,
whoever
posted
it.
Please
tell
me.
D
This
one's
daniel
and
me
posing
questions
for
the
group
and,
I
think,
will
is
in
a
good
position
to
help
answer
these
questions.
So
we've
now
got
so
we're
focusing
on
the
hampt,
but
the
the
same
questions
go
for
the
amt.
If
we
get
there
daniel's
building
an
adl
for
gopd
iple
prime,
we
now
have
two
versions
of
the
hampt
four
file
coin,
and
these
questions
were
just
about
the
value
of
supporting
all
the
versions
of
the
file
coin
data
layout
or
aiming
for
latest
one.
D
I
think
if
we
were
to
if
we
were
to
like
there's
two
goals
here,
there's
the
you
know
showing
up
to
act
as
people
and
saying
hey,
you
should
be
able
to
use
iple,
prime
in
your
work
and
here's
a
good
way.
Adls
fix
all
these
issues
with
the
way
that
you're
navigating
the
tree.
F
So
I
mean,
from
my
perspective,
the
state
routes
are
versioned,
so
it's
easy
for
me
to
have
different
schema
types
on
those
different
state
route,
things
which
are
keyed
off
of
the
epoch,
so
using
the
current
amp
implementation
for
things
now
and
then
only
switching
to
the
adl
amp
when
the
transition
to
actors
v3
happens,
so
I
don't
think
for
the
analysis,
side,
workload,
there's
really
going
to
be
any
particular
objection
to
them
only
supporting
the
new
style
hands.
B
I
think
so,
at
least
from
my
side,
because
I
think
supporting
two
versions
of
this
sorry
supporting
two
schemas
at
once.
If
they're,
if
they
only
have
minimal
differences,
is
reasonable
in
terms
of
it's
still,
mostly
being
a
single
adl
or
at
least
sharing
a
lot
of
the
code.
But
if
there's
three
versions
where
the
oldest
one
has
significant
changes,
then
it's
significantly
more
difficult.
I
think.
A
D
They
have
different
code
bases
for
the
different
versions
of
actors,
so
as
you
as
you
and
you
can
look
in
lotus
and
you
can
see
it
actually
links
to
different
branches
on
specs
actors.
So
when
you
get
to
a
certain
point
in
the
chain,
you're
using
entirely
different
code
base
to
navigate
it,
I
can
it's
going
to
get
out
of
hand.
One
day
it's
going
to
be
like
how
many
versions
do
we
have
and
how
many
different
code
bases
and
then
maintain.
D
Codes,
I
just
just
even
things
like
there's
a
new
version
of
go
and
we
need
to
fix
all
of
the
old
stuff
to
compile
on
the
new
version
of
go
like
yeah,
so
there's
also.
There
is
also
this
other
thing
in
the
hampt,
where
the
falcon
hemp
uses
big
end
for
its
bit
field
and
and
that's
not
something
that
we
do
or
want
to
support
for
a
generic
hempt.
D
I
did.
I
tried
to
get
that
fixed
before
mainnet,
but
it
was
just
too
late
and
then
there
was
a
discussion
about
doing
it
for
v3,
but
the
the
benefits,
just
I'm
just
not
big
enough
to
bother
in
file
coin.
So
we
sort
of
stuck
with
this
quirky
bit
field
in
the
far
coinhampt
that
we
don't
want
to
support
for
our
generic
hampt.
So
there's
questions
about
divergence
about
multiple
code
bases
and
yeah,
so
I
I
think
I
think
something
for
daniel
and
the
guidance.
D
The
helpful
guidance
would
be
more
about
what
is
what
is
the
most
useful
target
for
development
here?
Is
it
developing
an
adl
that
works
on
specs
actors,
v3
that
can
be
used
to
look
at
the
current
chain
and
possibly
offer
it
to
the
specs
actors
team
as
a
drop-in
replacement,
or
is
it
to
work
on
something
better?
D
That
is
more
generic,
that
we
could
offer
them
for
them
for
a
v4,
or
is
it
to
work
on
older
stuff,
an
older
version,
so
we
can
expect
older
work.
This
is
a
it's
a
question
of
you
know
the
biggest
biggest
value
for
work
that
I
don't
have
a
good
answer
to.
F
I
mean
I
can
say
my
sense
is
that
third,
one
is
not
the
one
where
the
value
is
that
for,
from
my
perspective,
the
as
soon
as
we
get
a
real
ipld
node
compatible
amped
as
the
thing
that's
being
used
as
the
hampt.
That
makes
my
life
easier
and
means
that
we
can
then
do
ipld
style,
traversals
and
things
like
that
and-
and
that
gets
us
a
bunch
of
benefit
in
that
then
subsequent
processing.
F
As
soon
as
we
can
start
meeting
those
interfaces,
we
don't
have
to
think
about
subsequent
versioning,
quite
as
bad
or
it
becomes
a
little
less
bad
right,
which
is
if
I
can
still
pass
through
the
hampt,
and
it's
got
that
adl
level
that's
great,
and
if
it's
not
fully
optimized
and
we've
had
to
make
some
compromises
and
we
fix
those
with
a
different
version
later.
As
long
as
the
like,
I
can
still
pass
through.
It
works.
The
same
we've
saved
ourselves
having
to
rewrite
analysis
code.
F
So
I
think
this
is
one
where
I
would
say
the
the
good
rather
than
perfect
and
get
it
in
is,
from
my
perspective,
the
highest
value.
D
That
the
specs
actors
team
are
not
going
to
take
a
upgrade
within
a
major
version
to
anything
major,
even
if
it
was
the
same
format.
It's.
I
think
my
understanding
of
the
way
they're
working
is
once
they
commit
to
a
version
and
it
gets
rolled
out
that
code
base
is
really
just
in
maintenance
and
things
get
fixed,
but
otherwise
they
don't
tend
to
try
and
touch
it
very
much
because
of
all
these
gas
calculations
and
the
rest
of
it.
D
So,
while
developing
a
an
adl
for
the
current
version
of
of
it
makes
sense,
I
don't
think
we
should
go
in
with
the
expectation
that
they're
going
to
replace
their
current
version
with
an
adl
and
ipld
prime,
it's
more
likely
something's
going
to
happen
in
a
major
version
upgrade.
So
I
I
don't
know
what
that
means.
I
mean
that
that
does
mean
that
there's
there's
scope
there
for
actually
changing
the
format
and
the
schema,
but
it
doesn't
mean
that
we
should
so
yeah.
D
D
And
and
yeah,
and
we
did
pull
in
in
some
a
discussion
about
changing
the
bit
field.
I
I
pulled
in
the
what's
his
name
from
chainsafe
who's,
doing
the
rust
implementation.
D
F
Hunch
is
the
best
value
would
be.
My
other
thought
on
the
bit
field,
specifically,
is
the
reality
is
if
you
are
doing
any
sort
of
chain
analysis
in
whatever
language
you
have
reimplemented
the
go
bit
field,
because
it
appears
not
just
there,
but
in
plenty
of
places.
So.
D
D
Yeah,
that
was
my
point
there
as
well,
except
for
the
fact
that
this
is
the
in
this
particular
place.
It's
used
in
a
very
novel
way
accessing
individual
bits
of
it,
so
you
actually
need
to
implement
even
more
of
the
go
bitfield
than
you
do
just
to
read.
Them
read
and
write
them,
but
yes,
that's
that
that's
yeah
when
I,
when
I
was
doing
doing
the
schemas
for
the
chain,
I
didn't
realize
in
the
beginning
how
how
much
big
int
was
used
and
it's
used
everywhere.
C
D
If
you're
writing
that,
if
you're
writing
code
for
the
falcoin
chain
in
any
other
language
you're
in
the
source
code
of
big
into
figuring
out
what
it's
doing
so,
my
hunch
is
that
the
best
best
bang
for
buck
would
be
working
on
the
specs
actors,
v3
format,
which
is
the
kind
of
union
and
then
adding
in
anything
else.
After
that,.
B
Yep,
I
agree
so
essentially
just
supporting
that
schema
initially
and
once
it's
working
well,
I
can
think
about
what
to
do
to
support
the
proper
new
schema,
some
way
be
it
like
a
separate
package
or
whatever
it
is
just
so
that
I
understand,
is
this
v3
of
actors,
the
next
version,
or
is
it
the
current
version?
Yeah.
D
B
Oh,
so,
even
though
v3
is
the
next
one,
it's
probably
a
little
too
late
to
suggest
replacing
the
implementation.
At
this
point.
E
B
B
D
No,
I
I
I
might
put
it
to
oh.
I
think
I'm
probably
talking
to
wyatt
again
this
week,
so
I
might
bring
it
up
with
him.
But
you
know:
we've
got
this
conflict
here,
a
conflict
of
approaches
where
they're
very
much
a
product
team
and
we're
not-
and-
and
so
we
can't,
like
their
goals-
are
very
short
term
they're-
very,
very
rigid,
because
they
need
to
get
these
things
out
in
particular
time
frames,
and
so
we're
going
to
have
trouble
coming
to
them
with
anything
yeah.
D
E
A
question
on
things
being
plugged
in,
I
thought
the
fit
for
the
amt
changes
just
went
out
like
today.
E
Okay,
this
is
what
I
might
miss
remember,
okay,
yeah,
and
this
is
probably
for
before
right.
That's
not
what
we
do.
D
There's
yeah
there
is
there.
Is
there?
Probably
I
don't
know
if
there
was.
I
assume
there
was
a
fit
for
the
amt
because
it
changes
bit
width
too,
but
the
ham
coin
got
got
merged,
but
it
got
merged
at
the
same
time
that
all
the
code
got
merged.
So
all
that's
all
done
so
all
right,
okay,
yeah,
never
mind.
I'm!
I'm!
I'm
crossing
my
wireless
nevermind.
E
Stuff
yeah,
it's
not,
I
I'm
not
sure
who
changed
the
who
changed
the
the
topic.
It's
not
who
changed
the
question.
It's
not
specifically
about
the
ideas.
It's
basically
in
general
people
are
collabs,
are
coming
to
you
and
are
asking
her
for
what
is
our
like?
E
What's
our
guidance,
as
you
know,
as
protocol
labs
for
building
more
advanced
stuff
and
whether
there
is
something
some
set
of
schemas
or
anything
like
this,
that
we
can
link
people
to
at
this
point
if
anything
exists
not
specifically
for
the
ids,
the
ids
was
only
one
of
the
examples.
E
I
I
I
don't
know
the
answer
to
decider,
so
I
know
rod
eric
that
will
be
for
you
guys.
I
guess.
D
Yeah
we
got
it,
we've
got
to
I.
I
assume
that
this
is
coming
from
from
ava
to
who's
doing
grand
stuff.
Okay,
who's
got
very
good
connectivity
with
the
ecosystem,
but
this
is.
This
is
very
language
dependent.
Unfortunately,
if
you're
doing
stuff
in
go,
then
our
advice
is
very
much
to
every
it's
to
push
people
towards
ipld,
prime.
E
Her
question
is
on
a
more
basic
level,
not
in
terms
of
like
how
do
I
design
something
for
my
language,
but
how
do
we
get
people
to
basically
build
the
merkle
forest
by
just
applying
a
common
set
of
things?
So
it's
explicitly
not
language
dependent
but
more
like
what
should
people
be
doing
so
that
others
can
interoperate
with
them
at
a
later
date?.
C
We
need
more
docs
work.
I
guess
surprise.
I
think
we
probably
have
some
documentation
for
this
is
that
is
decent,
but
it's
probably
not
discoverable,
like
I
think,
there's
the
primer
document
that
I
wrote
around
the
time
that
daniel
was
joining
us.
I
think
it's
still
really
good
and
we
did
a
bunch
of
editing
work
on
that
as
he
joined
us
also,
which
was
really
useful,
and
we
haven't
landed
that
anywhere
or
I'll
blame
myself.
D
So
is,
is
this
question
about
so
the
last
part
of
the
question
that
makes
me
think
is
this
is
about
what
are
the
off-the-shelf
components
for
data
structures
that
I
can
take
and
not
have
to
build
from
scratch.
Is
that
is
that
what
it's
about
these.
E
Kinda
yeah,
it's
like
again,
like
the
the
question
is
coming
through
on
multiple
layers,
so
it's
difficult
to
get
an
exact
answer.
However,
the
the
meeting
we're
going
to
have
tomorrow.
Probably
some
of
this
will
come
up
with
the
with
the
ethereum.
Well,
not
with
the
syrian
people
but
organized
I
I
think
yes,
they
will
probably
have
something
similar
in
terms
of
need,
but
yeah
like
like
like
stuff
like
the
ideas,
are
very
general
because
you
want
to
apply
them
to.
E
D
My
I
think
my
answer
to
this
would
be,
but
still
I
still
think,
there's
a
language
dependent
thing
here,
because
there's
a
mismatch
in
maturity
where,
where
the
answer
is
different,
depending
on
what
language
you're
doing
things
in,
because
we
can
give
you
off-the-shelf
things
in
go,
we
can
we
can
show
you
some
schema
work.
D
Why
don't
we
have
that
answer,
and
it
seems
like
something
that
we
kind
of
do
have
answers
for,
but
they're
not
organized
enough,
obviously
to
be
able
to
just
say
here:
it
is
so,
maybe
if
maybe
if,
whenever
these
things
come,
that
comes
up
loop,
us
in
I,
I
think
an
email
is
probably
the
easiest
way
to
do
it.
Maybe
just
get
one
or
two
of
us
in
email
and
then
we'll
like.
D
I
did
this
recently
with
some
blockchain
people
and
that
ended
in
some
really
fruitful
discussions
with
dean
and
some
other
people
about
some
various
ipfs
related
things
but
yeah,
I
think,
send
them
to
us.
Let's
have
a
discussion
and
then
we
can
understand
requirements
and
what
we're
missing
and
then
work
on
those
things.
A
I
don't
see
any
other
items
on
the
agenda.
Does
anyone
have
anything
else.