►
From YouTube: Filecoin Core Devs #44 (Meeting 1)
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
A
All
right,
hi
everyone
good
morning,
good
afternoon.
This
is
file
coin,
core
devs
call
number
43
today
on
thursday
june,
2nd
happy
june,
and
this
is
meeting
one
of
two.
A
So
today
we
plan
to
go
through
our
standard
implementation,
team
updates
and
we're
also
going
to
go
over
some
proposals
for
the
new
file
coin.
Request
for
comment
which
brenda
from
the
boost
team
has
joined
us
to
discuss
and
also
go
over.
Some
pros
changes
to
the
structure
of
the
core
devs
call
to
be
a
little
bit
more
productive
going
forward.
A
So
with
that
lee.
Do
you
want
to
give
us
an
update
from
your
team
or
david.
B
With
the
building
actor
test-
and
we
are
about
done
with
the
tests
that
were
converted
from
go
and
we
will
continue
assisting
with
the
integration
tests,
but
we
will
split
our
team
in
two,
so
some
people
will
work
on
the
integration
test
and
some
people
will
move
back
on
on
forest
to
prepare
for
network
15
network
16..
A
Great
I
wanted
to
ask
about
this
last
bullet.
Last
I
had
heard.
I
know
your
team
was
not
preparing
to
upgrade
for
us
for
v16,
but
the
lotus
team
had
offered
some
additional
resources.
Are
you
planning
on
on
syncing
on
mainnet
or.
B
So
so
yes,
so
it
it
turns
out
that
that
might
so.
The
problems
that
we
were
having
in
the
past
might
have
been
due
to
like
some
internal
box
in
the
building
actors
that
appear
to
have
gone
away
or
been
fixed
over
the
last.
B
A
E
Oh,
this
team
updates
will
be
boring.
We
work
we
ship
another
feature
release
our
monthly
release
in
may,
including
a
couple
bug
fixes
like
not
much
to
mention
we
have
working
out.
We
have
been
working
on
network
v60,
upgrade
kofree's
fvmrc2
and
we
released
a
print
tag
to
upgrade
the
butterfly,
which
happened
this
tuesday
right
this
tuesday.
It
went
quite
smoothly.
Nothing
major
happened.
E
We
are
working
with
like
lotus
tscs
and
a
couple
community
members
to
do
more
like
test
days
over
the
next
week
over
the
next
the
next
week,
and
then
we
will
be
preparing
the
first
official
like
cold
freeze
rc,
while
including
the
calibration
upgrade
dates.
We
are
looking
at
the
week
of
sorry,
I'm
just
looking
at
my
calendar
of
like
third
case
to
do
the
calibration
upgrade
so
far
we
are
still
targeting.
I
think
we
are
on
track
of
upgrading.
E
I
mean
that
at
the
end
of
like
late
june
or
early
july,
depending
on
how
the
week
looks
the
huge,
the
biggest
blocker
today,
it's
like
cold
freeze
for
actor,
which
is
highly
dependent
on
the
testing
coverage
of
actor.
But
the
forest
team
and
sang
is
like
working
really
hard
on
that
and
though
thank
you
for
all
the
support
for
the
forest
team.
We
are
hoping
to
wrap
everything
up
by
the
end
of
next
week.
E
A
A
Okay,
so,
as
usual,
the
venus
team
isn't
going
to
join
us
this
morning,
but
their
updates
are
pretty
standard
from
weeks
past,
as
well.
Just
released
a
new
version
of
venus
cluster
continuing
to
integrate
the
fbm
and
they
plan
to
join
mainnet
at
the
end
of
june
or
early
july,
as
jennifer
mentioned,
and
they've
also
made
some
small
adjustments
to
the
venus
market
module
as
well
they're
going
to
continue
to
test
for
v16
move
over
to
butterfly
net
and
continue
to
make
some
of
those
module
enhancements.
A
A
All
right
great,
then
there
should
be
no
surprises
on
this
slide.
Today,
karth
is
continuing
to
handle
bug
bounties,
but
there
are
no
pending
security
issues
or
concerns
that
we
need
to.
Let
you
all
know
about
for
governance,
there's
been
no
big
changes
in
the
fips.
Currently
we
have
five
accepted
fips,
four
of
which
we're
going
to
be
introducing
in
b16.
A
As
you
all
know,
there
are
no
flips
currently
in
last
call,
and
we
do
have
a
couple
of
large
drafts,
many
of
them
from
alex
north,
who,
I
think,
is
going
to
present
some
of
his
new
proposals
in
two
weeks,
so
at
core
devs
meeting
44,
and
we're
also
going
to
talk
about
sort
of
implications
for
two
of
these
drafts.
A
Potentially
the
ask
v2
protocol,
but
the
indexer
advertisement
protocol
as
well,
and
also
boost
which
does
not
have
any
kind
of
fifth
draft
or
governance
documentation
yet,
but
which
likewise
will
fall
potentially
under
this
new
file.
Coin
request
for
comment
model
that
we're
working
on
right
now,
any
questions
about
fips
before
we
segue
into
that
topic.
A
Whoops,
I
think
I
put
these
out
of
order,
but
we
can
talk
about
the
network
v16,
as
jennifer
mentioned,
butterfly
net
has
been
upgraded
and
we're
looking
at
late
june,
potentially
early
july
for
the
overall
network
upgrade
jennifer.
Anything
you
want
to
add.
E
We
are
still
on
track
again
earlier.
We
can
have
in
two
weeks
calibration
upgrade
late
june
early
july.
We
want
to
do
the
minute
upgrade.
I
do
want
to
say
that
again,
this
is
a
huge
upgrade
in
the
network,
the
lotus
team
and
the
many
other
teams.
I
I'm
sure
that,
along
with
the
community,
we
are
planning
to
stay
a
little
bit
on
call
canada
post
upgrade.
E
C
A
Okay,
cool
anyone
else
from
the
forest
see
many
concerns
questions
anything
you
want
to
raise.
I
know
it's.
I
mean
a
huge
network,
upgrade
lots
of
testing
really
important
changes
happening,
but
obviously,
because
of
that
sort
of
a
tentative
timeline.
A
All
right,
then,
as
we
think
about
v16
and
plan
for
it,
jennifer
also
started
a
discussion
post
for
network
v17
and
right
now
it
seems
like
there's
two
sort
of
different
sort
of
schools
of
thought
emerging
about
what
would
be
best
for
this
upgrade.
A
One
is
jennifer's
proposal
which
you
can
speak
about
sort
of
a
smaller
community
upgrade
to
get
the
broader
file
clean.
You
community,
used
to
upgrading
under
the
fbm,
and
the
other
is
sort
of
saying
that
this
isn't
really
necessary
that
they
can
sort
of
onboard
to
any
new
procedures
during
b16
and
that
v17
should
be
sort
of
a
fifth
packed
large
upgrade,
as
all
of
our
other
recent
upgrades
have
been.
A
So
we
certainly
have
a
few
more
weeks
to
figure
out
which
direction
we
want
to
go,
and
I
think
we're
going
to
end
up
back
at
that
question.
That
ayush
has
been
asking
for
a
few
months
about
how
do
we
scope
the
size
of
appropriate
network
upgrades,
but
wanted
to
sort
of
start
that
conversation
here
as
well
and
see
if
anybody
has
any
preferences
or
opinions
they
wanted
to
share.
E
So
just
want
to
give
everyone
here,
update
like
after
I
propose
a
very
small
like
practice
upgrade
like
since
the
last
quarter.
I've
been
chatting
with
different
parties
a
little
bit
more
about
the
idea.
I
think
I
got
like
a
mix
like
feedbacks,
which
some
of
I
agree.
It's
like
it's
also
possible
that
tuesdays
first
is
like
the
community
and
the
implementation.
E
Should
team
should
be
ready
for
this,
such
a
small
upgrade
to
have
to
happen
post
the
upgrade
in
case
any
you
know,
network
incident
is
introduced
by
by
the
new
actor
or
fvm,
so
that
can
be
our
practice
already
so,
like
you
know,
implementation
teams
should
already
be
preparing
a
sort
of
like
a
run
book.
How
we
want
to
be
responsive
when
certain
one
situation
occurs
and
then
the
other
thing
is
like.
Is
it
the
effort
worth
it
for
doing
a
practice?
E
Because,
like
you
know,
you
have
to
work
with
the
risk
there
is
like?
Maybe
the
storage
provider
community
can
be
more
responsive
with,
like
two
two
very
close
upgrade.
Would
the
be
the
other
stakeholders,
for
example,
exchanges
applications.
All
those
parties
are
also
be
responsive
and
like
be
ready
for
two
to
upgrades.
E
The
answer
is
like
known,
so
that's
why,
let's
like
keep
discussing,
I'm
wondering
how
we
and
other
teams
like
think
about
that,
but,
like
I
I'm
personally
I'm
okay
to
say,
maybe
we
can
skip
the
small
practice
while
I'm
working
on
a
larger
scope
one
but
like
we
need
more
discussion
on
the
scope,
but
yeah
be
any
thoughts.
C
Yeah,
so
from
what
I'm
understanding
after
the
nv16
upgrade,
you
guys
want
to
have
some
form
of
buffer
in
case
things
go
wrong
to
kind
of.
If
we
need
to
roll
back
certain
things
or
fix
any
bugs
for
related
to
the
fvm
upgrade
right,
that's
one
and
the
other
one
is
for
nv17.
I
glimpsed
to
the
fifties
that
was
there.
One
is
like
an
address
change.
One
was
like
something
like
an
ens
ems
kind
of
stuff
on
the
five
second
network
and
another
one
was
something
on
the
attribute.
E
Think,
there's
more
being
added
by
the
product
opportunity
team.
However,
a
lot
of
things
are
like
protocol
changes
like
implementation
effort,
it's
like
minimal,
so
yeah.
I
think
what
lotus
team
you're
saying
today
is
like
oh,
okay,
saying
bring
up.
A
very
good
point
is
like
we
should
figure
out
each
team's
resource
like
a
location
we
can
have
in
q3
before
we,
we
define
the
scope
so
for
low
decide.
E
For
now
we
are
okay
to
say
we
will
have
like
at
least
two
engineers
to
commit
60
of
the
capacity
across
q3
to
support
this
like
upgrade.
So
this
is
from
our
set,
obviously
based
on
like
how,
if
an
m2
scope
changes
how
long
this
maintenance
scope
changes,
we
may
have
more
later,
but
so
far
this
is
what
we
are
comfortable
like
commit
to.
C
Yeah,
okay,
david:
do
you
have
a
idea
on
how
much
or
when
can
we
get
to
nv16
at.
B
This
point
right
now:
I
do
not
I'm
still
surprised
that
the
issues
that
we've
been
having
have
have
been
fixed
by
by
the
lotus
team,
so
yeah-
I
I
I
don't,
have
any
estimates
like
when
will
we
be
able
to
join
netflix,
16.
yeah,
okay,.
C
So
perhaps
once
we
have
a
clear
idea
on
where
we
will
be
in
nbc16,
we
can
then
probably
state
with
more
clarity
what
how
much
scope
of
the
work
we
can
handle.
At
this
point.
Personally,
I
would
say
smaller
the
scope
better
because
we
have
been
working
on
the
mv
16
upgrade
and
we're
still
a
little
behind
on
that
by
default,
so
smaller
scope
would
be
better
for
nv17,
but
if
we
make
it
to
nv16
in
a
timely
manner
without
any
problem.
C
Yes,
caitlin,
I
think
I
mentioned
about
the
scope
and
the
other
one
I
mentioned
about
the
timeline
yeah
and,
and
I
kind
of
forgot,
what's
the
other
one
but
yeah
that's
kind
of
if
we
make
it
in
conclusion,
if
we
make
it
sooner
with
the
nv16
upgrade,
we
would
be
able
to
we'll
be
in
a
better
position
to
say,
but
right
now
I
think
the
smaller
scope
would
help
for
nb17.
If
that
makes
sense
to
you
guys.
A
I
think
that
sounds
good.
I
think
we
will
have
to
begin
to
make
some
more
concrete
decisions
about
which
types
of
steps
will
be
included
in
this,
and
also
what
our
initial
projected
timeline
might
look
like
in
the
next
meeting
or
two,
but
as
we've
seen
this
time
also
those
things
are
subject
to
change.
A
Also,
sorry
lee
I
I
know
I
distracted
you
with
the
message
while
you're
talking,
I
suppose
my
question
and
I
think
this
is
for
jennifer,
but
you
may
not
know
yet
either
when
we
think
about
the
larger.
What
a
larger
fip
upgrade
may
look
like.
I
assume
most
of
those
are
some
of
the
recent
proposals
that
have
come
from
the
like.
I
think,
protocol
opportunities
team,
correct.
None
of
those
are
the
the
next
milestone
for
the
fbi,
correct.
E
E
So
we
really
want
to
consider
that
protocol
opportunity
team
was
like
holding
off
that
because
of
the
resource
issue,
but
now,
like
all
this,
may
help
there
so
yeah
might
be
back
to
the
table
and
but
like
that,
one
would
be
a
big
one.
A
lot
of
like
cover
factory,
yeah,
yeah
and
the
other
one.
A
fifth
like
034
is
a
very
small
one
and
it
doesn't
require
any
implementation
work
beneficially.
E
I
dress.
Well,
I
believe
the
gold
version
has
already
existed
coded
by
venus
team.
I'm
on
the
assumption
that
venus
will
do
the
beauty
active
one.
We
will
see
how
that
goes,
that
one
will
need
some
like
kind
of
implementation,
support
just
to
expose
that
future
for
the
users,
but
that's
mostly
on
the
start,
like
a
minor
side
of
the
things.
E
That's
what's
the
node
domain
separation
of
signatures?
Yes,
that
that's
a
thing
that
hello,
this
kinda
wanna
do,
and
we
just
have
a
discussion
this
morning.
We
will
be
dropped.
A
newest
member
of
florida's
team
will
open
up
discussions
soon
and
seeking
for
ideas
on
how
we
handle
this.
We
still
have
some
like
unsolved
questions
on
how
we
can
introduce
that
to
falcons
so
like
we
will
ask
for
another
implementation
team
idea
later
as
well.
I'm
not
too
sure
what
about
the
system
design
discussion
was.
Let
me
take
a
look.
C
The
same,
I
think
the
domain
separation,
I
think,
oh.
C
So
from
what
I'm
understanding
the
fib-0034
doesn't
require
node
implementations
to
get
involved,
correct
and
and
f5p0029
venus
team
is
spearheading
that
process
and
the
third
one.
Sorry
I
just.
C
Okay
and
the
third
one
is
basically
where
we
kind
of
want
some
discussion
around
and
see
basically
so
okay,
so
this
seems,
I
think,
like
a
smaller
scope
in
general.
Unless
you
know
people
start
adding
tens
of
fibs.
I.
E
D
E
A
I
I
agree
with
this.
One
challenge
on
my
end,
related
to
the
scope
is
that
there
are
a
lot
of
projects
in
the
works
that
have
not
been
fully
communicated
yet
either
as
fifth
drafts
or
to
like
me
directly.
A
So
I'm
going
to
touch
base
with
with
alex
and
the
protocol
opportunities
team
and
also
poke
around
and
make
sure
that
there's
no
other
big
fit
drafts
that
teams
are
working
on
that
they
expect
to
land
that
we're
not
currently
aware
of
and
I'll
try
and
update
the
the
the
thread
that
you
started
on
github
jennifer
about
b17
with
all
of
the
potential
fips
that
we
could
include
just
so.
We
have
a
single
point
of
reference,
but
I
think
your
list
here
is
is
most
most
of
it.
Yeah.
E
I
think
one
thing
can
be
super
helpful.
It's
like
to
have
like
kind
of
like
a
submission
that
I
kind
of
say
of
like
the
scope
of
like
only
17,
and
I
think
alex
is
aware
of
that,
but,
like
let's
double
confirm
with
that
team,
I
also
think
crypto.
Econ
team
may
have
some
ideas,
so
I
will
reach
out
there
as
well
and
maybe
a
governance
thing
that
we
should
set
up
just
like.
Of
course,
we
want
to
be
reactive.
A
Yeah
so
one
thing
we've
also
been
discussing-
and
this
is
not,
unfortunately,
something
that
we
could
do
for
v17.
I
don't
believe
there's
not
enough
time,
but
one
way
we
could
think
about
scoping.
The
size
of
fips
upgrades
is
to
actually
put
together
an
implementation
plan
before
the
fifth
draft
is
accepted.
So
that
way
we
can
forward
projects
the
amount
of
capacity
needed
for
varying
engineering
teams
to
actually
implement
on
top
of
regular
maintenance
and
enhancement
work.
A
This
is
something
that
lee
and
I
have
been
looking
at
and
we'll
continue
to
kind
of
poke
around
with,
but
yeah.
I
agree.
We
need
to
kind
of
figure
it
out
sooner
rather
than
later.
Even
if
other
elements
from
b17
are
undecided.
C
Yeah
I
liked
what
jennifer
said
you
know:
have
a
strict
deadline
to
submit
the
fifth
and
then
lock
down
the
scope.
I
would
also
suggest
that
if
these
some
of
these
fips
are
proposed
by
other
teams
that
we
use,
one
of
the
code
f
calls
to
basically
talk
about
that
fib
and
maybe
they
can
present
it.
C
So,
for
example,
I'm
not
sure
if
venus
team
did
it
for
the
ip0029,
they
might
have
at
some
point
in
time
or
if
the
other
fibs
that
we're
going
to
include
in
the
mb17,
we
could
use
a
presentation
and
give
some
feedback
and
also
receive
some
more
understanding
of
the
rfip.
A
Yeah,
so
all
teams
are
required
to
present
their
their
fifths
when
they
vote
before
they
can
be
accepted,
so
the
stevens
529
this
was
presented
months
ago.
The
challenge
is
that
like
fips
do
take
months,
and
so
sometimes
you
get
the
presentation
and
you're
like
okay,
great
sounds
fine
and
then,
when
it
comes
to
actually
implementing
you
do
not
retain
any
of
that
information
and
it's
unrealistic
to
expect
you
to
go
back
and
like
re-watch
those
videos.
A
So
we
can
talk
about
ways
like
make
sure
that
we
have,
I
think,
just
like
better
representation,
especially
for
folks
who
frequently
author
fip,
so
that
they
can
continue
to
kind
of
speak
to
their
fix.
The
way
I
think
raul
did
really
effectively
with
the
three
fvm
fifths.
But
the
one
thing
I
do
want
to
know
about
the
like
hard
deadline
for
fips
is
that
we
don't
have.
A
We
don't
have
preset
upgrade
timelines
or
upgrade
quarters,
because
we
want
to
be
reactive,
the
same
thing
with
fips,
I'm
cautious
about
a
deadline
only
because
our
upgrade
timelines
do
shift,
and
it's
not
to
say
that
you
know,
as
we
shift
timelines
we're
willing
to
accept
more
fips.
But
it's
just
to
say
that
like
fips
process
should
be
long
and
people
should
be
indicating
their
work
much
sooner
in
the
process
than
they
are
currently.
So.
One
challenge
that
trying
to
work
around
or
address
directly
is
getting
people
to
indicate
the
work
that
they
are
doing.
A
That
will
require
a
fifth
in
advance
of
them,
having
a
fully
complete
draft
that
they've
already
scoped
and
tested
that
will
make
it
so
that
we
don't
get
any
of
these
kind
of,
like
last
minute,
fully
fledged
fips
that
research
teams
expect
to
be
fully
implemented
right
away.
But
this
is
sort
of
a
this
is
sort
of
a
learning
challenge
that
we've
had
with
just
sort
of
the
scale
of
the
file
queen
ecosystem
and
the
fact
that
fips
come
from
so
many
different
directions.
A
C
Yeah,
so
if
we
want
to
be
flexible
with
the
process
which
we
understand,
we
need
to
be
to
a
certain
extent.
What
we
could
do
is
something
like
okay.
Now
we
know
that
network
16
is
getting
into
place
right.
So
during
this
time
we
can
allocate.
You
know,
four
to
six
weeks
till
the
network.
16
is
finalized
to
get
the
fips
for
17
and
not
like
you
know,
two
months
from
now
for
17.
and
when
network
17
is
in
place.
During
that
time,
we
can
have
like
a
cushion
time
of
again.
C
E
We
should
like
include
it
and
that's
how
we're
doing
this,
but
ideally
I
want
us
to
leverage
this
call
with
all
the
engineers
to
actually
evaluate
the
fifths
more
and
see
what
does
it
like
benefit
the
network,
like
what
opportunities
does
it
like
unlock
for
the
network
and
prioritize
them?
Those
way
we
shouldn't
be
like
defining
the
scope
solely
on
okay.
This
takes
less
implementation.
Time
to
work
out,
like
even
the
smallest
fit,
will
take
some
engineering
resources.
E
However,
if
we
can
spend
that
resources
on
a
high
priority
high
opportunity-
fifth,
maybe
we
should
do
that.
So
that's
another
thing
that,
like
I
would
propose,
is
to
have
more
developers
actually
joining.
This
call
talk
about
the
fifth
from
a
technical
perspective
and
before
before
we
make
any
decisions.
I
think.
A
So
that's
a
great
segue
into
talking
about
we'll
jump
around
and
talk
about.
Some
proposed
changes
to
the
core
devs
calls,
because
I
think
this
touches
on
some
challenges
we've
been
having,
and
it's
also
something
that
lee
and
I
have
been
talking
about
over
the
past
couple
of
weeks
in
particular
yeah
yeah
jennifer.
I
couldn't
have
like
created
a
better
audience
plant.
A
That
was
a
great
segue,
but
I
think
the
problem
we
have
now
is
that
this
call
is
mostly
just
implementers
right,
which
is
obviously
really
important,
but
again
that
creates
these
sort
of
black
boxes
around
what
other
teams
are
doing.
We
have
really
inconsistent
attendance
from
like
other
developers
in
the
filecoin
ecosystem,
even
though
they
are
really
involved
in
governance
in
sort
of
an
async
manner.
A
It's
difficult
to
have
like
robust
conversations
we
are
used
to
speaking
with
each
other,
because
we
do
very
frequently
but
again,
it's
sort
of
that
interplay
between
different
teams
and
people
working
on
different
aspects
of
filecoin.
That
makes
this
really
productive
and
it's
hard
to
say
that,
like
there
is
a
very
clear
value
or
purpose
for
the
core,
devs
call
other
than
sort
of
touching
base
and
checking
in
when
we
don't
have
that
participation.
A
So
one
thing
that
lee
and
I
discussed
is
like
a
potential
solution-
is
actually
changing
the
structure
of
the
call
to
be
much
more
structured,
so
it
would
become
a
monthly
meeting,
not
bi-weekly,
and
we
would
probably
have
it
for
about
an
hour
and
a
half
core
devs
would
be
recognized
as
more
privileged
roles,
so
we
would
work
together.
As
a
group,
I
have
a
feeling
jennifer
lee
and
I
would
would
kind
of
vet
this
list
where
core
dev
is
a
designation,
that
people
sort
of
receive.
A
You
receive
it
by
being
invited
to
the
meeting
and
there
would
be
attendance
requirements.
So
if
you
miss
three
meetings
or
whatever
within
a
period
of
time,
for
example,
you
will
be
removed
from
the
meeting
going
forward.
This
is
a
structure
that
all
of
the
storage
provider
working
groups
use
and
the
falcon
plus
governance
team
uses,
and
it's
a
good
way
to
kind
of
reinforce.
A
The
idea
that
you
should
be
participating
in
this
meeting,
if
you
have
the
privilege
to
attend
and
also
creating
clear
standards
and
a
more
formalized
agenda,
so
moving
away
from
doing
upgrade,
updates
which
people
should
know
where
to
find
those
things
within
slack,
but
having
more
broader
conversations
with
greater
facilitation,
so
that
we
could
be
talking
about
those
hip
drafts
over
time
that
we
can
have
big
planning
decisions
and
because
again,
this
is
only
going
to
be
happening
on
a
monthly
basis.
A
There
is
more
of
an
emphasis
on
having
teams
who
do
come,
be
prepared
for
the
meeting,
understand
the
materials
that
are
going
to
be
presented
in
advance
and
also
be
ready
to
sort
of
contribute
to
conversations
about
implementation
pathways
about
security
needs
or
about
whatever
that.
You
know,
high
value,
high
work,
reward
sort
of
formula
is
going
to
be
for
different
fips
that
are
open
for
upgrades.
A
So
any
immediate
thoughts,
concerns
or
other
ideas
about
this.
C
Yeah,
you
mentioned
there's
a
poor
definition
of
a
code
and
there's
an
assumption
that
codex
whole
visible
leadership
within
the
ecosystem
right,
so
I'm
could
you
clarify
clarify
on
on
that
a
little
bit.
A
Yeah,
so
we
say
a
core
dev:
is
anyone
who's
invited
to
join
this
call,
but
there's
not
much
of
a
definition
beyond
that.
Usually
the
ones
that
I've
leaned
on
the
past
is
saying
that
a
core
dev
is
anyone
who
is
responsible
for
you
know,
making
or
implementing
changes
or
proposing
changes
to
sort
of
those
like
core
consensus,
dependent
activities
within
the
network.
A
But
the
definition
is
sort
of
open,
and
I
don't
think
everyone
like
has
a
really
clear
understanding
of
what
it
is
and
historically
this
hasn't
really
mattered
right,
but
going
forward.
And
what
we're
going
to
talk
about
at
the
end
of
the
call
today
is
going
to
be
this.
This
file
coin
request
for
common,
which
specifically
asks
core
demps
to
make
decisions
about
what
standards
ought
to
be
adopted.
A
So,
instead
of
doing
this
more
kind
of
open
and
unstructured
community
process
which
we
use
for
fips,
it's
going
to
be
pretty
clear,
cut
and
dry
kind
of
vote
in
the
meeting,
and
that's
that
and
as
we
kind
of
give
that
authority
to
core
devs,
you
want
them
to
be
like
a
clearly
defined
group
as
well.
A
F
Yeah,
I
have
a
few
thoughts
about
this.
Thanks
for
picking
up
the
this
thread
broadly
agree
with
some
of
the
outline
with
most
of
the
outline
here,
and
I
I
I
do
think
we
have
some
changes
that
need
to
be
made.
F
My
chief
concern
is
how
do
people
who
are
not
core
dads,
who
have
one-off
suggestions-
and
you
know-
we've
had
a
lot
of
these
conversations
in
the
past
right
where
someone
who
has
a
lot
of
insight
into
vm
design
on
blockchains,
wanted
to
join
the
call
and
share
their
opinions
in
sync
and
have
a
one-on-one
conversation
or
not
one-on-one,
but
have
a
conversation
about
that
this
specific
topic.
F
So
I
want
to
make
sure
that
that
forum
continues,
for
you
know,
people
both
active
members
of
the
community
as
well
as
just
people
flying
by
who
have
a
lot
of
german
experience
to
share.
So
that's
one
fly,
the
other
thing
is
yeah.
I
think
I
think
a
monthly
meeting
probably
makes
sense.
I
feel
like
the
value
of
the
coordinate
scholar,
at
least
the
the
event
that
I
kind
of
take
away,
certainly
fluctuates
a
lot
as
we
get
very
close
to
network
upgrades.
It's
a
lot
of
like
closing
coordination.
F
You
know
handing
off
and
right
now,
teams
are
working
more
closely
with
each
other
than
ever
before.
You
know.
Point
of
the
forest
team
is
working
with
a
bunch
of
the
lotus
team
on
testing
the
shared
resource
and
so
on,
whereas
when
we
are
further
away
from
a
network
upgrade
then
sometimes
they're,
you
know
there's
less
less
activity,
I
suppose
so
I
want
to
make
sure
so.
I'm
interested,
I
guess
in
that
last
point
on
what
you're
envisioning
in
the.
F
How
do
we
coordinate,
updates
and
small
needs
in
weekly
collaborative
scrum
meetings
so
so
that
we
can
maintain
that
close
coordination
when
needed
and
then
the
core
dev
meeting
can
be.
You
know
something
we
give
a
lot
of
attention
to
when
everyone
takes
yeah
treats
is
important.
Then
we
can
have
these
good
conversations
there.
A
Yeah,
I
think
those
are
great
questions
so
yeah
to
your
point
about
people
who
are
not
cordevs
being
able
to
contribute.
We
want
that
to
continue.
Brenda
is
not
usually
a
core
dev
but
she's
here,
because
she
has
someone
to
discuss
with
us.
So
I
think
that's
great.
We
should
have
advisors
and
we
should
allow
people
to
come
in
as
observers
or
whatever
you
want
to
call
them.
A
The
process
would
be
the
same.
If
you
want
to
come
just
ask,
and
we
can
add
you
if
it's
relevant,
I
think
the
the
reason
we
would
sort
of
gate
the
meeting
for
core
devs,
more
formally,
really
has
to
do
with
instilling
the
sense
of
like
if
you
are
invited
to
this,
you
need
to
attend.
So
it's
not
to
say
that
we
want
to
do
this
to
like
restrict
participation
like
keep
others
out.
We
want
to
actually
like
get
people
to
come
in
participate
if
that
makes
sense,
and
for
the
second
one.
A
A
This
is
like
very
variable,
but
something
that
lee
and
I
had
discussed
and
that
he
had
asked
for
and
a
certain
way
was
the
idea
of
like
doing
more
team
check-ins
on
sort
of
in
sort
of
an
agile
way,
so
having
15
or
20
minutes
stand-ups
at
the
end
of
the
week,
for
example,
just
for
teams
to
check
in
less
formal
than
I
think,
the
30-minute
bi-weekly
meetings
that
are
sometimes
used
and
also
a
little
bit
clearer
than
having
to
rely
on
slack,
which
I
think
for
all
of
us
can
get
very
overwhelming
at
times,
especially
as
we
near
big
work
changes
like
a
network
upgrade
but
again.
A
This
is
this
is
open,
and
this
is
more
for
implementation
teams
to
decide.
So
if
we
move
to
sort
of
a
monthly
meeting
format,
we
want
to
make
sure
that
people
are
still
able
to
communicate
their
needs,
because
we
know
that
they
happen
in
more
than
a
monthly
kind
of
fashion.
And
so
it's
just
to
say,
if
we
reduce
access
to
this
meeting,
we
cut
it
in
half
the
number
of
times
it's
held.
A
Yeah,
so
the
two
meeting
structure
is
not
working.
The
second
meeting
right
now
is
only
myself
alex
and
alex
north
and
stephen,
it's
great
to
talk
to
the
two
of
them.
The
three
of
us
kind
of
usually
hang
out
on
those
calls
and
just
sort
of
chit-chat,
but
it
is
not
a
cordov's
call,
it's
not
productive
and
it
also
creates,
I
think,
a
chasm
between
the
things
everyone
wants
to
talk
about
and
needs
to
talk
about
lotus
and
forest
work
really
closely
together.
A
Venus
is
obviously
important,
but
hasn't
been
working
as
close.
They
should
be,
or
they
should
at
least
have
the
opportunity
alex
north
is
offering
a
ton
of
really
high
value
fips.
He
should
be
able
to
have
a
conversation
with
a
broader
group
and
not
just
myself
and
stephen.
So,
potentially,
what
we
could
do
is
on
that
monthly
basis.
A
We
could
alternate
between
what
in
north
america
is
in
the
evening
time
in
the
morning
time,
but
I
think
hopefully
also
reducing
it
to
one
month
means
so
that,
if
it's
sort
of
inconvenient
for
your
time
zone
that
it's
at
least
only
once
a
month.
F
C
Yeah
and
to
add
to
katelyn's
and
the
other
general
idea
is
that,
like
at
least
for
myself
and
the
forest
team,
I'm
assuming
that
we,
I
think
it
was
really
helpful
to
just
think
right
on
a
standard
basis,
even
if
it
was
for
five
minutes
just
on
a
day
to
day,
and
I
think
that's
something
node
implementators
could
do
so
that
we
are
not
really
waiting
for
the
codeless
call,
which
is
happening
in
one
month
to
sync,
so
just
think
on
a
weekly
basis
for
10
minutes
right
and
kind
of
keep
that
routine
going.
C
I
think
that
really
helps
to
get
things
into
consensus.
That's
what
I
think
the
last
line
is
here
implemented
or
should
consider
updates
and
small
needs
in
weekly
collaborative
meetings.
E
I
think
that,
like
I
think,
like
you,
know,
having
forrest
and
lola's
joining
the
same
like
a
stand-up
like
daily
the
shared
effort,
unlike
test
the
coverage,
is
it's
been
super
helpful
and
I
think
we
should
like
just
like
create
ad
hoc,
like
shared
stand-ups,
as
the
collaboration
project
goes.
If,
like
we
have
a
shared
project,
I
think
we
should
do
more,
like
you
know,
stand
up
like
together.
That
makes
sense.
E
It
makes
sense
suggesting
unless
like
a
frequent
like
frequency,
because
a
lot
of
times
unless
you're
like
urgent,
like
network
upgrades
load,
this
has
a
lot
of
like
maintenance
work
or
like
lotus
project
that,
like
I
would
imagine
forest
doesn't
really
care
about,
but
I
still
think
we
should
think
because
some
of
the
ideas
we
have
we
would
love
to
share
with
forest
or
like
venus
or
other
teams
and
see.
Maybe
we
can
create
collaboration
opportunities.
So,
let's
say
like
maybe
we
start
with
bi-weekly.
F
Yeah
and
I
think
the
value
of
these
yeah,
these
weekly
value
release
crumbs,
will
be
potentially
be
more
useful
when
we're
not
in
the
network
upgrade
sprinting
phase,
because
we're
working
towards
the
network
upgrade
we're
talking
to
each
other
because
we're
we
have
to
be
aligned,
whereas
yeah,
when
we're
not
actively
moving
towards
something
it'll,
be
good
to
stay
in
touch
online,
especially
now
that
we
have
built-in
actors
and
fbm
as
shared
commodities
for
all
our
teams.
I
think
it'll
be
useful
to
you
know
this.
F
E
Just
like,
for
example,
like
lotus,
is
thinking
about
like
a
lotus
project
for
like
live
notes,
and
things
like
that
and
while
I
talk
to
zen,
it's
like
ground
zero
and
he
he
is
very
interested
in
like
how
foreign,
like
you
know,
I
feel
like
different
implementation
can
have
different
like
purpose
like
the
main
use
case
of
that
I,
like
these
other
ideas,
I
would
love
to
discussing
such
thing
just
like
to
inspire
each
other
a
little
bit,
maybe
fun.
I.
G
F
F
See
that
more
and
more
as
we
as
we
have
more
people
at
least
speaking
for
lotus,
we
are,
we
generally
have
more
people
interested
in
our
work
and
so
we're
having
the
need
to
like
write
down
what
we're
doing
a
little
bit
more,
and
it
is
it's
good
for
our
own
organization
as
well
yeah.
We
know
what
we're
trying
to
get
done
in
the
next
weeks
or
what
we
did
get
done
in
the
past
two
weeks
and
so
on.
So
yeah,
I'm
on
board,
with
with
kepler's
shared,
pushing
each
other.
F
E
A
Yep
a
great
point:
I
think
we
can
separate
them
out
and
again
those
like
kind
of
scrum
needs
or
those
ad
hoc
meeting
requirements
that
your
teams
have.
If
it's
expected,
that
those
kinds
of
planning
things
happen
outside
of
this,
it's
easier
for
you
to
just
make
decisions
about
what
you
need
in
more
of
an
ad
hoc
fashion.
So
I
think
it
seems,
like
people
generally
kind
of
agree,
that
we
need
to
kind
of
refresh
the
format
a
little
bit
so
I'll.
Just
write
up
the
changes
more
formally
post
it
in
the
thread.
A
So
with
that
said,
I
do
want
to
jump
to
the
last
topic
because
we
are
reaching
close
to
the
end
of
the
hour,
but
I
wanted
to
make
sure
that
we
had
time
to
talk
about
this
and
that
brenda
could
weigh
in
also
since
she
took
time
to
join
us
this
morning.
But
if
you
haven't
seen
posted
a
proposal
for
the
filecoin
request
for
comment
procedure,
if
you
haven't
read
through
this
it's
kind
of
long,
it
will
take
you
15-20
minutes.
A
So
there
is
a
proposed
workflow,
it's
very
similar
to
the
fixed
process.
The
only
significant
difference
is
one
that
we
would
want
sort
of
broad
adoption
before
declaring
that
something
is
a
network
standard
and
the
process
of
confirming
that
someone
is
or
something
is,
a
network
standard
would
actually
fall
to
cordovs,
which
is
why,
again,
we
want
to
revamp
this
meeting
and
make
it
as
as
good
as
it
can
be
brenda.
A
G
Yeah
sure
yeah,
I
think,
for
for
boost.
It's
like
I'm
talk
about
this
with
jennifer
a
little
bit
as
well,
but
I
think
a
lot
of
it
is
like
encouraging
people
to
upgrade
to
boost,
even
though
it's
not
like
it
doesn't
yeah,
it's
not
consensus.
Breaking
it's.
Basically,
the
main,
I
guess
addition
is
to
live
p2p
protocols
in
terms
of
how
you
can
do
storage
deal
making
and
look
for
storage
deal
status
so
yeah,
I
guess
a
lot
of
it
here
would
be
more
like
hey.
G
You
know,
as
I
guess,
the
dev
team
who
is
working
on
markets
like
how
can
we
use
frc
as
a
method
or
a
way
to
kind
of
better
publicize
like
the
push
that
we
want
to
have
to
encourage
people
to
use
boost,
since
it
has
a
lot
of
improvements
based
on
the
feedback
that
the
storage
writer
community
had
given
us
around
around
like
the
entire,
like
markets,
stuff
and
so
yeah.
I
guess
for
me,
I'm
just
trying
to
figure
out
like
what
is
the
content
that
should
be
included
in
this
frc.
G
That
could
be
actually
like
useful
or
like
helpful
to
the
core
devs
team
and
the
community
in
general.
It
might
not
necessarily
be
super
heavyweight,
but
but
yeah
we
have
like
docs
pages
and
stuff.
That
could
be
helpful
for
people
to
see
but
yeah.
That's
that's
it
from
me.
I'm
just
yeah
trying
to
better
understand
like
what
like
what
is
the
information
that
that
would
be
important
or
critical
for
us
to
have.
C
Yeah,
I
have
a
question
because
brenda
is
here:
I'm
still
having
a
little
difficulty
understanding
how
how
this
frc
is
different
compared
to
something
like
a
meta
eip
or
an
informational
eip.
I
know
that's
more
like
extreme
level
stuff,
but
it
seems
to
me
it's
very
similar
that
more
like
informational
or
meta-level
stuff
goes
into
it
or
I'm
just
not
understanding
it
well
enough.
A
I
think
it's
important
to
know
that
we
don't
like
copy
the
ethereum
governance
process.
You
know
word
for
word,
so
we
do
have
informational
thefts.
Fib
18
is
the
one
that
changed
minor
to
storage
provider,
for
example-
and
I
think
the
logic
is
holds
that
we
don't
have
a
lot
of
these,
but
they
are
for
more
sort
of
fundamental
changes
to
the
way
the
community
operates.
A
Another
one
I
can
think
of
is
if
there
was
like
a
meta
governance
proposal
for
filecoin
plus.
That
would
still
need
a
fip,
for
example,
but
the
difference
here
is
that
a
filecoin
request
for
comment
is
really
a
standard
that
has
been
you
know,
sort
of
adopted
or
implemented
in
more
of
a
sort
of
an
ad
hoc
or
more
organic
way,
and
all
we're
doing
with
the
frc
is
like
indicating
that
this
is
a
recognized
best
practice
for
the
network.
A
So
it's
not
so
much
about
like
making
a
change
it's
more
about
signifying
cohesion.
If
that
makes
sense.
C
G
Yeah,
I
mean
I
guess,
like
as
an
example
with
boost
it's
like
we're,
introducing
some
new
like
they're.
Actually,
the
only
I
guess
new
thing
that's
been
introduced
with
boost
is
like
the
lib
p2p
protocols
in
terms
of
how
you
can
propose
a
storage
deal
on
how
you
can
basically
check
storage
deal
status,
but
other
than
that,
like
nothing,
really
has
changed.
If,
if,
if
you
know
what
I
mean,
it's
like,
you
know
the
market's
still
like.
G
Basically,
we
have
added
like
a
new
ui
on
top
of,
like
basically
information
that
you
might
have
around
your
storage
deals,
and
you
can
actually
see
like
how
your
funds
are
being
worked.
So
there's
like
a
nice
ui,
there's
actually
some
additional
methods
that
you
can
do:
data
transfer
from
the
storage
broader
side,
so
you
can
transfer
data
via
http
instead
of
you
know,
via
just
purely
graph
sync
and
we're
hoping
to
make
more
improvements
in
the
boost.
G
I
guess
like
markets
like
module
around
retrieval
as
well,
and
so
I
think
the
goal
here
is
like
hey.
We
want
to
encourage
people
to
move
to
use
boost
over
the
existing
market
subsystem,
even
though,
like
technically
you,
I
guess
you
know
it's
like
you,
don't
necessarily
have
to
move,
but
we
want
to
encourage
people
to
move,
because
all
the
new
improvements
and
new
features
will
be
added
in
the
boost
system.
G
However,
like
all
the
changes
that
are
made
in
boost,
don't
actually
affect
consensus
like
it's
not
like
it's
not
like
anything
different
necessarily
happens
on
chain.
It's
just
the
way
that
the
storage
writer
is
communicating
with
with
the
client
like
you
can
have
additional
ways
to
like
move
your
data
around
right,
and
so
that
type
of
stuff
is
not
actually
like.
C
Yeah,
so
I'm
getting
so
from
what
I'm
understanding
it's
like
the
behavioral
changes
that
requires
you
know,
users
to
adopt
a
new
kind
of
system
or,
like
just
user
changes.
I
think
that's
what
I'm
getting
at
behavioral
user
changes
can
go
through
the
frc,
which
is
not
necessarily
an
fip,
because
the
5b
is
more
like
a
technical
change
to
the
protocol.
Is
that
correct
to
say
here.
A
I
think
it
is,
I
think,
another
way
to
to
think
about
differentiating.
These
is
kind
of
like
the
role
of
like
community
consent
right
so
like
with
fips.
These
are
big
fundamental
changes
and
the
way
we
organize
this
is
around.
You
know:
here's
a
proposal.
A
We
think
either
it's
a
technical
change,
it's
protocol,
you
know
it
makes
file
coin
work
better
more
intuitively
or
it
could
be
something
else
right,
for
example,
but
it's
to
say
we
recognize
this
adoption
and
we
want
to
like
draw
reference
to
it
so
that
if
there's
new
developers
coming
to
the
network
or
whatever,
they
also
can
like
quickly
find
what
is
the
best
practice
for
everyone.
E
It's
like
like
standard
it's
like
if
you
have
the
token
center,
that's
adopted
by
the
communities
and
the
wallet
tooling,
that's
built
on
top
of
all
coin
can
just
like
look
into
this
standard
and
know
like
what
they
need
to
support
so
that
they
can
interact
as
with
as
many
token
contracts
as
possible.
However,
you
can
still
have
like
multiple
token
contracts
right
like
if
you
don't
like
the
current
one,
I
can
propose
another
one.
You
could
deploy
your
own,
it's
just.
E
Maybe
it's
not
like
supported
by
the
most
like
common
tool
in
the
ecosystem
team,
so
like
it's
similar
with
like
the
markets
protocol,
it's
just
to
make
sure
that
my
current
market
client
implementation
can
talk
to
as
many
as
like
storage
provider
implementation
as
possible
in
the
market,
so
they
can
make
deals
with
each
each
other.
Get
data
like
stored.
C
Yeah,
it
makes
sense
so,
for
example,
the
way
I
see
it
is
like,
for
example,
if
we
wanna
say
okay
to
the
community
or
to
the
filecoin
users.
Okay,
we
are
having
for
eighty
percent
of
the
or
ninety
percent
of
the
nodes
on
lora,
so
we
are
proposing
an
frc
for
some
of
the
node
implementators
to
probably
change
to
for
restaurants
or
to
increase
network
diversity
with
something
good
through
this
frc
process.
If
I'm
understanding
it
currently.
C
E
A
Yeah
so,
for
example,
with
boost
lee,
if
you
know
we
were
to
go
boost,
is
already
being
integrated
into
venus
and
to
lotus
right,
for
example,
we
say
hey
this:
this
should
be
a
network
standard.
This
is
like
a
great
tool.
The
protocol
changes
are
really
useful.
Whatever
an
frc
is
implemented,
it's
accepted
whatever
this
is
considered
a
best
practice
one.
It's
not
a
consensus
issue,
there's
no
on-chain
change,
so
it
would
be
up
to
the
forest
team
to
like
incorporate
the
protocol
right
incorporate
boost
into
forest
on
your
own
timeline
right.
A
You
wouldn't
have
to
do
it
at
any
particular
point.
You
should
because
we're
saying
all
the
other
implementations
do-
and
this
is
something
that
benefits
from
having
more
people
bought
into
it.
But
if
you
wanted
to
decide
for
product
differentiation
purposes
or
anything
else
that
we
don't
want
boost,
we
actually
want
to
create
our
own
market
module
whatever.
In
this
context,
I
don't
think
that
would
make
a
lot
of
sense.
But,
hypothetically
speaking,
you
could
do
that
and
not
sort
of
adhere
to
what
the
frc
recommends.
C
A
A
And
aside
from
that,
I
think
I'm
not
sure
about
ask
v2,
but
also
the
index
or
advertisement
protocol
that
was
presented
a
few
by
hong
kong
a
few
weeks
ago.
That
will
also
be
an
frc
because
it's
you
know,
sort
of
a
an
indexer,
but
it's
not
something
that
everyone
has
to
incorporate
as
part
of
a
network
upgrade,
for
example,.
A
All
right,
well
thanks
everyone
for
joining
us
brenda,
thanks
for
coming
too
there's
another
meeting
this
afternoon
or
later
this
evening.
If,
if
anyone
else
would
like
to
join
that,
one
too
we'll
go
over
these
topics
again,
so
if
you
have
any
questions,
you're
welcome
to
come.
Otherwise,
I
think
this
is
a
really
productive
call
today.
So
thanks
everyone
for
your
participation,
your
thoughts.