►
From YouTube: Filecoin Core Devs #44 (Meeting 2)
Description
PLEASE NOTE: The slideshow in this video incorrectly listed this as Core Devs meeting #43. It is in fact Core Devs meeting #44.
Recording for: https://github.com/filecoin-project/tpm/issues/102
For more information on Filecoin
- visit the project website: https://filecoin.io/
- or follow Filecoin on Twitter: https://twitter.com/Filecoin
Get Filecoin community news and announcements in your inbox, monthly: http://eepurl.com/gbfn1n
B
All
right
well
welcome
everyone
to
stephen
and
to
alex
this
is
file
coin.
Core
devs
number
43
today
in
the
us
at
least,
is
thursday
june
2nd,
and
this
is
meeting
two
for
our
group
so
today,
as
always,
we'll
go
through
brief
updates
from
each
of
the
implementations
and
then
updates
from
the
file
queen
foundation.
In
particular,
I
want
to
just
flag
the
filecoin
request
for
comment
proposal.
That's
live.
I
think
this
is
something
we
are
also
going
to
need
a
fit
for.
B
So
we
just
wanted
to
flag
for
the
group
and
also
talk
about
some
requested
changes
to
the
format
of
the
core
devs
meeting,
get
everyone's
feedback
and
ideas
about
this
before
a
proposal
goes
up
on
github
also,
and
then,
of
course,
we
can
go
through
the
v16
and
v17
network
upgrades
alex.
I
know
you
wanted
to
talk
about
some
of
the
pending
work
that
the
protocol
ops
group
is
doing,
which
is
great.
We
will
have
time
if
you
want
to
do
it
today.
B
I
think
that's
fine,
but
if
you'd
like,
we
can
also
dedicate
like
a
much
larger
chunk
of
time
at
both
meetings
to
going
through
some
some
of
your
pending
work
in
in
two
weeks
time.
Just
because
there's
still
a
lot
of
open
questions
about
the
version
17
network
upgrade
and
what
kind
of
appetite
there
is
for
a
large
scope.
A
B
Okay,
that
sounds
great
and
yeah.
If
you
want
to
give
us
a
teaser
at
the
end,
we
can
do
that
too.
It's
pretty
informal
great
well,
I
guess
we'll
jump
into
our
team
updates.
Forest
and
lotus
have
been
working
pretty
much
hand
in
hand
over
the
past
couple
of
weeks
on
built-in
actor
unit
tests,
they've
gone
through
hundreds
of
them.
These
are
now
almost
all
complete.
B
Both
teams
are
preparing
to
sync
on
mainnet
and
b16
goes
live,
which
is
great,
and
forest
has
committed
that
they
will
be
able
to
join
the
network
upgrade,
which
is
also
great
news,
because
previously
they
were
worried,
they
would
be
unable
to
do
so.
Any
questions
that
you
want
me
to
pass
to
either
team.
C
Yeah,
okay,
yeah,
thanks
to
those
are
team,
enforced
teams
work,
so
we
have
the
yeah
building
actors
and
available
and
also
the
fm.
So
the
team
is
working
on
the
integration
actually
yeah
we're
following
and
access
closely.
So
currently,
we
are
working
on
the
innovations,
fm
and
building
actors
for
network
operation,
16
upgrade
and
we
plan
to
have
this
test
on
butterfly
network
next
week.
Yeah.
C
We
had
done
some
optimization
on
the
settings
schedule
and
improved
the
cri.
Well,
we
have
the
new
architecture
of
the
vls
cluster.
We
could
have
some
customized
yeah
workers
to
do
the
pro
rip,
just
like
the
plug-in
model.
So
we
we
hope
you
are
different
yeah
because
different
storage
providers,
they
have
their
customized
ceiling
programs.
We
with
this
model
yeah
they
could
use
the
vlas
and
just
you
know,
plug
in
their
yeah
ceiling
excoder
and
it
will
work.
C
C
C
B
I
think
that
sounds
great.
There
were
no
questions
about
any
of
the
work
that
you
have
completed
or
that
you're
planning
to
do
it's
great
that
you'll
be
on
testing
on
butterfly
net
next
week.
There
was
one
question,
as
teams
are
starting
to
think
about
what
may
be
included
in
b17
the
beneficiary
address.
Fifth,
that
you
authored.
The
forest
team
wanted
to
know.
C
B
C
C
C
B
A
I
I
filed
an
issue
in
the
built-in
access
repository.
I
think
yesterday
and
tagged
you
stephen.
The
work
is
mostly
supporting
the
implementation
that
your
team
already
did
in
go,
which
helped
us
flesh
out
the
details
of
the
proposal,
porting
that
change
to
rust,
so
that
it's
in
the
rust
minor
actor
as
well-
and
I
think
that's
that's-
basically,
the
scope
of
it.
B
Cool
thanks
alex
all
right,
so
updates
from
the
foundation.
Paris
is
continuing
to
run
the
bug
down
to
program.
There's
no
pending
security
risks
from
our
side
to
flag
for
anyone
listed,
accepted
fips.
There
are
now
five,
four
of
which
are
going
to
be
integrated
in
v16,
as
we
know,
and
then
hopefully,
fifth
29,
as
mentioned,
will
be
included
in
version
17,
regardless
of
sort
of
the
scope
of
the
entire
upgrade
alex,
saw
your
your
updates
and
some
of
the
mergers
that
you
pushed
forward.
This
is
great
yeah.
B
If
you
want
to
give
us
a
walkthrough
of
some
of
the
fips
that
you're
hoping
to
push
and
sort
of
what
timelines
you're
thinking
about
those
at
the
next
core
devs
call,
then
that
would
be
fantastic
and
jennifer
also
mentioned.
I
think
it's
kuba,
maybe
who
works
with
you
pretty
closely,
could
potentially
present
at
the
other
meeting,
so
that
people
can
ask
questions
live
in
both
sessions.
If
that
works.
B
Okay,
great
so
I
can
reach
out
to
both
of
you
early
next
week.
Just
so
you
can
make
sure
it's
on
your
calendars
and
koopa
can
attend
also,
but
I
think
that'll
be
really
helpful
for
all
the
team
to
hear
all
of
these
things
together.
So
they
know
what
to
to
do
when
thinking
about
again
the
size
of
b17.
B
All
right
so
then,
two
additional
updates,
as
mentioned
one,
is
the
documentation
for
request
for
comment
alex
thanks
for
reading
through
and
adding
your
suggestions.
I
think
all
of
them
are
great
and
I'm
going
to
update
the
language
to
reflect
like
the
sort
of
change
in
emphasis
about
when
something
is
accepted.
B
Stephen,
if
you
haven't,
had
a
look
yet,
if
you
could,
that
would
be
great.
I
think
the
next
thing
to
figure
out
is
what
should
be
required
in
a
request
for
comment
template.
Fortunately,
we
have
a
couple
of
immediate
use
cases
both
with
boost
and
with
the
advertiser
index
protocol
and
potentially
the
ask
v2
protocol,
but
not
sure
yet
so
we'll
use
those
as
sort
of
initial
case
studies
and
what's
important,
but
the
idea
is
that
there
should
be
standardization.
B
C
Yeah,
I
okay,
I
I
how
to
review
some
of
this
document.
If
I
have
any
comments
yeah,
I
could
comment
if
github,
okay,
basically-
and
I
think
this
is
a
good
idea-
is
because
yeah
the
fip
is
yeah.
We
would
the
scope
it
only
for
the
the
the
the
core
development
right,
the
yeah,
the
chair
level,
and
if
I
say
it
will
be
on
the
upper
level
for
the
actors
or
some
community
consensus,
something
like
that
yeah.
That
is
good.
B
Great
yeah
thinking
about
it
more,
as
you
know,
we
have
fips.
We
look
for
this
kind
of
soft
community
acceptance
to
say
that
this
is
something
we're
going
to
implement
and
that's
the
frc's
is
more
to
say:
hey
the
entire
filecling
community
is
kind
of
organically,
attributing
these
things
or
they're,
adopting
these
protocols
or
applications
or
whatever
it
may
be.
Let's
standardize
that
adoption
so
that,
if
there
are,
you
know
new
developers,
new
opportunities
whatever
it
may
be,
they
have
a
single
point
of
reference
for
understanding.
C
Yeah
this
is
all
so.
My
understanding
is
that
they
yeah
they
say.
Frc
is
kind
of
recommendation,
okay,
so
it's
kind
of
standard,
and
so
the
people
can
follow
that.
We
hope
people
can
follow
that,
but
some
people
may
yes,
some
and
some
of
you
stand
out
or
something
like
that.
It's
okay,
it's
because
yeah
it
will
not
broke
your
break.
The
the
consensus
right
yeah!
It's
still
on
this
yeah.
B
Exactly
so,
the
frcs
are
recommended,
but
they
are
also
optional.
So,
for
example,
if
boost
were
an
accepted
frc
and
you
said
that
you
did
not
want
to
integrate
boost
hypothetically
speaking
since
you
are
because
when
you
didn't
want
to
or
you
felt
like
you
had
a
different
protocol,
you
wanted
to
implement
whatever
it
may
be.
You
wouldn't
be
bound
to
do
that.
It's
up
to
you.
B
B
It's
also
true
that
if
we
implement
this
frc
policy
or
system,
it
asks
for
core
devs
to
kind
of
approve
what
is
a
standard
ultimately,
and
so
it's
important.
I
think
that
we
have
like
a
clear
definition
of
what
a
cordev
is,
but
that
we
also
incentivize
people
to
attend
and
participate
in
these
meetings
and
there's
a
couple
of
different
ways
that
we
can
do
that.
So
one
of
the
things
that
we've
proposed
is
changing
the
meeting
format
to
be
once
per
month
in
terms
of
timing.
B
Obviously,
if
someone
else
is
offering
a
fifth
or
has
expertise
and
wants
to
join,
they
could
do
that,
but
it
would
just
be
for
that
one
meeting
and
there
would
be
attendance
requirements.
So,
for
example,
if
you
missed
three
meetings
within
a
period
of
time,
you
are
removed
from
the
meetings
going
forward
to
make
sure
that
we
have
expectations
around
attendance.
B
And
the
idea
for
this
is
that,
with
sort
of
a
stricter
structure,
we
could
sort
of
better
prime
materials
and
agendas
in
advance
to
make
sure
that
everyone
is
on.
The
same
page
has
read
and
reviewed.
Fips
is
coming
to
the
meeting,
ready
to
sort
of
participate
in
conversations
around
decisions
and
that
the
scope
of
conversation
in
general
is
a
little
bit
higher
order
and
isn't
so
much
focused
on
updates
and
sort
of
administrative
decisions.
A
I
I
certainly
agree
with
the
goals
that
were
stated.
They
sound
like
a
great
set
of
things,
to
aim
towards
it's
a
bit
harder
to
judge
whether
any
particular
changes
will
will
achieve
them.
But
I
certainly
in
favor
of
this
this
effort
and
will
your
game
to
experiment
with
some
things.
If
we
do
get
to
a
call
where
people
are
more
prepared
and
we
can
have
some
more
in-depth
discussion
rather
than
exchange
updates,
I
do
think
that
would
be
more
valuable.
B
Yeah,
I'd
love
to
be
able
to
put
together
even
like
a
brief,
even
if
it's
a
more
detailed
agenda
for
everyone
in
advance
and
what
makes
it
difficult
now
is
that
it's
hard
to
know
who
is
going
to
attend
also,
but
also
when
it's
mostly
implementation
teams.
Everyone
is
so
busy
just
maintaining
implementations
and
preparing
for
network
upgrades,
but
it's
hard
to
ask
for
additional
work.
So
yeah,
okay,
cool
yeah
and
fingers
crossed
that
some
of
these
solutions
do
yield
changes,
but
we'll
just
we'll
have
to
play
around
with
that.
I
think.
C
Okay,
here,
yes,
and
before
we
have
this
quality
meeting,
we
have
some
yeah
designers
to
join
the
speaking
yeah.
For
example,
we
have
the
fip.
We
always
have
the
fft
authors
to
get
present
the
ideas
and
as
well
as
you
know,
yeah
behind
the
ffp,
something
like
that,
which
is
very
good
and
I'm
thinking
that
they
appeal
your
the
prolapse
and
actually
have
a
few
yeah
research
teams
right
yeah,
because
the
research
teams
and
then
actually
studying
something
to
overcome
some
challenges
of
the
network.
C
So
I
would
think
that
if
we
could
add
one
section
in
this
meeting
to
need
some
some
researchers
to
do
some
presentation
here
and
we
will
to
to
tonight
the
community
knows
about
the
some
direction
and
some
directions.
Actually,
the
the
whole
network
want
to
take
right
and
to
have
some
yeah
just
give
some
ideas
or-
and
also
you
know,
we
have
some.
C
C
B
B
So
if
they
can
come
and
we
can
find
a
format
that
allows
them
to
communicate
consistently
like
what
is
coming,
that's
great
and
if
we
could
yeah
have
presentations
and
have
topics
of
interest
like
record
these
meetings
and
put
them
on
youtube
for
a
reason,
and
it
shouldn't
just
be
for
us
to
watch
them
back.
It
should
be
like
for
other
people
to
be
interested
in,
what's
being
discussed.
C
B
Yeah
now
the
kind
of
like
technical
planning
stuff
that
should
be
presented
in
these
calls.
It
shouldn't
be
decided
in
these
calls
right
that
there
are.
There
are
more
important
topics
to
discuss
so
yeah
great,
all
right.
Well,
again,
I'll
write
up
the
proposal.
We
won't
make
any
changes,
I
think,
until
after
v16.
Just
so
there's
some
consistency,
but
as
always,
if
you
have
middle
of
the
night
thoughts,
you
feel
you
need
to
share
about
this
or
you
have
preferences
or
an
idea.
B
All
right,
so
current
network
16
no
changes.
Everything
is
on
track,
so
targeting
an
upgrade
at
the
very
end
of
june
or
perhaps
the
beginning
of
july,
butterfly
net.
The
lotus
team
upgraded
on
june
1st,
so
just
this
week,
which
was
ahead
of
their
their
deadline
of
june
2nd,
which
is
great
forest,
is
going
to
be
upgrading.
I
believe,
early
next
week
and
then
stephen.
B
You
said
a
little
bit
after
that
because
of
sort
of
the
testing
requirements
and
all
of
the
integration
testing
that
still
needs
to
happen
for
the
actors,
we're
still
kind
of
going
to
keep
the
timeline
very,
very
tentative.
But
if
you
have
specific
questions
or
concerns
stephen,
it
sounds
like
your
team's
kind
of
off
to
the
races-
and
I
know
you
haven't
been
as
integrated
in
the
the
actors.
Workflow
is
lotus
and
forest,
but
feel
free
to
kind
of
coordinate
async.
B
B
There
were
two
kind
of
proposed
scopes
that
people
were
talking
around.
One
was
sort
of
a
small
community
upgrade
so
that
you
know
team
implementation
teams
are
able
to
like
fix
any
bugs
or
offer
any
enhancements
necessary
after
the
new
actors,
repo
is
executed,
and
so
that
way,
the
broader
fileclean
community
storage
providers
etc
can
get
used
to
upgrading
with
the
fvm.
B
This
would
be
something
that
would
maybe
include
one
or
two
small
fips,
but
it
would
be
a
pretty
lightweight
upgrade.
All
in
all,
the
other
suggestion
is
to
keep
doing
what
we're
doing,
which
is
a
large,
very
fit
heavy
upgrade,
which
would
allow
us,
I
think,
to
incorporate
some
of
the
fits
that
you
and
your
team
are
working
on,
alex
that
we
can
prepare
for
the
second
fpm
milestone
at
the
end
of
this
year.
Both
of
these
are
still
very
much
in
play,
but
I
think
everyone
is
leaning
towards
the
second
larger.
B
You
know
kind
of
fit
heavy
upgrade
on
a
on
a
longer
timeline,
so
bleeding
it
out
into
the
early
fall,
making
sure
everyone
has
time
to
do
what
they
need
and
to
sort
of
monitor
the
progress
of
v16
also.
But
it
was
sort
of
decided
that,
as
long
as
we
communicate
effectively
about
how
to
upgrade
during
b16
that
a
separate
community
upgrade
may
just
not
be
the
best
use
of
time.
A
Yeah,
okay,
I
mean
I
have
a
sort
of
two
sets
of
changes.
Jennifer
did
approach
me
about
that
sort
of
first
idea,
and
so
I
already
had
a
bunch
of
small
things
and
I've
been
working
on
writing
up
more
of
the
small
things.
So
I
guess
I
I
took
that
prompts
to
find
to
find
small
changes
that
could
go
into
a
small
easy.
You
know
low
stress
upgrade,
but
it
just
turns
out.
I
have
lots
of
them,
they're
all
easy,
and
so
they
would
all
be
like
very
light.
A
They're
all
targeted,
extremely
light
work
for
implementation
teams,
but
but
if
we're
going
to
do
an
upgrade
here,
I'm
keen
to
get
as
many
of
those
in
as
possible
and
then
I
do
also
have
a
set
of
larger
ones,
which
I
I
was
working
on
at
the
start
of
this
year
and
paused.
While
we
were
focused
on
the
fm
around
re-architecting
towards
enabling
programmable
storage
markets
on
the
fdm,
it's.
A
Whatever
our
scope
is,
it's
probably
not
gonna
be
large
enough
to
include
all
of
them,
but
maybe
the
first
step
of
that
which
is
around
reworking
phil
plus
to
decouple
from
the
markets.
If
we
did
go
for
a
large
upgrade,
then
that
could
be
the
sort
of
scope
of
application
level
change
that
we
could
aim
at
yeah.
B
That
sounds
good,
and
I
also
think
the
lotus
team
at
least
made
it
clear
that,
whether
it
be
like
a
larger,
a
smaller
upgrade
or
yeah
larger
smaller
upgrade,
especially
if
it's
larger
they're
interested
in
sort
of
doing
some
of
the
refactoring
problems
that
they've
been
thinking
about
too.
So,
regardless
of
both
of
those
lists,
I
think,
if
you
already
have
them,
they're
really
helpful
for
others,
as
they
help
try
to
make
this
decision
also.
C
A
B
A
Yeah
thanks,
I
might
skip
it
this
week.
It's
all
happening
in
fifth
discussions.
I
think
I
only
have
one
last
interview
I
want
to
propose
before
I'm
sort
of
got
it
all
out
and
then
I'll
try
and
make
I'll
try
and
get
that
sort
of
clear
list
for
everyone
of
like
the
set
of
small
ones
and
the
set
of
larger
ones.