►
From YouTube: Filecoin Core Devs #34
Description
Recording for: https://github.com/filecoin-project/tpm/issues/86
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
A
This
is
also
core
devs
meeting
number
34,
if
you're
keeping
track
and
today
we'll
move
through
our
agenda
like
we
usually
do
and
also
have
several
different
open
discussion
items
at
the
end
of
this
call
for
different
implementation
teams
and
core
devs
to
weigh
in
on
so
to
get
started
we'll
go
through
our
team
updates.
As
a
reminder,
we
sort
of
began
moving
in
the
end
of
2021
towards
sort
of
a
more
open
format.
A
Great
yes,
stephen.
B
Yeah,
okay,
I
just
want
to
mention
to
the
team
that
the
vlas
team
is
working
on
the
network
version
15
and-
and
we
announced
the
schedule-
and
I
could
yeah
put
it
into
the
chart
and
put
link
into
the
chart
yeah.
Basically,
we
yeah
our
schedule
is
yeah,
it's
trying
to
match
with
the
notice
schedule.
So
there
is
no
ending
and
yeah
surprise
about
this
one
and
yeah.
Currently
it's
in
progress
and
we
didn't
see
any
risks.
B
Yeah
very
just
about
this
update
and
some
others
is
us
we're
working
on
the
vedas
market
phase.
Two.
We
want
to
release
the
first
version
about
businessman
phase
2,
which
is
a
deployment
on
the
cloud
called
support.
Multiple
new
service
providers.
Yeah.
I
think
that's
all
about
the
witness
progress
I
want
to
mention
to
a
team.
A
Great,
thank
you,
stephen.
I
also
saw
that
in
the
the
venus
team
slack
channel,
there
was
like
a
great
update
announcement
with
the
scheduling
for
the
next
release.
So
I'll
add
that
to
the
meeting
notes,
also,
if
anyone
wants
to
review
it,
do
you
have
something.
C
Yeah
sorry
I
was,
are
we
talking
about
snap
deals
a
bit
more
later
or
should
we?
Are
we
jumping
into
that
stuff?
Now?
Because
there
are
a
couple
of
relevant
updates
regarding
your
network
b15.
A
C
It
sounds
good
yeah,
then,
just
to
just
kind
of
follow
up
on
steven's
thing.
We
cut
the
actors
release
candidate
for
the
v15
upgrade
on
monday.
I
think
so
that
we're
hoping
that
will
be
the
final
code
that
gets
shipped
on
mainnet,
so
any
anyone
who
consumes
specs
actors
can
can
use
that
anyone
who's
re-implementing
specs
actors.
C
So
the
forest
team
can
use
that
as
your
blueprint
for
for
what
the
code
will
look
like
any
changes
that
any
consensus,
critical
changes
that
go
in
at
this
point
will
be
because
we
messed
up
and
have
a
bug
that
we
need
to
fix.
So
we're
hoping
this
will
be
the
final
product.
Lots
of
testing
that
will
be
happening
and
lotus
is
starting
its
release
testing
process
for
the
upgrades.
Sorry,
the
releases
that
we
will
be
shipping
for
the
upgrade.
I
think
our
first
release
candidate
came
out
yesterday.
A
Sounds
great
and
as
a
note
jennifer
also
mentioned
before
we
started
recording
this
call
that
there
are
different
slack
channels
that
have
been
set
up
for
different
phases
of
the
lotus
testing
process
and
I'll
also
add
those
to
the
meeting
notes.
So,
if
you'd
like
to
join
those,
it
may
be
advisable
just
so,
you
can
keep
tabs
on
how
testing
is
going
and
what
kind
of
open
needs
emerge.
A
Right
and
I'll
also
drop
a
link
as
well
to
the
confirmed
details
for
the
osnap
upgrade
so
jennifer
kindly
put
together
an
outline
of
which
fips
are
likely
going
to
be
incorporated
as
well
as
details
about
each
of
the
upgrade
epochs
do
note.
We
were
originally
considering
three
fips
to
go
through.
However,
one
of
them
has
been
removed
from
this
implementation.
This
upgrade
cycle
that's
going
to
be
fip
27,
which
has
to
do
with
the
label
type
field.
A
Labels
switch
type.
Sorry,
the
exact
name
is
escaping
me
right
now.
But
again
we
added
updated
notes
on
slack
as
well
and
we'll
include
that
in
the
meeting
notes.
A
Great
any
other
last
updates
or
items
that
any
of
the
implementation
teams
want
to
raise.
D
Maybe
just
two
sentences
around
trusted
setup,
caitlin
sure
we
started
this
monday.
First,
we
are
kind
of
doing
all
the
on
all
the
runs
in
with
participants
in
china.
Mainland
everything
is
looking
good.
So
far
we
uploaded
the
first
two
or
three
contribute
contributors,
and
we
are
looking
to
do
that
until
the
26th
of
january.
Every
I
created
like
a
discussion
if
somebody
wants
to
discuss
it
more,
but
this
is
the
current
outlook
and
everything
everything
looks
good
so
far,
also
part
of
v15.
A
A
All
right,
so
it
looks
like
dudley,
is
not
able
to
join
us
today
and
there
shouldn't
be
any
need
to
know
security
updates
from
the
foundation
either
on
my
end
again
we're
just
working
on
these
two
fips.
So
it's
going
to
be
changes
to
verified
client
status
in
the
file
coin
plus
program
as
well
as
snap
deals
as
you
all
are
very
well
aware.
We
have
a
set
agenda
or
sorry
an
upgrade
timeline
as
well.
So
thanks
everyone
for
contributing.
A
I
know
there
was
some
some
back
and
forth
here
and
I
guess
other
than
that,
just
in
like
housekeeping
now
that
it's
a
new
year
and
we
still
have
our
core
devs
meetings.
If
there's
any
changes
to
the
formats
of
these
that
you'd
like.
If
you
don't
like
this
more
open-ended
style,
it
seems
to
be
pretty
time
efficient.
But
if
you
like,
having
everyone
sort
of
get
to
share
updates
through
the
week,
we
can
go
back
to
that
format.
A
Feel
free
to
just.
Let
me
know-
and
another
thing
to
consider
is
alex
north,
who
has
returned
from
paternity
leave
and
has
pushed
forward
a
couple
of
snap
proposals
and
discussion
items
he
reached
out
and
messaged
me
and
asked
if
we
would
potentially
consider
doing
two
separate
core
devs
calls
both
on
thursdays,
but
at
different
times
since
he's
based
in
australia
and
it's
quite
difficult
for
him
to
join
with
the
time
gym.
A
I
also
suspect
that
might
be
the
case
for
some
of
you,
if
you're
in
china
or
other
parts
of
east
asia,
the
filecoin
plus
governance
team
does
host
two
consecutive
calls
to
address
for
this
issue
and
it
works
relatively
well
for
them.
I
have
some
concerns
about
us
fragmenting
up
who
joins,
which
call
and
perhaps
not
having
one
single
team
that
can
come
together
to
hear
each
other's
issues
and
share
potential
solutions.
E
Just
like
a
quick
question
like
instead
of
having
like
two
meetings
for
like
all
the
time
product
calls,
is
it
possible
for
us
to
consider
maybe,
like
rotating
the
time
so
like
if
this
week
is
in,
like
a
u.s,
friends
or
anytime
zone
for
the
the
next
one?
We
have
like
more
like
a
you,
know,
12
hours
later
time,
so
sort
of
things.
A
Yeah,
that's
a
good
suggestion
too.
We'll
have
to
make
sure
everyone
can
keep
track
of
what
time
the
meeting
is
going
to
be,
and
I
think
that
may
just
fall
to
me:
pinging
people
more
on
slack,
which
is
fine
but
again
yeah,
good
suggestion.
C
Yeah,
I
think
I
think
two
meetings
could
work
with
the
caveat
that
you
were
kind
of
alluding
to
if
there
definitely
needs
to
be
some
good
connection
between
folks,
it's
some
async
summary
of
what
was
discussed
in
both
in
all
meetings
for
folks
who
didn't
join,
who
couldn't
join
live
so
as
long
as
we
can
get
that
and
make
sure
that
information
doesn't
get
dropped
along
the
way.
So
someone
doesn't
know
when
the
next
network
upgrade
is
because
they
were
in
the
different
times.
C
When
meeting
that
that'll,
be,
I
think,
the
important
part,
but
otherwise
I
think
it's
a
good
idea,
god
I
can
imagine
that
folks,
joining
from
from
east
asia
and
australia-
don't
don't
enjoy
this.
A
Yeah
I
was
complaining
to
tabitha
that
this
meeting
is
at
8
am
for
me,
but
that's
far
better
than
for
many
of
you,
so,
okay,
great,
so
we'll
sort
of
I'll
put
together
little
proposals
to
what
that
might
look
like,
so
that
you
guys
can
think
about
it
more
and
if
we
want
to
implement
this
change
like
anything
else,
we
can
also
sort
of
test
drive
it,
and
if
we
don't
like
it,
we
can
go
back
to
what
we're
doing
currently
so
great
cool.
A
So
if
there's
nothing
else,
certainly
not
from
my
end,
I
think
we
can
kind
of
segue
into
those
open
conversation
topics
the
first
one
being
a
conversation
around
the
v16
network,
upgrade
as
well
as
the
coming
fvm
fits.
So
there
are
two
fips
that
we
expect
to
land.
This
is
the
same
guidance
that
raul
shared
with
us
in
2021
raul.
Thank
you
so
much
for
joining
us.
A
Despite
your
very
busy
schedule,
you
did
give
us
a
nice
async
update
on
our
on
our
agenda,
but
would
you
like
to
sort
of
provide
an
overview
or
any
new
details?
You
think
is
important
to
share.
F
Yeah
sure,
basically
the
update
is,
is
that
hi
everybody
happy
new
year
by
the
way
yeah
the
update,
the
update
is
basically
that
there
are
two
flips
and
coming
first,
one
is
gonna,
be
around
the
introduction
of
the
fem
itself.
Second,
fifth
is
gonna,
be
around
the
changes
to
the
gas
accounting
model
for
to
account
for
user
programmable
contracts
in
the
future.
F
F
We
expect
to
to
submit
this
fit,
or
at
least
an
initial
draft
or
kind
of
like
you
know
something
that
is,
that
is
good
enough
to
like
be
considered
by
this
group
and
the
community
at
large
by
the
end
of
this
of
this
month.
By
towards
the
end
of
this
month,
we
also
expect
to
begin
collecting
data
from
the
canary
experiment,
which
will
then
feed
into
the
concrete
changes
that
we
propose
for
the
gas
accounting
and
for
the
gas
for
the
iteration
on
the
gas
model.
F
So
that
fib
is
gonna,
is
gonna
come
lightly
sometime
in
february,
or
at
least
like
there's
gonna,
be
probably
gonna,
be
preceded
by
discussion
rather
than
kind
of
like
you
know,
just
just
just
just
delivered
to
the
community
for
consideration.
So
so
that's
where
we're
standing
right
now
in
terms
of
the
upgrade
parts
and
the
implementation
kind
of
like
effort,
something
that
I
also
laid
out
in
in
this
particular
comment
on
the
on
the
tpm
issue.
F
For
this
call
is
that
there
there
is
going
to
be
a
change
in
dynamics
in
terms
of
like
the
implementation
cost
that
implementers
are
going
to
have
to
face
for
implementing
these
fips
if
they're,
using
the
reference
fpm
implementation,
which
is
what
we
expect
that
you
know
all
implementers
are
going
to
be
doing
so,
really
the
by
the
moment
that
we
submit
fip
the
first
fit,
which
is
the
the
implementation
of
the
fpm.
F
It
will
have
already
been
integrated
into
lotus
right,
so
we
don't
expect
a
implementation
phase
after
the
fib
itself.
Similarly,
the
the
fem
is
largely
like
the
fem
is
is
based
off
of
forests,
initial
vm
and
it's
written
in
russ.
So
the
integration
with
forest
should
be
pretty
pretty
simple
as
well
the
integration
with
venus.
F
We
we
expect
that
most
of
the
patch
that
goes
into
lotus
would
be
reusable
for
venus
and
when
it
comes
to
fujon
the
the
ffi,
they
will
need
some
ffi
bindings
there,
but
rust
and
c
the
the
interoperability
between
those
languages
is
way
smoother
than
the
one
between
between
go
and
rust.
F
So
we
expect
like
very
very
little
like
work
and
effort
there,
and
basically,
what
this
means
is
that
implementations
will
have
support
during
some
time
for
two
vms
and
they
will
atomically
switch
to
the
fvm
when
the
upgrade
epoch
kicks
in.
So
this
is
going
to
be
the
way
that
that
we
designed
that
that
upgrade
so
during
some
during
some
time
those
code
base
well,
those
code
bases
will
actually
there
will
be
two
vms
coexisting
in
that
code
base
in
each
of
the
code
bases
and
eventually
in
the
future.
F
We
we,
like
the
the
the
intention
here,
is
for
for
implementations
to
be
able
to
choose
if
they
want
to
support
historical
vms,
going
forward
we
and
lotus.
The
idea
here
is
that,
because
I
did
like
when,
when
this
upgrade
airport
kicks
in,
it
is
theoretically
possible
for
the
next
kind
of
like
the
next
version
of
the
client
implementation
to
just
erase
the
old
vm.
F
If
we
just
want
to
support
the
ongoing
network
right,
however,
it
is
likely
that
implementations
will
want
to
support
previous
or
like
have
a
mode
where
they
support
historical
vm
executions.
F
So
this
is
the
case
for
lotus
and
we're
planning
to
kind
of
like
one
idea
to
to
have
the
support
is
by
by
using
build,
compile
flag
so
having
the
ability
to
compile
lotus
with
historical
support
or
without
historical
support.
That's
kind
of
like
one
one
one
thought
there,
and
so
yeah
so
kind
of
like
the
change
in
dynamics,
in
the
way
that
we
implement
fips
that
have
to
do
with
the
fem
going
forward
are,
is
basically
that
there's
going
to
be
less
work
on
the
implementation
side
of
things.
F
So
we
think
we
need
to
factor
in
for
less
time
when
it
comes
to
like
the
full
end-to-end
process
until
up
until
the
fit
goes
live
and
also
the
gas
accounting
changes
themselves.
If
they're
approved,
then
they
will
be
implemented
in
the
fvm,
so
there's
like
literally
no,
we
don't
expect
any
work
besides
besides,
maybe
like
some
ux
stuff
or
like
some
dx
stuff.
F
That
needs
to
be
done
on
on
clients
themselves
to
actually
support
this
flip
as
long
as
they're
using
the
reference
implementation
of
the
fem
which,
as
I
stated
before,
we
expect
that
would
be
the
case.
F
Any
any
questions,
thoughts,
discussion,
points
that
you
want
to
reset.
E
E
Just
like
you
know
how
low
this
was
sort
of
like
the
reference
implementation
file
coin
like
for
in
the
very
beginning,
so
we
have
different
like
implementations
like
I'm,
just
like
curious
does,
it
is
like
is
like
what
do
you
expect
just
like,
for
example,
like
venus
like
have
their
own
version
of
like
fvm
or
like
do
you
expect
like?
What's
your
thoughts
on
yeah,
I.
F
Know
I
know
yeah,
I
know
what
what
where
you
headed
with
the
question,
which
is.
Do
we
like
expect
actual?
You
know,
alternative
fem
implementations
to
emerge,
and
the
answer
here
is
that
the
fdm
is
like
is
an
embedded
component
right.
It
is,
it
doesn't
expose
a
user
interface
so
to
speak.
Like
you
know,
a
node
would
therefore,
like
you
know.
Venus
is,
for
example,
specialized
in
certain
use
cases
that
load
assistant
or,
like
that's
the
direction
that
where
venus
is
headed.
D
F
So
like
this
is
because,
like
it
supports
different
use
cases,
the
fdm
is
like
a
very
constrained
and
kind
of
like
tightly
bounded
component.
So
I
I
do
expect
implementations
alternative
implementations
to
emerge,
but
potentially
because
somebody
like
feels
radically
different
about
how
a
particular
how
the
implementation
should
be
and
like.
Potentially,
there
is
like
disagreement
but
like
at
one
point
which,
like
you
know,
warrants
maybe
forking
a
code
base
or
like
starting
a
new
code
base,
and
this
is
good
because
diversity
is
good
right
but
like
when
it
comes
to.
F
You
know
a
a
practical
reason.
So
to
speak.
It's
it's
it's
hard
because,
like
the
the
fem,
currently,
the
implementation
is
tied
to
what
to
what
sometime
like
out
of
you
know
all
programming
languages
rust
is
the
better
the
best
fit
for
was
and
runtimes
really
so
like.
It
is
hard
to
like
imagine,
an
fem
implementation
being
built
in
a
different
language
and
when
it
comes
to
like
the
actual
wasm
runtime,
which
we're
using
wasn't
time.
F
At
this
point,
it
is
possible
to
introduce
different
runtimes
in
the
reference
implementation
of
the
fvm
itself,
and
this
is
something
that's
in
the
road
so
like.
I
don't
think
that
that
would
be
motivation
enough
to
start
another
implementation,
but
I
think
there's
going
to
be
potential
for
intellectual
curiosity
or
intellectual.
You
know
intellectual.
C
E
Think
that
makes
sense
because,
like
I
just
want
to
like
out
there,
it's
like,
if
you,
you
don't
plan
to
implement
in
a
different
like
totally
different
approach
like
if
yeah
it's
gonna
be
an
open
source
like
again
like
repository
and
also
like,
we
welcome,
like
all
contributors,
just
contribute
to
the
repository
directly,
I'm
giving
ideas
so
like
I
just
want
to
play
it
out
there.
It's
like
it's,
not
just
like
phone
loaders.
You
know
like
in
a
way
yeah.
C
Yeah
one
flag
in
terms
of
timeline,
I
think
yeah
broadly
agree
that
integrating
the
fbm
into
the
various
implementations
shouldn't
be
all
that
complicated.
Having
said
that,
it's
a
little
bit
of
us,
the
sooner
folks,
can
get
started
on
that
the
better,
because
some
some
refactoring
some
re-architecturing
will
be
needed,
I'm
sure
in
all
of
the
implementations,
even
for
us,
so
we
should
definitely
factor
in
that
time.
C
Obviously,
lotus
is
getting
a
head
start
in
order
to
validate
the
fem
itself,
but
the
sooner
everyone
can
start
kind
of
trying
to
see
what
that
would
look
like
and
do
any
pre-factoring
that's
needed.
I
think
that'll
that'll
make
sure
that
everyone
can
move
along
in
a
timely
fashion.
E
F
One
one
thing:
sorry
jennifer,
just
just
one
thing:
we're
we're
planning
to
open
source
the
wrapper
really
really
soon
we're
right
now
doing.
Cleanups
we've
got,
I
think,
with
two
pr
submitted
overnight:
we've
got
100
of
actors,
b6
test
vectors
passing
now.
F
So
that's
that's
a
really
good
news,
so
we're
we're
planning
to
open
stories
soon
we're
doing
cleanups,
adding
to
do's,
adding
like
making
sure
that
we're
that
there's
issues
in
there
so
that
if
people
want
it
like
as
soon
as
we
open
source
people
want
to
jump
in
and
help
there
are
issues
stacked
with
help
wanted
and
kind
of,
like
you
know,
to
provide
good
community
good
community
experience
here.
F
What
I
can
do
in
the
meantime
is
give
the
implementers
group
access
already
to
the
repo
before
we
actually
make
it
full-on
public.
So
if
that
is
something
that
you
know,
what
would
help
the
forest
team
already
has
access,
because,
like
you
know,
much
of
the
code
was
based
from
them
and
we
needed
to
coordinate
on
actor
actor
fixes
as
well.
But
I
can
give
the
folks
on
on
venus
and
fulham
access
right
now
and,
like
probably
just
just
ahead
of
the
of
the
public,
making
it
public
itself.
B
Yeah,
I
think
which
is
good
to
make
it.
You
know
public
and,
and
we
yeah
as
the
village
team,
we
we
we
will
assign
one
or
two
resources
on
this
and
yeah.
This
is
very
important
for
us
to
integrate
or
yeah,
make
some
change
to
to
to
yeah
and
adopt
this
yeah.
So
I'll.
F
Get
this
done
today
just
be
aware
that
you're
gonna
find
a
bunch
of
to-do's
and
things
in
there
so
don't
just
buy
buy.
It
has
been
a
very,
very
it's
a
very
fast-paced
project
here,
so
so
yeah.
B
Yeah,
that
is,
okay,
yeah,
yes,
you're
saying
is
yeah
you're
ready,
yeah
we're
now
to
get
and
to
see
what
we
could
and
you
contribute
and
how
to.
F
A
So
I
have
a
quick
timeline
question
for
you.
Raul.
Does
your
development
schedule
have
an
ideal
general
date
by
which
you
expect
the
fdm
to
be
live
on
the
network.
F
E
D
E
Like
you
wrap
up
all
these
annoy,
you
know
implementation
details,
like
you
know,
maybe
at
the
end
of
january
I
would
love
to
sync
with
you
as
soon
as
possible.
It's
like
which
tesla
should
we
using
like
how
do
we
do
like
do?
We
like?
I
would
love
it
to
be
wrong
on
calibration,
at
least
for
like
a
month,
at
least
four
months
before,
like
the
mina
upgrade,
but
at
the
same
time
time
is
kind
of
tricky
because
we
have
the
snapdeal
testing
ongoing
as
well.
E
So
like,
I
feel
like
a
lot
of
like
coordination.
Planning
needs
to
be
done
there
and
you
so
also
like
kind
of
like
quote-unquote
like
recruiting
the
community
members
who
can
actually
joining
this
the
test
effort.
I
would
love
to
get
started
as
soon
as
possible.
So
like
once,
you
know,
when
you
have
time,
let's
have
a
sink.
F
So
I
think
the
the
main
thing
that
we
need
to
think
about
and
if
people
also
have
like
thoughts
here
with
regards
to
to
test
nets,
is
besides
kind
of
like
looking
out.
For
you
know,
the
test
net
is
not
getting
broken
right
and
it's
just
like
the
chain
is
proceeding
and
like
the
network
is
healthy
and
everything
we
do
need
to.
F
Like
figure
out
the
exact
metrics
that,
if
that
that
we
wanna
that
we
wanna
instrument
nodes
with
as
well
for
for
a
test
net,
so
that
the
test
that
can
be
as
helpful
as
possible
to
me
to
make
sure
that
this
that
what
we're
introducing
is
is
is
going
to
keep
a
healthy
network
going.
A
Jennifer
just
asked
in
the
chat
as
well
curious
about
where
the
rest
factor
will
live.
F
Yeah
so
well
we
so
the
idea
is
to
extract
the
actors,
the
built-in
actors
to
a
separate
rebel,
which
is
also
a
meeting
place
for
all
implementers
right
now.
So
this
would
be
a
common,
a
common
good
repo
for
for
the
falcon
ecosystem,
we're
thinking
tentatively
of
using
the
name
falcon
project,
slash,
act,
actor,
dash
rs,
because
it's
rust
actors
right
and
it
just
like
you
know-
fits
in
really
well
so
yeah!
F
That's
that's
where
it
would
that's
just
a
proposal,
but
like
it's,
probably
probably
by
by
february,
would
be
when,
like
we
consider
extracting
the
actors.
A
All
right
well,
thank
you
so
much
for
coming
raul.
Again,
we
know
how
tight
your
timeline
or
your
schedule
is
sorry
timeline
too.
I
guess
we
do
appreciate
it.
So
we'll
keep
all
of
this
in
the
notes,
as
well,
for
anyone
who
may
not
be
here
today
and
we
can
kind
of
asynchronously
connect
on
any
other
additional
questions
that
come
up
but
looking
forward
to
knowing
a
little
bit
more
when
you
begin
to
work
through
that
test,
net
process.
E
Well,
thank
you
cue.
I
have
is
like
do
we
expect
this?
Like
you
know,
v7
go
actor
to
be
the
last
go
actor
we
have,
and
I
think
it's
like
important
for
us
like
to
stay
up
like
in
public
in
that
way,
because,
like
a
lot
of
phibia
is
being
proposed
and
people
are
doing
a
lot
of
prototyping,
I
think
they're
wondering
if
they
should.
You
know
continue
with
the
go
active
press
or
they
should
like
start
thinking
about,
like
a
rust
actor
pass.
C
Yeah,
that's
a
good
point.
The
the
trade-off
here
is
obviously
we
don't
want
to
stop
like
the
fdm
is
still
ultimately
experimental,
and
you
know
we
don't
want
to
say,
tell
people
stop
working
on
go
actors
because
we're
definitely
doing
all
of
this.
Having
said
that,
certainly
the
expectation,
at
least
from
my
point
of
view,
is
yes.
C
This
v7
actors
will
be
the
last
time
we
ship
go
actors,
so
maybe
the
decision
that
we
need
here
is
at
what
point
we
feel
comfortable
enough
making
that
so
internally,
it's
like
as
the
folks
working
on
specs
actors.
Right
now,
that's
my
expectation
at
some
point.
We
should
have
enough
confidence
in
the
svm
to
communicate
that
externally
saying,
and
maybe
it's
when
the
specs
actor
dash
rs
is,
is
opened
and
then
folks
can
start
using
that
as
their
reference
point
to
open
prs
and
so
on.
C
A
All
right,
then,
switching
gears
a
little
bit
but
in
the
thread
related
to
the
fvm
alex,
did
ask
that
we
discuss.
If
anyone
has
any
items,
they'd
like
to
bring
up
potential
changes
or
directions
for
storage
markets
in
the
future,
especially
post
fvm
implementation.
A
A
I
get
scared
to
just
say:
storage
market
decoupling
for
now
I
know
this
is
a
big
topic
if
anyone
has
a
thread
in
this
area
that
they'd
like
to
run
with
or
propose
for
the
group
happy
to
discuss
it.
Otherwise,
I
did
want
to
flag
this
discussion
item
for
you
all
and
you
could
check
offline
review.
What's
been
written
already
see
if
you
have
any
thoughts
or
proposals
to
add,
and
then
we
can
continue
to
discuss
this
in
future
meetings
as
well.
D
E
There's
more
activity
in
a
different
discussion.
We
probably
should
consider
like
merging
a
little
bit
so
like
the
first
like
official,
like
fifth
draft
is
created,
and
the
discussion
to
address
that,
like
official
proposal
is
like
in
the
discussion
265
and
there's
a
lot
of
momentum
there.
So
like
yeah,.
A
Yeah,
I
think,
there's
also
some
uncertainty
about
the
exact
scope
of
what's
being
proposed
in
the
fill
plus
subsidy
post
that
alex
made
and
the
fifth
draft
that
he
pushed
so
we're
going
to
try
and
get
him
to
come
to
an
upcoming
quartet's
call
so
that
he
can
walk
through
it
in
greater
detail,
which
is
also
what
necessitated
us
asking
about
the
time
zone,
challenges
and
in
australia.
B
Yeah,
I
think
this
is
a
yeah.
This
is
a
very
big
scene
for
this
big
actors,
change
so
yeah.
This
is
also
related
to
the
discussion
we
yeah
we
just
heard
about
well,
they
should
yeah
put
into
the
guild
line,
implementation
or
yeah
these
last
ones,
yeah.
We
need
to
make
that
you
discuss.
B
A
Yeah
and
as
jennifer
pointed
out,
there's
now
three
separate
discussions
happening
about
this
one
very
big
proposal,
so
I'll
also
reach
out
to
alex
and
see
if
we
can
condense
some
of
these,
it's
important
that
people
can
focus
on
specific
elements
that
may
be
complex
or
have
some
downstream
impacts,
but
we
also
want
to
make
sure
it's
easy
to
find
where
information
lives
so
we'll
keep
you
posted.
A
All
right,
any
last-minute
walk-on
items,
comments,
questions
or
anything
else
for
this
week,.
E
Yes,
is
there
any
other
fit
that
folks
are
considering
implementing
network
v16
and
shall
we
start
brainstorming
what
the
network
codename
is
gonna,
be.
C
A
If
it's,
if
it's
more
helpful,
we
can
in
our
call
in
two
weeks,
I
can
bring
a
whole
slate
of
proposals
that
seem
like
they
may
be
ready
to
sort
of
move
into
sort
of
final
fifth
status.
Sorry
in
terms
of
completeness
not
in
terms
of
like
where
they
are
in
the
network
that
we
can
all
go
through
as
a
group
and
see
if
anyone
has
any
priorities.
E
B
Yeah,
I
think
it's
okay.
I
really
want
to
have
this
being
implemented
in
the
version
and
yeah
16.,
and
I
have
the
team
is
really
working
on
the
implementation
and
we
will
create
another
branch
of
this
big
specs
anchors
and.
B
Of
course
it's
about
the
good
nightmare,
yeah
goodnight
implementation,
so
I
was
thinking
that
we
will
have
a
reference
of
the
and
yeah
implementation.
Maybe
yeah
a
few
weeks
and
yeah
for
for
before
reveal.
A
B
No
and
yeah-
I
didn't,
I
think,
but
I
think
yeah
many
people
already
yeah
revealed
they
are
discussing
yeah
if
yeah.
If
it's
okay,
I
can
present
this
and
actually
yeah
this
meeting.
Yeah.
It's
okay.
A
A
All
right
anything
else.
D
One
question
question:
around
the
public
roadmap:
we
announced
that
the
submission
is
kind
of
over
what
would
be
the
follow-up
steps
and
where
do
we
discuss
the
ideas
that
are
presented
there?.
A
Yeah
great
question:
so
we
extended
the
sort
of
submission
timeline
through
the
very
beginning
of
this
week.
So
it
closed,
I'm
now
painstakingly
gathering
all
of
the
information
that
was
submitted.
There
were
lots
and
lots
of
submissions.
Not
all
of
them
are
projects
that
we
would
consider
within
scope
for
what
this
project
is
supposed
to
be.
A
However,
we're
going
to
try
and
find
a
way
to
like
sort
through
these,
so
that
we
can
still
show
you
know
we're
working
on
20,
wallets
and
blah
blah
blah
blah
lots
of
different
sort
of
additional
usability
and
features
that
will
also
be
added
on
top
of
the
network.
But
the
idea
here
is
that
by
the
end
of
this
week
that
data
will
be
preliminarily,
parsed
I'll
share
it.
A
If
anyone
wants
to
take
a
look
and
provide
feedback,
let
me
know
if
they
think
there's
anything
that
is
perhaps
missing
and
beginning
next
week.
I
will
be
organizing
it
into
a
visual
roadmap
that
we
can
share
more
broadly.
We
don't
have
a
strict
timeline
on
this,
but
in
the
next
week
and
a
half
we
should
have
at
least
a
draft
early
product
and
actually
sharing
it
with
the
broader
community
depends
on
how
much
feedback
we
get
in
this
sort
of
drafting
and
finalization
process.
A
And
if
actually
this
is
an
open
product,
you
can
see
all
of
the
submissions
on
github
if
you'd
like
I'd,
be
happy
to
bring
the
drafts
to
the
next
core.
Devs
call
just
again
to
due
diligence
on
making
sure
that
every
project
that
is
ongoing
is
adequately
accounted
for.
A
A
So
I
think
with
that,
I
think,
with
that
we
are
at
the
end
of
our
meeting
again.
Please
interrupt
me
right
now.
If
you
have
any
last
items
comments
whatever
it
may
be,.
C
Just
one
thought
about
this
format:
I
do
think
it's
a
better
use
of
time.
The
kind
of
more
open
share
any
updates
thing,
and
so
I
I
quite
like
it
one
flag
that
I'd
be
careful,
that
we
don't
start
taking
our
updates
async
into
the
zoom
chat,
just
because
that's
completely
opaque
to
anyone
viewing
this
recording
afterwards.
So
if
you
have.
C
That
you
think,
is
interesting
and
have
to
share
under
zoom
chat
unmute
and
give
your
verbal
update
in
15
seconds
or
whatever
just
for
for
people
viewing
after.
E
A
All
right
so
another
standing
topic
for
jennifer
in
particular
all
right.
I
think
with
this.
It
brings
us
to
the
end
of
our
meeting
for
this
week,
as
always
lots
of
follow-up
notes
to
come.
You
can
always
watch
the
meeting
recording
back
if
you
need
it,
and
I
think
I'm
actually
going
to
open
up
a
poll
in
slack
about
what
we
want
to
do
with
the
potential
for
two
meetings
or
different
meeting
times
each
week,
etc.
So
you
guys
can
all
vote
which
everyone
likes
to
do
usually
so
with
that.