►
From YouTube: Filecoin Core Devs #47
Description
Recording for: https://github.com/filecoin-project/tpm/issues/107
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
Follow Filecoin!
Website: https://bit.ly/3ndAg44
Twitter: https://bit.ly/3ObND0x
Slack: https://bit.ly/3HKfFy7
Blog: https://bit.ly/3HFZFNv
Reddit: https://bit.ly/39N4Jmv
Telegram: https://bit.ly/3bkP8Ly
Subscribe to our newsletter! https://bit.ly/3Oy8J9j
#filecoin #ipfs #libp2p #web3 #nft
A
All
right,
hi
everyone
and
welcome
this
is
file
coin.
Core
devs
call
number
47.
today
is
thursday
july
14th
and
today
is
meeting
one
of
two
pretty
packed
agenda
for
today.
We've
been
really
efficient
lately,
so
we'll
see
how
quickly
we
move
through
some
of
these
items,
but
I
think
key
goal
today
is
to
really
begin
to
nail
down
some
details
around
the
v17
network
upgrade.
A
There
are
a
lot
of
open
challenges
here
that
we
can
talk
through,
but
I
think
we're
moving
towards
resolutions
that
teams
can
begin
work
and
we'll
know
what
the
next
couple
of
months
will
look
like,
at
least
on
the
flip
side,
so
excited
to
move
through
that
and
also
kuba
has
joined
us
and
he's
going
to
talk
about
one
of
those
fips
which
is
fit
41
forward.
Compatibility
for
pre-commit
and
replica
update.
A
So
with
that,
would
the
forest
team
like
to
kick
us
off
with
updates
and
any
open
questions
or
needs
that
they
may
have.
B
Sure
so
wyatt
helped
us
a
lot
nailing
down
the
the
last
bug
that
was
keeping
us
from
from
joining
this
view
upgrade.
So
we
got
that
fixed
and
yeah.
Now
everything
works
so
yeah
like
it
would
have
taken
like
several
more
weeks
without
wire
support,
so
yeah
we're
very,
very
thankful
and
yeah
we're
now
gonna
move
forward
and
make
a
new
release
and
then
start
creating
regular
calendar
snapshots
yeah
and
that's
that's
all
for
forrest
great.
C
C
C
We
did
ship
a
patch
release
of
lotus
116.1
that
fixed
one
issue
that
emerged
from
the
upgrade,
which
is
that
for
the
first
time
sometimes
messages
can
require
more
gas
than
the
actual
block
gas
limit
allows
and
in
particular
we
discovered
that
submit
window
post
messages
if
they
have
a
lot
of
partitions
being
proved
in
the
same
message
can
hit
that,
and
so
some
search
providers
did
run
into
that
issue.
C
The
quick
solution
was
just
to
break
up
those
messages,
so
that
you're,
proving
you
know,
break
them
up
into
proving
two
messages
of
half
as
many
partitions.
We
probably
need
to
do
more
analysis
into
yeah
how
we
want
to
maybe
potentially
change
limits
in
actors
code.
As
a
result
of
that,
aside
from
that,
I
think
things
yeah
seem
to
go
super
smoothly.
We
were
a
little
distracted
for
our
june.
We
tried
to
do
monthly
feature
releases,
but
our
june
feature
release
wound
up
being.
C
We
can
give
it
the
attention
it
needed,
so
we're
kind
of
skipping
that
slash,
saying
that
the
mandatory
release
was
the
june
release
and
merged
the
june
and
july
releases
that
have
started
testing
as
of
yesterday
and
there's
some
there's
some
good
stuff
in
there.
Some
good
fixes
so
yeah,
that's
about
it
from
lotus.
A
Do
you
guys,
I
know
you
were
talking
previously
about
taking
some
time
off
also
between
july
and
august,
do
you
have
any
like
major
out
of
office
notices
that
everyone
else
should
be
aware
of,
or
is
it
just
individual
teammates
sort
of
taking
breaks
here
and
there.
C
What
I'll
say
is
that
we'll
probably
be
working
at
about
half
capacity
until
until
the
midpoint
of
the
end
of
august,
so
we're
obviously
staggering
it
so
that
we're
not
all
out
at
the
same
time,
but
the
overall
productivity
will
be
will
be
a
little
less
we're
also
all
planning
on
being
at
phil
singapore,
which
is
happening
august
16th
to
19th,
I
think,
which
will
be
exciting,
exciting
to
attend,
but
also
will
affect.
You
know
how
responsive
we
are
to
kind
of
the
day-to-day
operations
sounds
great.
A
All
right
on
the
venus
side
team
keeps
pushing
out
updates,
which
is
great
to
see
venus
messenger.
They
actually
submitted
some
cli
improvements
and
also
some
changes
to
help
mitigate
congestion
on
the
network.
Support
b16
continue
to
work
on
data,
retrieval
information
for
venus
market
and
increasing
support
for
venus
cluster.
I
think
the
most
important
thing
here
to
note
is
that
venus
is
going
to
take
the
lead
in
designing
fit
29
for
all
the
other
implementations.
A
This
is
great,
since
steven
is
also
its
author
and
we'll
talk
a
little
bit
more
too
about
sort
of
how
we
see
the
lines
of
responsibility
falling
for
these
primary
fit
designs
and
implementation
pathways
for
b17
later
in
this
call.
Today,
too,
that
said,
any
questions
for
the
venus
team
that
you'd
like
me
to
transmit
over
to
the
meeting
later
today,.
C
I'd
definitely
be
interested
in
hearing
more
about
that
first
point
about
venus
messenger
and
how
their
anywhere
to
mitigate
v16
message,
concession
because
lotus
had
the
same
problem,
and
we
have
a
very,
very
imperfect
solution
right
now,
so
definitely
interested
in
hearing
more
about
that.
If
they
can
industrial
pr
or
any
description,
it
would
be
cool
yeah.
D
A
All
right
so
updates
from
the
file,
plane,
foundation,
updated
list
of
fips
and
where
all
of
them
stand.
I
think
the
most
important
thing
to
note
is
that
fip
34
set
pre-commit
deposit
is
now
in
last
call
and
will
be
for
the
next
two
weeks.
Everyone
should
be
familiar
with
this
step.
We've
discussed
it
extensively
and
it's
been
open
for
quite
a
while
now,
but
if
you
have
any
questions,
I'd
highly
recommend
taking
a
look
at
the
open
draft
or
you
can,
let
me
know,
and
we
can
go
through
it
also.
A
We
also
have
quite
a
few
fips
that
have
been
merged
into
the
repo
just
to
make
sure
everything
is
in
orderly
fashion,
as
we
have
these
conversations
about
planning
and
scoping
for
the
next
network,
upgrade
and
sort
of
the
one
open,
fip
right
now,
that's
still
being
worked
on
and
there's
quite
a
bit
of
community
discussion
around.
Is
this
bottom
one,
the
sector,
duration,
multiple
for
longer
term
storage,
commitment
which
was
presented
at
the
previous
core
devs
call
and
is
being
stewarded
primarily
by
the
crypto
eco
econ
lab
network.
A
A
That
being
said,
I
also
wanted
to
share.
I
checked
in
with
par.
There
are
no
security
flags,
so
I
wanted
to
use
this
section
to
actually
give
you
some
updates
on
some
of
the
upcoming
sort
of
like
work
stuff
that
you're
going
to
see
from
the
governance
team,
which
is
me
the
number
one
thing
is
hiring.
A
The
governance
team
is
only
me
right
now
and
there
is
zero
capacity
for
work
extremely
stretched
thin,
which,
as
a
note,
if
you're
ever
waiting
on
anything,
you
need
anything.
Please
push
and
ping
me
because
odds
are
it's
sitting
under
30
other
to-do
list
items
for
slack
messages,
but
we
are
looking
to
add
at
least
one,
if
not
a
few
project
managers
to
the
governance
team
to
help
us
we're
earlier
in
the
hiring
process.
But
this
is
a
huge
priority.
A
Be
able
to
support
with
some
of
the
direct
chips
management
also,
so
I
will
keep
you
apprised
so
that
you
know
what's
going
on
and
what
new
folks
may
be
popping
into
these
meetings,
but
wanted
to
flag
and
also
version
17.
A
The
network
upgrade
is
already
sort
of
creating
many
many
open
questions
and
competing
interests
which
we'll
have
to
sort
of
manage
and
negotiate
in
the
coming
weeks.
We're
going
to
create
a
fifth
tracking
table
that
will
be
added
to
github.
It's
going
to
look
very
similar
to
the
ones
that
all
of
the
implementation
teams
filled
out
this
week,
sort
of
reflecting
on
their
capacity
and
sort
of
implementation
needs
for
different
fips.
A
But
this
will
be
a
good
way
for
us
to
track
things
as
they
are
sort
of
developed
and
pushed
into
the
repo
in
tandem,
which
is
a
sort
of
process
that
we
don't
usually
have
we're
going
to
make
public
very
detailed,
fip
management
workflows
so
that
we
can
audit
how
things
are
currently
going
and
you
can
make
requests.
If
you
want
additional
support.
I
think
there's
something
that
we
should
be
doing
better
and
we
also,
of
course,
have
our
upcoming
changes
to
the
core
devs
meeting
format
and
scoping
some
updates
to
fib
one.
A
A
C
Yeah,
I'm
personally
not
not
really
an
idea,
but
I'm
personally
definitely
feeling
a
little
overwhelmed
by
the
amount
of
stuff.
The
amount
of
you
know:
potential
ideas
for
v17
and
just
overall
fibs,
I'm
glad
to
have
that
tracking
table.
I
think
that'll
help
help
keep
us
all
on
the
same
page,
because
I
think
there's
a
lot
of
scope
for
a
little
bit
of
chaos,
but
a
good
problem
to
have.
A
And
just
a
little
bit
of
chaos,
the
decentralized
chaos
vectors
are
at
our
door
once
more
and
we
fought
them
off
before.
So
I
think
we
will
this
time
too,
but
yeah
if
you're
ever
feeling
that
confusion
really
handily
and
it's
affecting
your
ability
to
sort
of
think
about
your
work
in
the
moment
or
over
the
coming
days
too.
Let
me
know,
because
I
know
that's
a
point-
that
some
teams
have
fallen
into
during
previous
upgrades
and
we
really
want
to
avoid
that.
A
So
I
think
today
we're
not
going
to
have
like
a
really
set
resolution
on
what
b17
is
going
to
look
like,
but
we
will
get
closer,
and
the
hope
is
that
we
can
continue
to
move
towards
that
relatively
quickly,
so
that
there's
some
certainty
over
the
next
couple
of
weeks.
F
Yeah
something
I'd
like
to
add.
I
think
this
is
really
great
the
progress
from
how
we
had
been
doing
things
since
last
year.
You
know
now
we
have
presenters
for
fifths
and
then
we
have
this
tracking
table
and
we
have
consensus
on
which
needs
to
be
added.
I
think
this
is
fantastic
from
what
has
happened
and
the
progress
that
we
have
made.
F
F
A
Yes,
great
observation,
good
suggestion:
this
is
part
of
the
complication
that's
emerging
around
this
upgrade
jennifer.
Did
you
want
to
jump
in?
It
looks
like
you
have
a
question.
Sorry,
it's
a
different
topic.
Okay!
So
for
this
one
point
of
constant
confusion
that
I
don't
quite
know
how
to
battle.
A
This
is
unrelated
to
this
upgrade
in
particular
is
that
if
we
leave
something
open
as
a
pr
indicating
that
it's
sort
of
still
in
need
of
review
or
there's
still
a
lot
of
changes
happening,
it
makes
it
difficult
to
push
those
changes
and
keep
the
draft
current
when
we
merge
it,
even
if
it
is
still
indicated,
as
a
draft
folks
rightfully
tend
to
think
that
it
is
more
final
or
is
like
imminently
going
to
be
accepted,
not
always
the
case.
A
The
differentiation
between
like
a
draft
that
is
a
pr
and
a
draft
that
has
been
merged
into
the
repo,
is
very
slight.
It's
really
pretty
arbitrary.
It's
really
just
has
to
do
with
whether
the
draft
seems
mostly
complete
and
the
author
is
actively
still
working
on
it.
So
there
is
nothing
to
really
distinguish
like
where
those
things
are
you're
right.
A
There
are
some
things
here
that
were
not
in
your
table
to
like
really
consider,
of
course,
you're
always
welcome
to
go
and
like
throw
in
additional
options
here,
but
the
message
replay
protection
and
then
the
gas
model
for
user
programmability.
A
These
are
not
high
priorities
at
the
moment
and
given
other
things
that
are
they
just
weren't
included
for
consideration.
We
can
reconsider,
of
course,
but
at
the
time
they
didn't
seem
especially
fit
37.
Raul
has
not
indicated
that
this
is
one
that
needs
to
go
forward
in
v8
or
in
b17
other
than
this,
where
you're,
seeing
those
like
additional
fips
to
consider
that
aren't
open
is
drafts.
A
Yet
this
is
part
of
the
challenge
of
this
upgrade
is
that
we've
been
specifically
asked
to
consider
these
fips
because
they
have
been
planned
or
they
are
dependent
on
other
fips,
but
for
various
reasons,
whether
that
be
a
testing
requirement,
any
parameter
that
needs
to
be
modeled,
etc,
work
capacity
being
one
of
them.
There
is
not
a
fifth
draft
yet,
and
that
is
a
challenge
for
me
and
hopefully
something
that
I
can
help.
A
Manage
confusion
around.
Does
that
make
sense.
F
Yeah
yeah,
it
does
thank
you
for
the
clarification
yeah.
I
think
that
helps
because
just
wondering
why
they
were
not
there
and
vice
versa,
but
I
think
you
cleared
that
confusion
for
us
yeah.
A
And
I
think
you
and
jennifer
had
each
asked
that
there'd
be
like
a
cutoff
date,
by
which
point
we
need
fips,
and
I
my
original
opinion
was
that
that's
not
super
helpful.
I
think
in
this
case,
for
the
very
reason
that
we're
being
asked
to
consider
things
that
don't
have
full
drafts,
yet,
even
if
there's
a
lot
of
documentation
available,
I
think
ultimately,
you
guys
are
right.
I
think
we're
going
to
need
them,
so
we
can
talk
about
them
today,
too,.
G
Jennifer,
do
you
have
a
question?
I
also
feel
like,
I
feel
like
the
tracking
table
will
be
like
super
helpful.
However,
I
feel
like
there's
some
missed,
like
mistakes
of
a
flip,
it's
like
it
can
be
dropped,
it
can
be
lost,
it
can
be
accepted.
Like
even
accepted
fib
doesn't
mean
you
will
be
prioritized
for
the
next
immediate
network
upgrade
so
like
I
feel
like.
I
don't
know
what
state
it
should
be,
but
I
feel
like
we
need
the
state
for
fifth
that
is
like
be
actively
considered,
for
the
upcoming
upgrade.
G
Does
that
make
sense
like
even
like
a
draft
fit
can
be
in
that
status?
Right
like
it's
like,
even
though
it's
dropping,
we
think
it's
like
high
powered
high
like
power
tape,
so
we
will
be
more
engaged
to
make
sure
that
fib,
just
like
going
through
last
call
and
like
be
accepted
and
finalizing
the
up
like
upcoming
upgrade
so
like.
I
don't
know
how
it
looks
like
just
an
idea.
G
I
also
want
to
mention
it's
like,
especially
for
like
fib
exam
like,
for
example,
the
sector,
duration,
multiple
or
longer
term
storage
commitment,
I
would
say,
like
a
fib
has
like
a
very
active
discussion,
doesn't
mean
you
will
be
implemented
in
the
upcoming
network.
I
feel
like
there's
a
great
line
there,
because
I'm
mentioning
this
because
I
started
to
observe
in
multiple
community
chat,
that's
saying
that
the
teams
are
pushing
for
that
fifth
to
be
in
the
next
upgrade
and
are
making
assumptions.
So
I
just
want
to
make
that
clarification.
A
Yeah
and
to
your
point
529,
this
has
been
accepted
for
months,
wasn't
included
in
b16,
maybe
including
v17,
because
there's
time
and
capacity
but
yeah
you're
right.
That's
a
good
distinction
to
make
so
currently
there's
just
tags
for
like
when
fips
are
being
considered
for
different
network
upgrades,
but
these
are
just
made
in
the
discussion
repo,
which
also
makes
them
harder
to
sort
of
keep
really
current.
But
if
you
think
yeah,
we
can
also
add,
like
a
fifth
category,
for
something
that,
like
a
core
dev,
is
considering.
G
A
All
right,
so
then,
one
last
update
for
me
is
that
the
next
core
devs
call
we
have
will
switch
us
to
our
new
format
that
we've
discussed
for
weeks
now.
There's
a
rollout
plan
available
on
github.
If
you
want
to
see
details
of
this,
but
the
idea
is
that
this
first
call
is
going
to
happen
on
thursday
august
4th.
A
It
had
previously
been
discussed
and
decided
that
there
would
be
one
meeting
per
day
for
up
to
an
hour
and
that
every
other
month
we
would
switch
timing
to
accommodate
different
time
zones.
So
for
all
of
us
once
every
two
months,
you
will
have
sort
of
an
inconvenient
meeting
time,
but
it's
decided
that
the
two
different
meeting
structure
just
isn't
working
for
right
now
and
I
think
it's
affecting
our
overall
attendance
as
well
as
like
the
cogency
of
information.
A
That's
shared
also
know
that
this
meeting
will
introduce
a
new
format
that
is
a
little
bit
more
formal
you'll
have
materials
in
advance,
because
the
hope
is
that
we
can
have
more
engineering-focused
conversations,
fewer
updates
and
that
way,
if
there
are
any
materials
that
are
being
discussed
in
particular,
you'll
have
at
least
a
week
to
review
that
prior
to
the
actual
meeting,
all
materials,
including
invites
for
these
new
meetings,
are
going
to
be
sent
out
in
the
next
couple
of
days
and
we're
also
going
to
have
a
much
more
formalized
attendance
list,
as
well
as
really
clearly
scoped
responsibilities
for
what
a
core
dev
is
and
what
they
are
asked
to
do
within
the
ecosystem.
A
All
right
great,
I
for
one
very
excited
about
this,
so
fingers
crossed
it'll
go
great,
and
hopefully
we
have
a
lot
of
folks
who
attend
that.
This
is
like
a
high
value,
add
to
what
are
usually
very
packed
meeting
schedules:
okay,
keeping
our
placeholder
card
for
network
b16.
I
didn't
want
to
take
this
out,
because
I
wanted
to
touch
on
questions
about
a
retro.
A
Previously,
it
had
been
said
that
there
may
be
a
retro
coming
from
either
within
the
fvm
or
lotus
teams.
I
thought
could
have
misunderstood.
Plan
could
have
changed,
but
I
just
wanted
to
give
everyone
a
chance
to
kind
of
sort
of
share
any
info
with
everyone
else
if
they
have
it
or
to
figure
out
whether
or
not
this
is
something
that
we
still
need
to
schedule.
G
Yeah
there's
a
retro
is
going
to
be
close
to
like
multiple
retro,
while
going
out
like
from
the
lotus
team,
and
we
will
try
to
store
ship
this
one
like
maybe
next
time.
Someone
else
can
take
it
yeah,
but
the
idea
is
like
low.
This
will
first
like
do
a
joint
one
with
like
the
fdam
team
and
get
gathered
their
feedbacks,
because
there
was
a
lot
of
like
interaction
between
our
two
teams.
G
G
Forrest
team
obviously
is
welcome
to
join
the
locals
and
if
vm
like
retro
as
well,
I
would
say
invite
to
everyone,
however,
but
like
just
alert
be
aware
that
there
will
be
a
lot
of
like
management
related
stuff
just
like
between
these
two
teams
as
well.
If
you
want
to
leave
like
asynchronous
points
about
like
foreign,
that's
an
option
too,
but
everything
will
come
in
next
week
because
raleigh
is
finally
taking
a
break
this
week.
But
he
didn't
really
do
a
good
job
on
taking
vacations.
A
Great,
if
someone
wants
to
participate
in
the
async
retro,
I'm
thinking
the
venus
team
may
want
to.
Where
can
I
point
them?
Do
you
know
yet?
I
will
have
a
keyboard.
A
All
right
so
then,
moving
on
to
our
next
large
scope
of
work
network,
b17,
again
lots
of
different
sort
of
variables
that
have
emerged
very
recently,
making
this
a
little
bit
complicated
to
sort
of
think
and
plan
for
thanks
to
everyone
for
taking
a
few
minutes
to
sort
of
review
these
at
a
high
level
and
put
together
your
thoughts
for
implementation.
A
A
I
did
want
to
ask
about
this
last
one,
since
there
is
not
a
fit
draft
for
it
jennifer.
We
knew
that
the
lotus
team
was
working
with
the
crypto
netlab
to
model
the
implementation
of
this
and
do
some
early
tests.
E
Yeah,
there's
not
too
much
to
speak
about
more
or
less.
I'm
delayed
working
on
load
of
specific
things.
My
next
order
of
business
after
wrapping
that
stuff
up
is
going
to
be
prototyping.
This,
which
I
think
is
going
to
flush
out
some
design
decisions
and
is
more
or
less
blocking
writing
at
the
pip
draft.
We
do
have
kuber
here
too,
who
might
know
a
little
bit
more
about
like
the
straight-up
top-down
like
design.
E
There
might
be
enough
to
create
a
draft
which
we
could
then
augment
with
design
changes
that
come
from
prototyping.
If,
like
that's
a
problem,
yeah.
H
H
This
part
of
the
system,
like
the
complexity,
is
very,
very,
very,
very
high
over
there,
as
as
mentioned
so
yeah
like
depend,
depending
on
like
what
we
need
like
we
can
proceed
as
needed,
like
caitlyn.
G
So
timeline
wise,
I
will
say,
expect
a
early
draft
later
july,
early
august,
but
the
final
final
one,
that's
ready
for
last
call
was
like
you
know,
implementation
specifications
that
will
be
coming
later
in
august
early
in
september
for
like
before
you
can
go
last
call
cooper.
Does
kubernetes
understand
that
there's
something
like
reasonable
for
now.
H
Yeah
yeah,
I
think
so
like
yeah,
like
I'm,
I'm
like
yeah
like
it's
like,
we
are
really
hoping
we
can
get
get
this
in,
like
as
it's
like.
It
will
be
most
like
it's
mostly
actors,
change,
slash,
have
like
a
yeah
actors,
change
and
like
there
are
some.
There
will
be
some
changes
on
the
on
the
implementation
side,
especially
how
we
interact
with
field
class,
but
yeah
like
it's
an
important
component
to
further
updates.
We
were
planning
around
programmable
storage
markets,
yeah.
A
Okay,
thanks
sounds
good.
The
so
I
know
alex
north
has
put
together
a
lot
of
documentation
for
this
too,
and
it
looks
like
what
is
almost
a
complete.
Flip
drop
does
exist
within
the
the
repo
or
the
discussion
forum,
so
I
don't
know
if
it's
super
necessary
to
create
like
a
draft
right
away.
If
all
the
specs
are
going
to
change,
my
preference
would
be
for
their
to
be
one
so
that
we
can
make
reference
to
it
and
begin
to
share
it
with
the
file
coin
plus
t
more
formally.
A
I
know
this
has
been
presented
to
them,
but
I
know
they
have
a
lot
of
open
questions
still
and
just
some
hesitations
around
any
proposed
change
to
their
program,
so
we'll
have
to
talk
with
them
too.
If
you
again,
I
think
if
you
could
put
together
like
a
draft,
even
if
it
is
changeable,
that
is
preferred,
but
there's
no
tight
deadline
or
ask
around
this.
So
whatever
works
for
your
workflow
is
fine.
H
Right
yeah,
we'll
figure
yourself
help
for
sure.
A
Okay,
thanks
all
right,
great,
so
also
the
actual
design
and
like
lead
implementation.
For
all
of
these,
it
looks
to
have
been
divided
across
lotus
in
the
crypto
net.
Lab
crypto
net
lab
is
where
a
lot
of
these
originated,
except
for
5th
29,
which,
as
mentioned,
is
going
to
the
design
of
which
is
going
to
be
led
by
stephen
and
the
venus
team.
Jennifer.
G
I
D
F
Yeah
yeah
yeah
will
tests
be
go
test
be
available
for
this
ships?
I
think
foreign.
D
Which
flips
do
you
mean?
Because
the.
H
D
H
The
34
and
41
are
100
percent
within
actors
like
they
are
self-contained
within
actors.
41
exposes
new
methods
which
can
be
tested
externally,
yeah,
but
like
we
have
tests
for
them
within
the
actors.
If
we
are
talking
about
what
like
consensus
tests,
we
yeah
the
like,
consist
consensus.
H
Text
factors
will
for
sure
they
will
for
sure
be
updated
as
part
of
like
part
of
the
code
for
34,
because
it
changes
the
behavior
of
actors
and
if,
if
41
goes
through,
then
we
will
add
new
test
vectors
for
541
as
well.
F
Cool
awesome
david.
Did
you
have
anything
on
the
testing?
No,
no
comments,
okay,
all
right
cool!
Thank
you.
G
I
have
a
question
on
the
assumption.
I
don't
know
if
it's
the
right
time
or
yeah
good.
I
saw
the
second
point
saying,
like
timeline
is
dependent
on
expectation
around
fvm2,
I'm
wondering
what
does
that
mean?
How
are
we
going
to
make
a
decision
and
like
what's
the
decision
like
factors?
When
will
we
make
the
final
decision?
Basically,
because
I
don't
want
to
change
things,
I
don't
want
to
spend
like
two
months
planning
and
then
somehow
everything
just
like
shaken
up.
A
Yeah,
I
don't
think
anyone
yeah
don't
want
that.
I
also
am
very
careful
because
I
don't
want
everyone
to
plan
around
an
upgrade
date
just
for
us
to
have
like
a
governance
technicality
around
like
the
completion
of
a
fit
draft,
potentially
delay
anything,
and
that
would
not
be
particularly
efficient.
This
is
something
that
have
been
communicated
originally
in
the
v17
planning
thread
on
the
tpgm
repo
I
should
have
written
timeline
is
partly
or
partially
dependent
on
expectations
around
m2.
A
If
you
know,
there's
really
strong
push.
Obviously
we
know,
like
the
programmable
storage
contracts
are
community
priority
if
the
fbm
team
also
is,
is
really
focused
on
landing
m2
before
the
end
of
the
year.
It's
something
to
consider
when
we
look
at
this
upgrade
cycle.
If
we're
looking
to
finish
some
of
the
like
systems,
design
for
this
bottom
fifth,
decoupling,
filecoin
cluster
marketplace,
you
know
early
september.
A
Does
that
push
us
out
even
further
to
october,
wouldn't
give
us
enough
time
for
m2
may
be
negligible,
but
it
is
a
conversation
we're
also
having
with
the
fbm
team
more
broadly,
to
make
sure
that
everyone's
expectations
are
in
the
same
place,
but
in
terms
of
actually
making
the
decision
once
we
have
a
confirmed
list
of
fips
which
again
won't
happen
today,
but
should
happen
pretty
soon.
We
can
assert
a
timeline
a
little
bit
more
clearly
and
operate
on
that.
G
G
The
only
thing
that
we
will
do
is
if
vmn
2.1,
unless
there's
a
very
urgent
network
security
thing
we
have
to
fix
other
than
that.
I
would
strongly
propose
to
not
consider
any
other
steps,
even
it's
like
implemented
or
whatsoever,
because,
like
the
changes
way
dramatics
and
even
in
one
you
like
foreign
already
see,
some
like
you
know
not
like
the
network
is
still
very
well
like
alive,
but
we
are
seeing
some
like
bombs
for,
like
m2.1,
is
going
to
be
more
serious
than
that.
G
A
I
think
I
think,
that's
great
to
note.
I
think
we
want
to
also
make
sure
that
kuba
has
enough
time
to
talk
through
the
four
compatibility
fifth,
but
I
think
that
what
you
just
said
jennifer
is
most
people's
preference
also,
especially
within
this
call.
A
H
To
join
us
yeah
yeah
could
I
share
my
screen.
I
I
know
yes.
H
All
right:
do
you
guys
see
these?
The
flip
flip
screen
yeah.
I
think
you
do
yeah
yeah
all
right,
so
the
title
is
for
compatibility
for
pre-commit
and
replica
update
and
the
reason
it's
called
forward
compatibility
is.
We
are
predicting
a
change
that
will
maintain
future
and
we
are
making
a
change
now
that
will
make
this
change
easier.
H
So
we
know
that
we
are
moving
towards
programmable
storage
markets
and
user
programmability.
For
for
us,
especially
search
markets.
We
want
to
enable
users
to
create
their
own
kinds
of
storage
products,
and
one
important
change
in
that
system
is
being
able
is
the
the
ids
not
being
like.
We
don't
have
deal
id
on
our
one
market,
we'll
have
different
deal
ids
on
different
markets.
Will
they
might
be
numeric,
they
might
be
hashes,
they
might
be
something
else.
H
This
means
that
we
no
longer
can
will
be
able
to
use
straight
deal
ids
for
for
during
pre-commit
and
proof
commit
stages,
and
we
cannot
trust
the
markets
either.
This
is
why,
in
in
future,
in
future,
in
future,
we'll
be
using
unsealed
sector
cid
instead
of
deal
ids
during
pre-commit
stage,
but
today
we're
still
continuing
to
use
deal
ids.
So
today
what
happens
is
the
during
pre-comment
stage.
H
H
There
are
some
changes
that
are
coming
that
are
were
already
accepted,
as
as
the
as
the
peace,
pre-committee
positive
fit
in
the
price
deposit
where
we
shuffled
around
where
we
are
where
we
accessed
the
com
d,
so
the
pre-commit
deposit,
fib,
moved
the
com,
the
answer
sector
and
still
sector
cid,
also
known
as
from
the
computation
from
proof,
commit
stage
to
pre-commit
stage,
and
here
we
are
expo
expo
allowing
the
storage
providers
to
pass
the
explicit
unsealed
sectors.
H
The
cid
during
pre-commit,
by
adding
a
new
method
number
number
28
with
the
working
name,
is
pre-commit
sector
batch
2..
We
don't
need
pre-commit
sector
because
internally,
it
just
forwards
it
to
pre-commit
sector
batch.
So
pre-commit
sector
is
not
needed,
and
this
method
is
a
clear
copy.
Carbon
copy
of
becoming
sector
batch
with
following
changes.
It
removes
the
non-functional
cc
upgrade
fields,
as
you
can
see
over
here
from
the
arguments.
H
It
introduces
the
sector
cid
field,
which
is
a
tagged
union
of
cid,
and
none
then
signifies
that
the
unsealed
sector
cid
corresponds
to
the
cid
of
a
empty
c
c
sector
of
that
given
type
and
size,
and
the
method
will
verify
that
unseal
sector
cid
is
passed
in
this,
as
this
argument
is
consistent
with
the
unseal
sector
city
computed
by
the
ladies.
H
So
the
reason
why
we're
doing
it
right
now
and
not
in
upgrade
or
two
when
it's
actually
useful
is
that
it
makes
a
transition
like
makes
the
transition
to
it
easier
because
search
providers
can
like,
after
this,
this
lands
on
chain
can
start
using.
This
method
will
deprecate
the
old
method
then,
and
at
the
next
upgrade,
we
can
assume
that
the
old
method
is
unused
and
every
message
contains
the
unsealed
sector.
Cid
like
we
cannot
assume
like
we
will.
We
will
disallow
using
it
anymore.
H
We
can't
do
that
right
away
in
within
one
upgrade,
because
the
old
messages
would
fail
then-
and
we
don't
want
to
do
what
we
don't
want-
that
the
same
change.
Almost
the
same
change
happens
to
prove
replica
updates,
I'll,
select,
method,
number
29
called
proof.
Replica
updates,
2,
which
is
a
carbon
copy
of
replica
upgrades,
introduces
a
new
unsealed
cid
of
type
cid.
H
It's
type
cid
instead
of
option
cid
as
as
a
pre-commit,
because
there's
no
reason
to
optimize
the
zero
cc
because,
like
for
pre-commit,
the
zero
sectors
are
my
major
use
case
for
for
proofread.
They
they
aren't
and
same.
We
introduced
the
field
and
we
verified
that
it's
consistent
with
the
leds.
H
That's
roughly
it
the
the
it's
primarily
a
change
to
the
actors.
The
implementations
themselves.
Don't
have
to
do
anything
for
it
at
this
point
in
time.
We'll
will
add
language
to
this
flip.
One
one
piece
of
language:
that's
missing
is
that
we
recommend
deprecating
the
old
methods
right
away
after
the
this
object,
lands
and
or
we
recommend
that
that
the
new
methods
start
being
used
right
away.
So
whenever
they
are,
whenever
we
need
everyone
to
to
to
use
the
new
methods
they
are
already
being
used
and
the
questions.
E
G
E
Would
you
say
that,
okay,
so
it's
it's
more
that
than
anything
so
it
you
could
also
say
it
like
allows
some
time
for
node
developers
to
like
create
the
right,
endpoints
and
grab
the
combi
and
put
it
in.
But
that's
maybe.
E
So
this
does
this
doesn't
make
sense.
I
guess
I
mean
like.
I
think
this
is
something
people
have
talked
about.
I'm
just
wondering
like
what
the
other
options
are
and
like.
I
guess,
like
the
the
trade-off
here,
which
it
seems
it
seems
reasonable,
is
that
you
have
the
this
like
proliferation
of
code
for
a
little
bit
and
then
this
proliferation
of
of
method
numbers
on
the
actor,
which
is
like
probably
fine,
but
I
don't
know.
G
E
It
would
be
nice
to
think
about.
I'm
sure
you
thought
about
so
like
like
what
I
guess.
What
goes
wrong
if
we
were
to
do
some
kind
of
like
node
based
filtering
like
hey,
just
don't
use
like
don't
use,
I
guess
it
just
becomes
more
complicated
on
the
node
right,
like
you
have
to
say,
don't
don't
submit
a
pre-commit
in
between
like
this
period
and
then
use
the
new
params
for
the
next
time.
Yes,.
H
Yes,
that's
an
alternative
that
we
could
use.
We
decided
to
go
with
this
path
because
one
it
isn't
that
big
of
a
change
like
that
big
of
a
increase
in
the
code
size
like
yeah,
as
you
mentioned,
the
alternative
is
like
it's,
so
I
I
call
this
like
rolling
update
because
there's
a
rollover
period
where
both
things
are
accepted,
which
is
the
period
will
be
after
the
next
upgrade
the
whole
up
until
the
next
upgrade
after
that
that's
the
rollover
period.
H
In
this
case,
the
alternative
is
atomic
update
when
at
the
epoch
boundary
we
switch
to
using
the
new
method
in
here,
we
could
do
like
make
some
mess
with
the
coding
and
like
like
decode,
both
both
both
things,
but
I
don't
think
it's
it's
worth
the
complexity
there.
Yes,
it
include
includes
increases
the
math
number,
but
I
don't
think
it's
an
issue.
Yeah
the
old
methods
will
get
deprecated
after
like
after
this
this,
this
lens
yeah.
E
That
makes
sense
and
hey
yeah,
it's
a
nice.
It's
a
nice
way
like
clearly.
This
has
been
a
problem
because
we've
been
putting
off
removing
the
four
zero
bytes
which
is
blowing
up
the
parameters,
so
it'll
be
nice
to
get
rid
of
those.
I
guess.
Are
you
imagining
that,
like
the
old
method,
so
the
subsequent
upgrade
the
old
methods
become
like
a
media
abort.
J
H
Yes,
exactly
and
jennifer
asked
in
chad,
so
no
state
migration
for
the
first
upgrade
this
itself
doesn't
require
the
state
migration.
The
reason
why
we
can't
avoid
this
state
migration
is
because
the
changes
that
were
done
during
the
precomit
deposit
fib
will
require
migration.
So
that's
the
also
why
currently,
both
this
fibs
are
implemented
as
one
code
change.
Although
removing
this
feature
this
fip
out
of
this
code
change,
which
is
which
is
in
built-in
actors,
is
trivial,
just
stripping
the
the
entry
points
and
more
questions.
Oh.
E
Sorry,
I
didn't
quite
catch
that,
like
the
the
pcd
change
that
still
requires
the
state
migration
on
the
the
pre-k.
H
C
And
to
be
clear,
so
that's
the
sector
pre-committee
info
object
that
you
have
there.
That's
a
new
picture
of
the
cycle.
Prequel
info
like
as
a
result.
Yes,
yes,
cool
yeah.
I
don't
know,
I'm
I'm
unhappy
that
we
have
to
do
this,
but
I
also
don't
think
like
it
just
feels
like
we.
I
wish
we
had
a
nicer
answer
here.
I
do
think
the
atomic
switch
would
just
be
too
messy.
We
kind
of
got
a
taste
of
that
with
the
v16
upgrade
where
we
didn't.
C
You
know,
make
any
messages
invalid,
but
just
like
the
gas
changes
alone
caused
some
chaos
and
obviously
pre-commit
sector
is
a
pretty
important
method
that
we
can't
just
like,
say
we'll
disable
for
one
to
two
days.
So
I
do
think
that's
the
best
option.
I
think
that's
what
we
should
do.
I
wish
we
had
something
better,
but.
H
Yeah,
like
you
also,
as
I
said
like,
we
were
looking
for
the
simplest
solution
like
yeah
like
introducing
new
method
numbers
and
new
method.
Names
is
a
bit
messy,
but
on
the
at
the
end
of
the
day
like
introducing
like
hidden
decoding
like
decoding
like
conditional
decoding,
is
even
more
messy,
so
and
atomic
switch
causes
a
mastering
upgrade,
which
is.
E
H
H
E
E
The
the
user
to
system
actor
api
yeah.
H
E
H
All
right,
if
there
are
no
more
questions,
then,
let's
back
to
you
caitlyn.
A
Thanks
kubra,
your
timing
is
great.
That
brings
us
right
to
the
end
of
the
meeting,
so
if
no
one
has
any
other
questions
items
or
needs
that
they
want
to
flag,
I
think
we're
good
for
this
week.
We
have
another
meeting
later
this
afternoon.
It's
it's
at
midnight,
utc
kuba.
I
don't
think
you'll
be
able
to
attend
that
one.
A
So
it
will
direct
everyone
to
the
recording
of
this
call.
But
thanks
again
for
joining
us.
A
Great,
if
there's
nothing
else,
then
we
can
end
for
today
thanks
everyone
and
looking
forward
to
seeing
you
all
at
our
next
meeting
on
august,
4th.