►
From YouTube: Filecoin Core Devs #52
Description
Recording for:https://github.com/filecoin-project/tpm/issues/122
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
A
Welcome
this
is
filecoin
core
dev's
meeting
number
52.
today
is
Thursday
the
1st
of
December
and
the
final
four
devs
meeting
that
we
have
scheduled
for
2022..
A
Then
Alex
North
is
going
to
lead
us
into
a
conversation
about
some
changes,
he'd
like
to
see
to
FIP
acceptances
and
quantifying
gas
costs,
and,
last
but
not
least,
I'm
going
to
walk
us
through
some
of
the
updates
we've
been
discussing
for
a
few
months
about
core
devs.
This
is
mostly
just
a
reminder
about
some
documentation,
updates,
you're
going
to
see
and
want
to
very
quickly
introduce
some
small
tweaks
to
the
way
we
think
about
FIP
acceptance
to
help
support
us
as
we
prepare
for
some
upcoming
crypto
econ
fips.
B
Hi
I'm
gonna,
try
and
I'm
gonna
try
to
be
fast,
but
we
just
shipped
the
sharp
ob17
upgrade.
It's
live
on
the
network
congrats
everyone
again.
The
network
is
well
and
live
and
seems
to
be
working.
So
so
that's
great,
but
I
do
want
to
get
like.
B
You
know
a
line
on
what
only
18
is
going
to
be
about
what
the
timeline
looks
like
before
we
get
into
the
winter
or
like
summer
holiday
was
unplugged
and
also,
and
also
just
like
to
along
a
line
on
like
what's
the
next
steps,
so
I
think
from
the
past
couple
months.
Quad
apps
are
our
self-consensus
that
NBA
team
Falcon
NBA
team
upgrade
is
gonna,
be
mainly
about
launching
fevm
into
the
filecoin
network,
and
we
are
expecting
most
of
most
steps
to
be
fine
to
be
surrounded
by
febm.
B
So
that
being
said,
I
have
listed
a
list
of
the
steps
that,
if
the
fvm
team
is
about
to
create
and
I
believe,
if
you
actually
go
to
the
deck,
the
links
are
clickable.
So
you
can
take
a
look
in
that
and
the
only
non-fbm
fit
that
we
are
proposing
to
finalize
is
flip
47.
B
The
program
policy,
security
policy-
and
this
is
in
fact
already
accepted,
and
a
Lotus
and
the
Lotus
team
do
feel
like
we
have
the
bandwidth
to
actually
land
that
work
for
the
Falcon
Network,
and
that's
why
we
are
proposing
to
include
this
fit
overseeing
the
nbat
upgrade.
So
that's
the
scope,
if
you
want
to
add
more
fips
into
that
in
the
last
slide,
there's
a
link
to
the
TPM
Forum,
where
you
can
propose
anything
else
or
crack
me
if
I
got
six
from
so
on.
B
The
next
slide,
so
I
only
had
like
about
like
48.
I
started
to
work
on
this
like
about
like
48
hours
ago,
while
shipping
and
B17
so
so.
This
is
like
my
first
initial,
like
proposal
of
like
what
the
network
upgrade
tentative.
A
timeline
can
look
like.
Thank
you
for
the
fem
team,
especially
matching
step,
and
also
like
a
huge
two
and
also
casely
from
the
government
side,
to
help
me
and
to
have
this
initial
proposal
so
I
so
for
each
Network
upgrade.
There
are
two
basically
like
apparel
track.
B
The
first
one
is
be
engineering,
the
other
one
is
being
gardeners
So
currently
for
the
development
timeline,
the
pr
again,
the
projection
is
mainly
based
on
the
fem
and
Lotus
and
actor
engineering
resources
that
I
am
aware
of,
and
also
the
things
that
I
I
heard
from
people
that
want
to
deliver
so
like
feedbacks,
especially
from
the
Venus
team
and
the
forward
team
are
super.
Welcome
I
also
try
to
factory
a
that.
B
You
know
a
lot
of
people
are
taking
like
two
weeks
off
in
at
the
end
of
the
year
to
start
to
celebrate
and
also
next
year,
at
the
end
of
like
January
and
there's
a
long
holiday
in
Asia,
especially
China,
the
Chinese
New
Year,
that
our
community
will
be
less
available
to
support
Network
upgrades,
so
those
are
vaccine
already
so
for
the
development
other
than
the
code
freeze
for
each
implementation,
the
fem
team
is
going
to
launch
a
hyperspace
developer
test
net
on
December,
the
8th
as
a
part
of
pre-production
and
test
test
net.
B
There's
a
link
in
the
later
slide
that
you
can
read
more
about
it:
I'm
hoping
to
lock
down
on
the
only
18
FIB
scope
by
December,
the
9th
any
any
new
fips
that
needs
to
be
considered
because,
like
there's,
no
other
fips,
that's
already
accepted.
So
any
new
steps
started
from
now.
It's
going
to
be
a
new
draft
that
needs
to
go
through
the
whole
governance
process
and
also
need
engineering
resources
to
implement.
B
That's
why
I
I'm,
hoping
that
anything
that
folks,
the
community
want
us
to
consider
can
be
proposed
before
December.
The
9th
I
am
because,
like
the
beauty,
actor
is
a
code
base
that,
like
you
know,
shared
by
loaded,
all
the
implementers,
including
Lotus,
Venus
and
Forest
I,
do
want
to
have
a
shared
code,
free
Slackline
for
everyone,
so
that
implementations
can
play
accordingly
and
that
date,
right
now,
I'm
proposing
it
to
be
January.
B
The
6th
and
from
the
fem
team
I'm
told
that
the
vvm
audits
is
going
to
be
done.
Both
the
internal
and
external
objects
is
going
to
be
done
by
January,
the
16th
and,
having
everything
being
said,
I'm
hoping
after
January
the
6th.
All
the
implementation
team
can
start
integrate
with
the
actor
and
start
to
do
implementations
and
we
can
work
towards
a
calibration
upgrade
on
January
the
26th.
B
With
that
timeline
being
said,
we
probably
can
Target
a
midnight
upgrade
sometime
around
mid-February
on
the
governance
side,
a
case
may
and
why
I
worked
really
closely
on
that.
But
this
is
again
a
super
high
level
like
potential
timelines,
so
to
make
the
engineering
to
actually
be
able
to
deliver
all
the
steps
we
need
all
the
flip
stuff
to
be
open
and
latest
December,
the
13th
the
sooner
the
better
and
for
the
step
to
go
through
the
whole
governance
process.
B
This
doesn't
apply
to
your
emergency
system
or
crypto
e-comfit
December
20,
the
22nd,
yes
one
or
the
fifth
should
be
moved
to
last
call,
so
it
can
be
accepted
by
January
the
5th,
and
then
we
can
land
all
the
changes
into
the
building
actor
code
base.
I
see
a
couple
cancer
hands,
so
I'm
gonna
stop
first
mommy.
C
Yeah,
can
you
clarify
the
the
date
alignment?
What's
the
difference
between
December
9th,
which
is
scope
lockdown,
which
sounds
like
we've
decided?
What's
in
the
upgrade
as
a
community
versus
December
22nd,
all
nv18
fits
shall
move
to
last
call
by
this
date.
I
don't
understand
those
two.
B
December
the
9th
is
like
what
like.
Yes,
you
can
propose
any
saying
that
you
want
to
potentially
be
included
in
in
the
at,
and
the
December
the
22nd
is
whatever
is
getting
proposed,
has
go,
has
gone
through
the
governance
process
and
ready
to
move
to
last
call
and
ready
to
be
finalizing
to
the
network.
B
So
if
any,
if
there's
any
like
new
new
thing,
like
so
there's
a
say,
if
you
propose
a
fit
after
December,
the
9th,
even
you
go
through
the
governance
process
or
accepted
before
before,
like
let's
say
January,
the
5th
I,
don't
think
the
quarter
should
consider
to
include
assets
increditives
in
NBA
team,
but
a
later
Network
outbreak.
C
But
then
the
December
13th
date
of
all
Envy
18
fips
should
be
having
a
fib
draft
open.
As
of
that
date.
These
are
two
different
dates
that
are
trying
to
stay
the
same
thing,
which
is
have
your
drafts
open
for
potential
inclusion
in
nv18,
and
maybe
we
should
rename
that
then,
from
like
all
potential
considerations
for
NVA
team
are
open.
C
As
of
you
know
that
that
early
to
mid-December
time
frame
and
then
as
of
late
December
right
before
some
folks
go
out
on
holiday,
is
when
we
aim
to
try
and
hit
a
last
call
and
aim
to
finalize,
like
governance
on
scope,
correct.
B
Yes,
we
can.
We
can
consider
that
we
cannot
say
that,
but
yeah
Stephen.
D
Okay,
so
yeah
first
I
want
to
mention
that
the
Chinese
New
Year
starts
at
January
22nd
yeah.
It
usually
many
people
work
on
the
takeaways
and
at
that
time,
perhaps
about
two
weeks
so
yeah
here
they
calibration
upgrade
happened
at
26th.
It's
happens
during
the
holiday
I
wasn't
in
China.
D
I
would
suggest
that
this
could
move
one
week
ahead
or
you
just
put
it
into
yeah,
or
maybe
you
stated
earlier
for
a
week.
It
was
okay.
I
would
think.
B
That's
a
very
good
point
and
what's
definitely
a
thing
that
I
I
was
like
considering
before
proposing
this
day,
so
maybe
like
so
like
some
of
the
things
in
the
next
slide
may
tell
you
more
of
like
where
this
date
is
being
proposed,
but
also
like.
We
should
definitely
rely
on
whether
that's
the
right
date.
Oh
I,
don't
know
why
it's
cutting
off
some
of
the
words
so
but,
like
that's
fine,
so
next
slide.
B
I
in
this,
like
proposed
timeline,
I,
definitely
see
a
couple
like
challenges
and
risk
that
quarter
should
be
like
aware
of.
The
first
is
like
the
the
fifth
review,
and
the
sentence
timeline
is
like
super
super
tight.
Only
a
very
few
steps
that
you're
supposed
to
be
in
the
18
is
already
draft
draft
complete
at
the
moment
and,
as
you
all
can
see
that,
if
all
the
fifths
actually
got
opened
by
you
know
December
the
13th,
which
is
our
deadline.
B
Flip
editors
called
as
artists
really
have
to
be
super
super
active
on,
like
reviewing
the
flip
drops.
Associated
can
be
the
last
call
already
before
I
went
to
going
into
the
holidays
and
also
the
last
call
period
heavily
overlaps
with
the
end
of
the
year
holidays.
So
a
lot
of
editors
or
like
core
types
may
be
a
way
to
actually
review
the
flips
in
a
meaningful
way.
B
So
I
think
cordov
should
also
discuss
what
whether
we
should
extend
the
last
call
period
two
three
weeks,
so
people
can
come
back
and
review
the
fifths
and
also
like
that.
There
are
two
newly
introduced
test
net
from
the
fvm
team
is
called
olb
and
hyperspace.
We're
always
kind
enough
and
to
describe
over
those
two
Network
is
for
in
a
GitHub
discussion.
So
click
the
link
there.
B
You
will
be
able
to
see
that
so
back
to
so
those
two
are
supposed
to
be
heavily
developer,
focused
and
testing
a
lot
of
to
make
sure
and
hopefully
discover
a
bugs
by
the
developers
what
it
like,
maybe
like
bring
back
like
a
VM
so
back
to
your
question
as
Stephen.
So
so
what
we
are
thinking
here
is
like,
because,
like
majority
of
the
testing
for
this
upgrade
may
be
performed
by
hyperspace
on
the
hyperspace
testnet.
B
Maybe
we
can,
you
know,
shorten
the
calibration
upgrade
a
little
bit
and
maybe
it's
okay
to
overlap
with
the
Chinese
New
Year
a
little
bit
for
this
one.
But
again
that's
over
four,
like
feedback.
B
C
I'm,
responding
to
Caitlyn
who's.
The
comment
above,
which
was
I,
think
Steven's
suggestion
was:
it
would
be
optimal
for
the
calibration
community
of
SPS,
a
number
of
whom
are
in
China
and
would
be
celebrating
Chinese
New
Year.
If
the
network
upgrade
happened
prior
to
January
22nd
such
that
it
could
land
in
calibration
net
folks
could
do
testing,
they
wouldn't
lose
sync
and
data
and
all
of
those
things
in
calibration
Network
and
it
wouldn't
have
yeah.
C
Obviously
we
want
to
do
the
main
upgrade
as
soon
as
Chinese
New
Year's
ends,
and
everyone
comes
back,
and
so
we
don't
want
to
delay
any
further
into
the
future.
You
know
of
anything
we
want
to
pull
pull
forward
and
so
I
guess.
The
question
is:
is
there
a
hard
Gap
or
timeline
or
something
between
last
call
or
something
from
a
governance
perspective,
and
when
the
calibration
upgrade
happens.
B
Coverage
operate
dates,
yes,
many
dependent
on
first,
like
all
the
fifths
has
to
be
accepted
before
I
think
we
can
introduce
it
on
the
calibration
and
also
like
when
the
implementation
teams
are
ready
to
share.
You
know
a
super
close
by
cold
freeze
release
onto
the
collaboration
again,
we
don't
want
to
kill
the
calibration.
It's
the
only
pre-me-net
production
ready
Network.
B
So
so
far
the
Lotus
team
feel
like
we
can
ship
the
first
rc
like
a
week
and
a
half
I
believe
before
the
calibration
upgrade,
which
gives
the
Chinese
community
at
least
next
three
to
four
days
to
update,
upgrade
their
notes
before
we
move
into
the
moving
into
the
upgrade
again.
But
this
is
something
we
have
to
discuss
with
like
Venus
and
more,
are
you
sure.
E
Yeah
I
just
want
to
say
from
my
perspective,
this
timeline
is
extremely
tight
as
it
is,
and
I'm
worried
about
kind
of
a
known
work
that
that
might
emerge
that
we're
not
budgeting
enough
time
for
so
yeah
I
think
this
is
this
is
all
very
difficult
to
achieve,
and
I
would
push
back
against
attempts
to
move
dates
forward.
B
D
D
I
yeah
I
agree
that
we
need
to
have
all
the
FIP
yeah
and
accepted
next
month,
and
so
that
yeah
before
the
holiday,
and
so
that
and
all
the
team
know
that
what
we
need
to
achieve-
and
the
second
is
that,
okay,
my
understanding
is
that
yeah,
this
network,
an
upgrade,
is
for
used
to
enable
the
fevm
and-
and
we
could
have
yeah
Eastern
your
compliant
user
program,
both
actors
to
run
on
this
new
version
right
so
yeah.
D
We
need
to
keep
that
in
mind
and
so
that
I
would
expect
that
there
would
be
mainly
made
in
yeah
testing
yeah
to
to
your
fulfill
yeah.
D
You
know
calibration
or
in
the
hyperspace
and
statistic
yeah.
We
we
I'm,
not
sure,
if
that
we
we
just
keep
one
month
is
enough
for
this.
But
anyway
we
could
have
some
testing
on
hyperspace,
which
might
be
okay,
but
I,
agree
that
and
yeah
it's
kind
of
tight
there's
a
schedule.
Yes,
because
it's
not
like
before
right
yeah
before
we
only
have
the
yeah
consents
or
network
label
and
operator,
when
you
we
don't
need
to
run
18
yeah
user
actors
to
do
the
testing.
B
And
the
FEMA
has
been
you
know,
working
on
a
testing
plan
for
a
really
long
time
because,
like
we
have
other
topics
to
cover
in
this,
like
what
I've
called
I'm
wondering
now,
if,
if
you
can
share
your
like
detailed
test
plan,
what's
called
that
async
yeah.
F
A
few
a
few
notes
on
kind
of
like
Awareness,
on
key
headlines
here
and
then
I
can
elaborate
on
on
that
in
the
in
the
channel,
if
that,
if,
if
you
want
me
to
so,
this
is
the
first
Network
upgrade
where
the
where
the
environment
is
being
tested
continuously
through
wannabe
we've
been
having
just
in
the
last.
In
the
last
two
weeks,
we
had
over
2
000
contract
deployments
on
wallaby
as
a
result
of
hack
fabin.
F
So
that
is
something
that
is
already
changing
versus
you
know,
past
testing
flows
we
will
be
having
hybrid
space
as
well.
We
are
planning
a
hackathon
with
that
is,
will
be
announced
in
the
next
in
the
next
weeks
for
the
time
frame
of
January
to
the
beginning
of
February
three,
we
need
to
see
exactly
how
that
aligns
with
what
the
what
the
timeline
that
is
being
presented
here
to
understand
how
much
testing
density
and
testing
traffic
we're
going
to
see
on
hyperspace.
F
As
a
result
of
that,
another
thing
that
we've
been
working
on
is
we're
lining
up
developers
to
develop
automated
testing.
Suite
suits
for
that
basically
Port
contracts
from
other
networks
into
into
the
filecoin
network
and
exercise
create
test
vectors
that
have
been
extracted
from
other
networks
into
the
file
and
to
to
play
them
against
the
filecoin
network
and
febim
specifically.
So
we
do
expect
to
have
a
level
a
level
of
of
automatic
real
world
testing
there
as
well.
B
Testing
were
expected
to
be
our
wallabian
hyperspace
localization
is
more
for
developers
if
they
want.
They
can
join
that
as
well
and
like
hybridges,
more
for
storage,
rather
an
implementation
team
to
make
sure
the
migration
the
upgrade
can
go,
go
smooth,
go
smoothly.
The
last
thing
I'll
again
I
will
go
quick,
some
like
timeline
again,
we
have
a
very
tight
timeline.
That's
why
there
are
some
challenges
so
on
the
audits,
all
the
other.
The
other
audits
are
targeted
to
be
complete
by
January
the
60s.
B
While
we
we
expect
all
the
critical
bugs
will
be
discovered
in
the
very
beginning
of
the
Audits
and,
like
you
know,
working
towards,
like
the
end
of
that
we're
expecting
less
less
critical
bucks
being
reported.
However,
the
audience
are
completed
after
a
sentence.
So
so
we
are
all
like
the
beauty
actor
code
freeze.
So
from
the
governance
process,
we
are
wondering
if
any
refinement
needs
to
be
added
to
a
accepted
fib
does
that
is
that
allowed
I?
B
Don't
think
we
have
a
policy
for
that
at
the
moment,
and
so
the
government
is
TPM
probably
should
discuss
that
like
async
later
on
and
and
any
other.
You
know
that
any
same
fund
on
the
audits
may
impact
development
timeline
as
always,
and
the
crypto
another
huge
thing
is
like
the
community
and
core
devs
are
all
like
super.
You
know,
you
know
are
looking
forward
to
what
kind
of
the
gas
impact
that
a
user
deployed
contract
may
bring
to
the
Falcon
Network
again.
B
This
is
the
new
thing
for
the
network
and
crypto
econ
lab
has
been
doing
this
analysis
in
the
past
couple
weeks
and
they're
currently
aimed
to
deliver
the
analysis
and
the
report
and
suggested
next
steps
by
December
the
18th,
which
is
right
before
a
lot
of
the
core
Engineers
Accord
apps
to
to
be
off
to
the
to
the
holidays.
So
a
couple
risk
here
is
like
you,
the
code.
B
Apps
do
have
enough
time
to
maintain
very
early,
like
reviewed
analysis
before
confirming
the
gas
model
fit
can
be
accepted,
can
be
in
last
call
and
what's
the
decision
making
process
on
whether
solution
has
to
be
landed
in
the
network
before
we
even
ship
at
the
end,
you
know
upgrade.
So
those
are
the
two
challenges
that
collapse
should
absolutely
like,
discuss,
maybe
offline
and
so
I
think.
That's
it
again.
B
If
you
have
any
questions,
if
you
have
any
concerns,
let's,
let's
research
in
the
code,
app
Channel
or
even
in
a
public
TPM
Forum.
Thank
you.
A
Thank
you
Jennifer
all
right.
Let's,
we
have
kind
of
a
tight
schedule
today,
so
let's
pass
it
over
to
Alex
who
is
going
to
keep
us
on
train
talking
about
governance,
discussing
Fifth
implementations
and
acceptance,
sequencing.
G
G
I
assume
everyone
has
had
a
chance
to
say
this
in
the
fifth
discussion
forum
or
the
quarters
chat,
but
there's
a
a
attention
that
that's
became
quite
apparent
with
45
between
how
much
we
do
implementation
prior
to
writing
a
FIP
so
that
we
can
write
the
specification
you're,
knowing
you're
informed
by
knowing
how
at
least
one
implementation
would
work
versus
the
process
of
writing
a
and
having
a
governance
proceed.
G
First,
to
give
you
know
to
set
the
spec
for
the
implementation
and
to
give
influencers
the
you
know
the
the
Mandate,
the
the
confidence
that,
when
they
commit
months
of
work
to
doing
the
implementation,
that's
going
to
be
worth
something
because
the
network
has
indicated
they
want
this
change.
G
One
yeah.
This
particularly
came
up
because
45
had
impacts
on
the
gas
costs
of
publishing
deals,
and
but
these
these
gas
costs
concretely
were
not
known
until
after
FIP
acceptance,
but
had
we
known
them
beforehand,
perhaps
we
would
have
done
things
slightly
differently.
You
know
they're
larger
than
we
would
have
liked.
Perhaps
we
would
have
spent
more.
H
G
Time
on
optimization,
possibly
that
would
have
performed
part
of
the
spec,
not
just
an
implementation
concern.
G
However,
you
know
the
more
that
we
require
implementations
to
be
complete
and
you
know
complete
has
a
needs
definition.
The
longer
you
know,
processes
processes
will
take.
We
still
need
to
leave.
You
know
plenty
of
room
for
the
discussion.
G
It's
there's
no
point
having
a
I
can
see
sort
of
some
of
this
happening
already
with
the
with
the
fem
fips,
but
this
year
the
discussion
and
Community
feedback
around
if
it
should
not
be
a
meal
like
for
Melanie,
not
a
show,
there
should
be
actual
room
for
people
to
object.
Propose
alternatives
have
a
real
discussion
that
the
FIP
is
not.
You
know
not
just
a
formality.
That's
actually
the
process
for
Community
consultation.
G
So
you
know
these
timelines
will
all
increase.
If
we
the
more
implementation
work
we
require
before.
If
we
can
reach
that
that
stage
which
will
slow
down
velocity
for
everything
next
slide,
I
think
please.
G
So
I
want
to
open
up
a
discussion
about
you
know:
what
should
we
do
here?
What
other
trade-offs
are
there
if
we
require
more
or
less
implementation
work,
we've
done
many
fips,
so
40
something
fips
in
the
past
generally
without
requiring
implementation
ahead
of
FIP
acceptance
hasn't
been
that
bad
I
mean
yeah.
A
question
is
like:
is
this
really
a
problem
that
needs
solving
it's
possible?
G
The
answer
is,
is
no,
but
how
can
we
generally
give
give
you
the
people
doing
the
work,
confidence
that
they're
doing
meaningful
work,
while
also
keeping
keeping
standards
quite
high
and
and
in
supporting
your
meaningful
Community
involvement,
Community
governance,
Community
feedback
on
the
changes
that
were
that
we're
making
suddenly
stop
there
and
open
to
discussion.
G
E
E
I
I
think
the
experience
with
45
kind
of
indicates
that
this
is
obviously
unfortunate,
because
it
does
mean
that
people
have
people
working
on
potentially
month-long
projects
have
to
at
least
slightly
be
open
to
the
possibility
that
that
it
doesn't
go
anywhere
or
doesn't
actually
go
live
in
the
network,
but
yeah.
E
There
are
just
a
whole
host
of
changes
that
it's
pretty
hard
to
to
make
a
governance
decision
on
just
an
acceptance
decision
on
without
knowing
what
the
implementation
looks
like
gas
is
a
good
example
of
that
and
that's
kind
of
what
what
happened
with
45,
but
I
do
think
there
are
others,
so
yeah,
I
I,
my
my
nudge
is
that
pretty
slightly
have
to
bite
the
bullet
and
Implement
them
things
while
being
open
to
the
possibility
that
they're
not
going
to
to
go
live.
G
Yeah
thanks
a
good
I
like
I,
have
a
lot
of
sympathy
for
that
point
of
view,
I
wonder
how
consistently
so,
as
you
see
some
plus
ones,
in
the
chat
as
well.
We
need
to
think
through
the
implications
of
that,
for
example,
if
we
took
that
seriously,
then
the
immediate
implications
for
the
fem
are
like
you
know.
G
Well,
you
know
finish:
implementation
write
some
fips
and
have
some
real
Community
engagement
and
you
know
maybe
we
can
ship
it
per
quarter
later,
because
if
anything
changes
that
you
know
it's
is
this
is
this:
is
this
Fit
review
a
show,
or
is
this
actually
a
place
for
consultation
and
real
design
alternatives
to
be
to
be
considered?
You
know,
I,
think,
there's
a
tough
trade-off
there
it's
hard
to
hard
to
apply
the
right
right,
the
FIP
first
and
then
it's
like
you
know.
G
Yes,
no
binary
decision
or
or
is
there
room
for
yeah
real
consultation?
It's
a
tricky
trade-off,
Caitlyn.
A
A
A
Think
one
of
the
things
that
we
could
potentially
do-
and
we
have
long
needed-
is
better
post
implementation,
monitoring
and
mitigation,
also
for
fips,
necessary
or
declaring
design
standards
and
potential
impact
scenarios
that
we
expect
to
see
so
that
we
can
more
easily
make
changes
even
very,
very
slight
ones
if
fips
aren't
operating
on
the
network,
the
way
that
we
anticipate
them
being,
but
ultimately,
I
think
what
Jennifer
first
said
about
there
being
an
additional
stage
here
for
testing
and
Design
This
also
gets
back
to
what
we're
discussing
earlier
related
to
febm.
A
It
seems
to
be
the
preference
of
the
group
and
how
quickly
we're
moving
that.
The
answer
is
yes
to
that,
but
we
still
need
to
have
some
kind
of
public
transparency
around
it.
So
as
long
as
again,
speed
is
sort
of
our
operating
value
for
how
we
make
design
decisions
for
this
process.
I
think
it's
going
to
be
really
tough
for
us
to
get
to
this
place,
but
it
might
be
a
longer
term
goal
for
us
if
that
makes
sense,.
C
Yeah
I
think
you
know,
if
anything
to
me,
it
seems
very
healthy
to
have
advice
around
speed,
because
these
sorts
of
protocols
and
processes
tend
to
get
longer
and
more
complicated,
and
eventually
your
development
slows
to
a
halt
or
or
becomes
becomes.
You
know
yearly
releases
that
sort
of
thing
which
is
like
just
not
not
at
the
speed
of
if
Improvement,
that
we
definitely
need
to
see
this
year.
C
We
have
a
lot
of
really
exciting
things
that
are
coming
and
something
that
adds,
for
example,
quarter
long
overhead,
post
implementation
to
discussion
and
ship
seems
like
a
huge
waste
for
the
entire
network,
but
I
do
completely
agree
with
what
a
use
was
saying
of
like
there
is
a
back
and
forth
between
you
know.
It
is
not
feasible
to
write
a
spec
without
doing
any
sort
of
implementation
and
actually
have
a
clearer
understanding
of.
C
We
didn't
have
a
clear
understanding
of
the
pros
and
cons
of
the
FIP
until
like
the
last
minute,
and-
and
you
know
that's
bad-
we
should
we
should
avoid
that,
but
I
think
it
means
that
there
is
a
a
period
of
like
we
like
the
thing
that
this
is
unlocking
and
we
generally
agree
with
the
high
level
way
it's
being
implemented.
C
However,
it's
in
an
ongoing
like
iteration
period,
And,
there's
like
a
you
know,
does
does
it
land
in
the
next
upgrade
or
does
it
need
to
keep
being
within
that
iteration
period?
This?
This
fifth
has
like
General
broad
support,
and
you
know
it
gets
targeted
towards
a
release
and
gets
finalized,
hopefully,
at
the
time
frame
where
it's
not.
C
It's
like
close
to
having
landed
the
the
bounds
like
you
know,
been
live
in
a
test
net
people
have
been
able
to
like
experiment
with
it
like
that,
that
sort
of
thing
and
I
think
fbm's
actually
a
really
positive
example
in
that
area
because,
like
you
know,
fips
were
open
early
for
that
overall
alignment
and
community
support
and
experiment.
You
know
feedback
loop
from
a
design
perspective.
C
You
know.
So
it's
been
a
long
process,
it's
been
live,
you
know
iterating
upon
but
like
characteristics
visible
in
test
net
since
like
July,
and
so
you
know
there
is
this
overlap
and
iteration
back
and
forth
between,
like
the
spec
itself
and
the
implementation
and
the
performance
characteristics
and
the
implications
having
all
been
looked
at
by
many
different
groups,
and
that
we
should
aim
to
create
that
overlap
in
the
interest
of
making
sure
that
we're
able
to
actually
ship
these
improvements
quickly
and
not
introduce
a
lot
of
buffer
time.
G
Foreign
yeah
thanks
I,
can
see
a
theme,
maybe
emerging
here
and
from
some
chat
comments
that
it
may
be
possible.
I,
don't
know
I,
don't
know
whether
or
not
it
comes
as
a
fifth
stage,
but
there's
some
distinction
between
a
an
acceptance
of
the
goals
and
acceptance
of
the
policy
decision,
that's
being
made
by
by
a
fair
lack
of
acceptance
that
this
is
where
we
went
ahead,
separated
from
the
sort
of
final
implementation.
We
understand
all
the
impacts
like
real
acceptance
that
this
this
is
the
spec
that
we
should
implement.
C
C
Don't
know
like
sure
you
can
do
that
in
20
000
different
ways,
but
like
there's
the
fifth
in
significant
technical
detail
and
then
there's
it's
been
implemented
in
a
live,
Network
and
tested
the
bejesus
out
of
it
and
it's
like
code
and
bug
fix
and
like
audit
complete,
all
of
which
introduce
like
minor
changes
but
maybe
aren't
affecting
the
overall
big
picture
design.
G
Yeah
I
mean
from
my
point
of
viewfm,
is
a
good
example
of
like
the
good
acceptance
of
the
policy
of
like
here's,
where
we
want
to
go
from
where
I'm
sitting
like
the
fibs
are
lacking
a
lot
of
technical
detail
right
now.
A
lot
of
a
lot
of
extremely
relevant
things
are
not
specified
in
the
existing
fibs
and
we're
waiting
for
like
four
more
fips
to
come,
which
I
expect
will
have
those,
but
but
we're
like
talk
about
the
same
things
matter
of
degree.
Degree
here,
I
think
role.
F
Yeah
I
think
sorry,
I
think
fem-m1
was
likely
a
little
bit
more
of
an
example
of
that
than
M2
I.
Think
M2
had
significant
uncertainty
that
we
still
we've
been
mapping
out
and
therefore
risk
like
I
would
have
personally
liked
to
open
a
prefab.
Several
prefabs,
maybe
two
or
three
weeks
ago,
when
like
most
of
the
big
decisions,
would
have
were
already
solidified
and
we
just
like
had
to
refine
and
and
iterate
upon
those.
Of
course,
we
were
heavily
bandwidth
constrained,
and
this
like
it
was
physically
physically
impossible
to
do
that.
F
However,
I
do
think
there
is
something,
so
there
is
already
a
pre-acceptance
stage
and
sorry
a
pre
prefab
stage,
and
that
is
a
fib
discussion
and
we've
been
using
FIB
discussions
for
this
to
gather
signal
in
terms
of
motivations
in
terms
of
goals
in
terms
of
overall
appetite
for
this
particular
change.
So
my
question
to
the
group
is:
how
does
introducing
an
Pro
introducing
a
a
pre-acceptance
stage,
but
I
want
to
make
sure
that
we
reconcile
this?
With
what
effect
does
question
will
ultimately
turn
out
to
be
I?
F
Think
there's
a
lot
of
value
enforcing
these
initial
sketches
to
take
the
form
of
a
spec,
a
spree,
semi-normative,
spec
and
and
like
aspect
that
we
can
iterate
and
iterate
on
with
a
audit
trail
with
commits
and
PRS
and
so
on,
so
that
the
changes
like
you
can't
do
this
in
a
fifth
discussion
right.
You
can't
point
out
specific
lines
that
you're,
not
that
you
do
not
agree
with
in
a
usable
manner,
so
I
think
there
is.
F
G
Yeah
thanks
roll
I
I
do
think
you're
on
something
there,
both
that
yeah
I
think
it
needs
to
take,
take
the
form
of
like
a
you,
know,
design
proposal
or
actual
act,
you're,
proposing
concrete
design
decision
and
a
review
of
those
decisions
and
I.
Think
fifth
discussions
sometimes
come.
It
sort
of
depends,
there's
a
there's,
a
range
of
things
that
people
can
post
in
different
discussions
on
the
way
to
a
FIP.
G
Some
of
them
are
more
or
less
normative,
but
one
well
I
think
one
concrete
difference
would
be
an
actual
decision.
Being
you
know
for
discussions,
you
know,
can
be
crickets
and
that's
often
okay,
but
sort
of
an
active
decision
and
active
acknowledgment
by
probably
by
the
core,
devs
and
like
yes,
this
is
a
direction
we
want
to
go.
We
expect
this
FIB
to
be
approved.
If,
if
it
doesn't,
you
know,
surprise
us.
F
Yeah
just
want
to
try
the
second
point
there
and
I
think
this
might
be
related
to
fit
47
the
sorry
45,
the
execution
gas
I
said
it
in
the
chat
execution.
Gas
is
very
unforgiving
and
I
think
there
is
a
place
here
where
core
depths
as
they
Implement
and
they
find
that
gas
is
an
impediment.
There
should
also
somehow
be
committed
to
refactoring
the
underlying
logic,
data
structures
and
so
on
for
for
up
for
better
performance
execution
gases
measuring,
ultimately
the
number
of
instructions.
F
So
if
that
and
of
course
we
need
better
tooling
to
actually
profile
where
the
cost
is
coming
from
and
I
think
this
might
be
the
big
blocker
so
in
in
allowing
us
to
take
the
right
decisions
to
optimize
the
right
things
so
that
this
actually
getting
to
a
point
where
you
implement
the
thing
only
to
realize
that
execution,
gas
is
just
slamming
the
the
the
the
the
the
like
the
whole.
F
The
whole
proposal
is
a
really
bad
place
to
be,
and
there
is
currently
we
are
not
able
to
actually
solve
for
that
at
all,
because
we
lack
the
ability
to
profile
and
I
think
that
would
be
the
next
step
to
unblock
to.
Actually,
yes,
we
need
this
pre-commit
stage,
but
also,
like
you
know,
minimize
the
amount
of
the
amount
of
times
that
we're
actually
going
to
see
ourselves
in
this
situation.
G
A
We
have
a
quick
ad
hoc
updates
from
Stefan
and
also
I
want
to
walk
through
some
of
the
changes
for
core
Dev.
So
if
you
want
to
take
five
or
so
more
minutes,
we
could
afford
it,
but
otherwise
we
can
move
on
okay,
awesome.
Thank.
G
A
Oh
I
think
Stefan
we'll
give
you
time
at
the
very
end
of.
G
The
end
great
yeah,
so
I
I,
don't
expect
if
there's
no
more
hands,
I
I
won't
take
any
any
particularly
more
time.
There
seems
to
be
a
thing
coming
out
here
that,
like
maybe
we
do
need
some.
There
is
some
kind
of
notion
to
be
formalized
here
and
we
can
probably
take
discussion
about
how
to
do
that.
Offline.
A
Yeah
I
think
it's
clear
that
the
theme
of
the
day
really
is
governance
and
and
not
to
be
too
localized
to
the
fip36
experience.
But
I.
Think
one
of
the
big
takeaways
is
that
there
is
a
significant
increase
in
momentum
around
some
of
the
the
nuanced
components
of
the
way
we're
governing
right
now
and
we've
been
discussing
it
internally
with
at
the
foundation.
A
But
we
may
actually
need
additional
meetings,
unfortunately,
specifically
for
discussing
and
proposing
governance,
quite
like
the
way
file,
Queen
plus
manages
now
with
their
governance
calls
so
that
core
devs
does
not
continue
to
get
overtaken
by
these
conversations,
which
all
by
important,
are
not
necessarily
something
we're
going
to
always
have
time
for
if
we
stand
a
monthly
schedule.
A
But
today
what
I
wanted
to
do
is
quickly
run
through
the
changes
that
we've
been
discussing
for
several
months
to
core
devs.
These
are
not
really
changes
so
much
as
just
documentation
updates
for
the
past
couple
of
months.
These
have
really
been
this
sort
of
sort
of
unclodified
standards
that
we've
leaned
on,
but
again
with
more
demand,
more
people
joining
this
meeting
and
with
continued
questions
of.
Is
this
a
core
dev's
question?
Should
this
go
elsewhere?
A
Should
I
figure
this
out
within
my
team
wanted
to
use
really
clear
standards
to
help
bring
us
all
in
alignment
and
also
align
with
filecoin
is
doing
with
the
trajectory
that
other
protocols
have
taken
too.
So
very
simply,
what
is
a
cordov
core
devs
as
a
group
is
a
technical
governing
body
providing
us
with
the
capacity
to
make
decisions
right
now.
A
lot
of
our
work
is
relatively
open-ended
right.
We
have
FIP
editors
who
also
oftentimes
service
core
devs.
A
We
have
core
devs
who
will
go
in
and
review
fips
participate
in
the
governance
forums.
All
of
this
is
fantastic,
but
having
sort
of
a
very
clear
understanding
of
what
this
group
is
being
assembled
to
do
is
important,
so
that
as
more
needs
arise
in
the
future
or
even
in
the
present
again,
as
we
see
more
attention
and
demand
on
our
governing
capacities,
we
have
a
group
that
we
can
use
as
sort
of
a
benchmark
or
a
jumping
off
point
okay.
A
A
I
would
really
like
to
distinguish
going
forward
between
a
core
Dev
and
an
observer,
the
only
real
difference
being
that
core
devs
take
on
and
opt-in
to
more
responsibilities
related
to
again
reviewing
fips
participating
in
more
meetings.
They
want
to
be
here
and
they
want
to
sort
of
do
those
extra
activities
that
are
really
necessary
for
sort
of
a
strong
body
versus
observers.
Who
are
people
who
want
to
join
the
meeting?
Maybe
a
few
meetings.
A
They
have
some
relevant
knowledge
or
expertise
for
topics
that
are
being
discussed
now,
but
perhaps
they
do
not
necessarily
participate
in
reviewing
fix,
participating
in
governance,
conversations,
long
term
Etc.
They
have
local
knowledge
and
they
love
to
contribute
that
and
know
what's
happening
within
the
group,
but
they
don't
necessarily
want
to
take
on
that
added
responsibility.
A
Next
slide,
please
all
right.
So
some
really
quick
FAQs
that
I'm,
hoping
are
are
very
helpful,
is
who
can
become
a
cordov
should
be
anyone,
but
not
necessarily
needs
to
be
everyone,
we've
long
sort
of
relied
on
sort
of
the
General
open
source
sense
of
meritocracy.
A
If
someone
asks
to
be
a
core
Dev,
we
can
ask
the
group,
and
as
long
as
no
one
disagrees
or
has
a
substantial
reason
to
they're
welcome
to
join
us,
we
do
not
want
to
have
really
hard
and
fast
or
quota
based
requirements
for
what
you
have
to
do
to
be
a
core
Dev.
We
want
this
to
be
something
that
you
you
choose
to
do
that
you
opt
into
you
want
to
participate
in
this
group
and
as
we
develop
those
Norms
of
what
is
good,
behavior
and
good
participation.
A
We
do
want
it
to
be
flexible,
but
we'll
say
that
it
may
not
be
necessary
for
an
entire
team
to
join
this
meeting.
There
should
be
better
ways
of
reporting
out
information.
These
meetings
are
recorded,
there
are
public
meeting
notes
and
we
are
continuing
to
move
towards
refinement
so
that
these
meetings
are
just
more
efficient
and
we
know
who
the
list
of
core
devs
actually
is
when
it
comes
time
to
actually
making
harder
and
faster
decisions
or
consensus
found
needs
for
the
team.
A
If
you
have
sort
of
an
administrative
or
a
planning
question
or
want
to
raise
a
security
concern
that
can
go
in
the
core
devs
Channel,
which
is
a
private
Channel,
how
our
core
devs
governed,
hopefully
by
themselves,
this
group
should
be
self-governed.
No
one
person
get
to
decide
how
this
group
ought
to
run
or
what
its
rules
ought
to
be,
and
even
what
I'm
presenting
here
says
not
necessarily
my
primary
reflection
of
how
we
should
operate
but
again
is
taken
from
months
and
months
of
conversation
around
this
okay
and
last.
A
How
do
they
make
decisions
through
group
consensus,
and
this
is
really
a
norm
and
a
behavior
that
I'm
hoping
that
we
can
build
upon
in
the
coming
weeks
and
months
next
slide?
Please
all
right!
Let
me
quickly
check
the
chat,
because
there
are
lots
and
lots
of
comments.
I've
seen.
A
Jennifer
quickly
asked
is
core
Dev
the
same
as
folks
in
Phil
cordov
Channel.
It
should
be
I'll
talk
a
little
bit
on
my
final
slide,
real
quick
about
some
of
again
those
documentary
documentation,
changes
that
you'll
see,
but
we'd
also
like
to
have
a
public
attendance
list
as
part
of
the
core
devs
repo.
Just
so
everyone
can
very
clearly
see
who
is
a
cordov.
A
We
will
also
keep
track
of
observers,
which
are
those
people
who
just
joined
meetings,
kind
of
on
an
ad
hoc
or
one-off
basis,
as
part
of
meeting
notes
going
forward
and
as
a
jumping
off
point,
we're
just
going
to
use
the
cordoves
list
that
was
used
for
the
FIB
36
still
pull
process.
I'd,
also
like
to
note
that
this
is
not
supposed
to
be
like
an
exclusionary
or
very
difficult
thing
if
you're
not
on
the
list,
and
you
feel
you
should
be
just.
A
Let
me
know
if
you're
on
the
list-
and
you
don't
really
want
to
participate,
we
can
remove
you.
If
you
get
removed,
you
can
be
brought
back
in
the
future.
No
one
will
ever
be
kicked
out
without
warning
or
notice.
We
want
this
to
be
an
expansive
group
that
relies
on
everyone's
expertise.
It's
just
that
we
want
to
also
have
some
some
benchmarks
and
some
some
rules
so
folks
know
what's
what
and
that
there's
less
uncertainty
going
forward.
A
Okay,
all
right
so,
but
we
can
address
these
and
I'm
sure
we'll
folks
will
have
comments
and
Reflections,
but
again
talking
about
court
of
responsibilities.
This
is
where
I
want
to
sort
of
shift
the
conversation
away
from
the
expectations
we've
discussed
previously
and
for
months
into
a
new
tweak
to
the
fix
process
dependent
upon
core
devs,
so
in
this
bottom
piece
in
rare
cases,
casting
votes
and
contributing
to
collective
decision
making
for
emergency
and
crypto
economic
fix.
This
is
a
need
that
really
arose
US
during
the
36
process
and
I.
A
Think
if
Stefan
is
going
to
suggest
in
just
a
couple
of
minutes,
it
may
be
a
need
very
imminently
to
handle
some
other
crypto
economic
changes
that
folks
within
the
network
are
hoping
to
make.
If
you
could
skip
to
the
next
slide,
please
foreign.
A
Sort
of
way
to
sort
of
set
the
stage
we
are
a
young
protocol
undergoing
rapid
technical
development
when
it
comes
to
governance,
there's
lots
and
lots
of
Standards
or
best
practices
in
different
communities
we
could
rely
upon,
but
as
long
as
the
emphasis
again
tends
to
be
a
bias
towards
speed,
we
want
to
make
sure
that
things
are
publicly
accountable
and
rules-based
to
the
best
of
their
ability
without
being
really
high,
friction,
okay
and
so
the
way
that
we
tend
to
approach.
A
This
is
for
fips
that
are
overwhelmingly
technical
right,
which
is
a
very
ambiguous
concept,
but
are
those
which
tend
to
provide
sort
of
a
net
operational
or
interoperability
increase?
They
change
sort
of
the
function
of
the
network
by
adding
capabilities
to
it.
Etc
fevm
is
a
great
example
right.
It's
improving
something
that
is
in
that
positive
for
this
community,
even
if
there
may
be
resource
costs
associated
with
it.
These
are
the
kinds
of
things
that
benefit
from
the
soft
consensus
that
we
usually
go
through.
It's
very,
very
easy.
A
Community
members
are
still
fully
welcome
to
participate.
Everything
is
publicly
documented
and
open,
but
it
does
provide
flexibility
for
us
to
make
big
and
complicated
technical
changes
to
the
network
without
necessarily
needing
to
vote,
without
necessarily
needing
to
convene
or
reach
very
difficult
consensus
around
things
that
many
people
still
are
unable
to
really
fully
participate
in
because
of
their
complexity.
A
The
point,
though,
is
that
there
are
rare
fips
on
this
bottom
piece
that
do
not
follow
this
pattern.
This
is
what
we
saw
before
36
and
we
need
to
begin
thinking
of
making
slight
tweaks
to
our
process
so
that
we
can
sort
of
absorb
the
shock
from
them.
Okay,
so
we
may
need
to
make
very
complicated,
crypto
economic
changes.
There
may
be
a
situation
in
the
future
where
some
security
vulnerability
is
discovered
and
we
need
to
land
a
fit
immediately
right.
A
These
are
things
that
again
are
very
rare,
but
we
should
have
procedures
for
them
in
advance
so
that
we
can
absorb
them
when
they
happen.
So
next
slide,
please
like
the
okay.
A
So
this
is
the
current
process
for
fips,
with
sort
of
a
highlight
in
this
middle
section,
for
what
core
devs
are
currently
asked
to
do.
Okay,
most
governance
happens
during
these
beginning
phases,
and
this
is
where
we
ask
community
members
to
participate.
We
want
them
to
lean
into
the
idea
and
the
drafting
stages
and
when
we
get
to
last
call,
we
want
sort
of
it
to
be
very
easy
to
understand
sort
of
the
concept
of
what
is
being
proposed.
A
Very
few
community
members
tend
to
weigh
in
here
it
tends
to
mostly
be
driven
by
football
there's
still
and
as
was
raised
during
this
meeting.
We
want
to
create
ways
to
better
manage
and
Implement
some
greater
Nuance
during
these
latter
phases
as
well,
so
that
we
can
be
responsive
to
testing
requirements.
Testing
needs,
spec
changes
Etc
and
what
we're
actually
shipping
onto
the
network
is,
is
high
quality
and
trusted.
Okay
next
slide.
A
What
I
propose
changing
is
that
for
certain
thefts,
which
we
consider
crypto
economic
fips
like
if
you
could
click
once
more,
we
introduce
a
slight
tweak,
which
is
here,
and
it
is
instead
of
going
only
through
a
soft
consensus
process
that
we
asked
for
devs
to
publicly
consider
whether
to
accept
or
reject
the
FIP.
A
This
is
not
necessarily
to
change
the
process.
Everything
else
is
the
same:
Community
feedback
could
still
be
a
huge
driver,
as
we
saw
during
FIB
36.
Many
cordoves
themselves
felt
very
conflicted
about
how
to
vote
on
the
5th
because
of
what
they
saw
as
feedback
from
Storage
providers.
A
We
want
that
to
still
be
a
driver,
but
with
these
things,
which
can
be
very
existentially
challenging
to
certain
stakeholder
groups
or
community
members,
there
is
still
going
to
be
a
need
to
make
a
decision
for
the
help
of
the
overall
Network,
and
it's
why
I
would
recommend
much
is
the
case
with
other
protocols
as
well
that
we
begin
to
rely
on
poor
devs
to
help
us
make
those
decisions.
Okay,
similarly,
next
slide
same
thing
for
an
emergency
fit.
A
The
only
thing
difference
is
that
these
are
the
kinds
of
scenarios
where
we
may
need
to
make
a
decision
in
days
or
even
hours
instead
of
months,
and
hopefully
the
idea
here
is:
we've
never
used
something
like
this,
but
if
we
ever
need
to
in
the
future,
we
have
a
procedure
in
place
that
we
know
what
to
do.
It's
not
to
say
that
these
procedures
cannot
change.
A
It
is
not
to
say
that
in
only
five
stages
they
are
perfect
or
the
Nuance
is
fully
understood,
but,
as
is
typical,
I
will
put
together
a
whole
documentation,
a
whole
set
of
documentation
for
this,
which
will
be
available
this
afternoon.
You
can
take
a
look
at
it
and,
for
the
sake
of
time,
I'd
encourage
async
discussion
around
this.
A
It's
again,
a
very
small
change,
I
think
it's
something
that
we've
been
discussing
and
that
has
actually
been
asked
for
in
different
ways,
but
I
think
it
is
important
that
we
do
consider
and
make
a
decision
very
quickly
again
because
of
some
other
crypto
economic
tips
that
we
know
are
coming
down
the
pipeline,
which
Stefan
and
also
which
Stefan
has
joined
us
to
talk
about
briefly
I,
don't
want
to
cut
off
this
conversation
and
I'm
very
happy
to
continue
to
have
it,
but
there
are
five
minutes
left
and
Stefan
I.
A
Think
that's
a
good
segue
for
you
to
introduce
what
you'd
like
to
talk
about.
H
Would
you
mind
giving
Porter
the
ability
to
share
his
screen
while
I'm
studying
the
stage
here,
but
first
we,
as
you
mentioned,
we
want
to
move
faster,
but
at
the
same
time
get
of
course
feedback
from
the
community
and
so
as
an
outcome
of
the
36
and
sort
of
the
current
challenges
that
we've
seen
in
the
market.
H
We
have
like
started
the
discussion
on
GitHub
that
Porter
will
share
in
a
second
here
where
we
sort
of
collect
collectively
with
the
storage
provider
working
groups,
because
we
have
weekly
storage
provider
working
groups
with
I
think
six
regions
now
right,
so
the
US
Europe,
Asia,
Singapore,
Korea
and
so
on,
where
we
are
collectively
working
on
what
are
all
the
programs
to
help
create
a
better
or
a
more
stable
and
robust
Network
and
demonstrate
utility
and
deliver
credibility
and
stability
overall
to
attract
more
customers
to
our
Network.
H
So
there's
a
couple
of
problems
that
we're
focusing
in
on
one
is
sort
of
like
at
core,
like
in
a
lot
of
discussions
that
we
have
in
Porter
can
give
some
more
details.
H
There's
a
lot
of
discussion
on
the
outcome
of
fit36
there's
a
lot
of
SPS
that
actually
want
to
continue
with
a
slight
variation
of
it
that
would
incentivize
long-term
participation
right
and
so
there's
a
couple
of
things
we
we
have
to
go
do
here,
so
our
goal
of
this
discussion
is
to
really
share
the
feedback
that
we're
collecting
through
these
storage
provider
working
groups
and
then
also
the
outcome
that
we
want
to
propose
as
a
basically
a
fit
that
comes
out
of
this
and
so
Porter.
H
Maybe
you
can
share
a
little
bit
of
the
details,
because
this
was
just
posted
two
days
ago,
but
we'd
like
to
ask
everyone
to
participate
and
also
track
this,
because
this
is
something
we
would
love
to.
We
would
love
to
see
a
new
FIB
as
an
outcome
of
this
conversation
based
on
the
feedback
we're
getting
from
the
SPs
and
obviously
our
hope
is
to
get
this
into
version
18
if
possible.
I
know
this
is
a
really
tight
schedule.
H
So
we
wanted
to
make
sure
that
everyone's
aware
of
of
what
we're
doing
here
supporter,
maybe
you
can
walk
a
little
bit
through
the
process
that
you've
been
following
and
I.
I
Just
want
to
lead
off
with
you
know.
Obviously,
usability
is
a
primary
concern
to
storage
providers,
and
this
really
isn't
a
discussion
on
overall
usability.
It's
about
some
of
the
other
things
that
we
can
do
to
set
us
up
for
a
lot
longer
term
success,
longer
term
participation-
and
you
know
this
was
you
know
again.
You
want
to
level
set
on
what
the
problems
are,
as
you
go
into
any
discussion,
especially
specially
with
storage
providers.
I
But
you
know,
as
we
have
these
discussions
within
the
working
groups,
there
is
a
consensus
around
what
it
what
they
would
like
to
see
within
the
market
and
that
really
goes
to
longer
term
participation,
which
translates
into
what
the
deal
duration
is
and
why
we're
raising
this
discussion
now
is
that
we
like
we
have
an
opportunity
to
increase
the
deodoration
from
18
months
to
five
years
five
years,
which
is
probably
it
is
universally,
the
most
accepted
term
by
the
storage
provider
working
group
and
that's
based
on
you
know
a
lot
of
client
conversations
that
they're
having
that
you
know,
obviously
we're
not
as
tuned
into
so
we're
relying
on
their
feedback,
and
you
know
that's
why
we
want
to
level
set
with
the
community
present
problems
understand
what
the
priorities
are
and
where
we
want
to
evolve.
I
This
to
is
just
saying:
hey.
This
is
what's
coming
out
of
the
storage
provider
working
group.
There
is
a
chance
for
us
to
include
this
in
the
next
Network
upgrade
if
there
is
universal
acceptance,
but
overall
storage
providers
are
all
about.
You
know
what
are
the
small
quick
wins
that
we
can
do
to
move
fast,
that
you
know,
aren't
aren't
so
controversial.
I
Obviously,
if
you
go
into
longer
term
deals
that
will
inevitably
bring
up
the
question
of
the
multiplier,
but
you
know
we're
taking
this
one
at
a
time,
and
this
is
something
you
know.
How
do
you
start
this
conversation
to
make
sure
that
you
know
the
community
is
seeing
the
prioritization
similar
to
the
storage
provider
working
group.
H
Thank
you
pointer.
So,
in
the
next
couple
of
days
you
will
see
more
comment,
comments
posted
specifically,
as
we
said,
the
outcomes
of
the
conversations
we're
having
in
these
working
groups.
So
we
can
share
it,
not
just
with
us
space
but
also
token
holders
and
other
ecosystem
partners
that
are
interested
in
the
ongoing
discussions.
But
this
time
it's
basically
built
you
know
with
dsps
in
the
room
and
it's
sort
of
driven
by
them
as
well.
H
So
thank
you
for
giving
us
the
time
we'll
we'll
share
more
updates
and
we'll
follow
up
in
the
next
call.
A
Great
thanks
also
for
jumping
in
last
minute.
It's
the
common
Porter.
Your
timing
is
perfect
for
right
at
the
top
of
the
hour
as
usual,
a
packed
meeting
and
lots
of
follow-up
lucky
we'll
meet
with
everyone
who's
presented
today
to
make
sure
he
has
all
of
their
materials
and
share
with
cordevs
again,
as
usual,
continue
to
have
async
discussions.
A
C
C
We
didn't
actually
get
time
to
converse
about
it,
let's
bring
it
up
in
our
next
core
devs
meeting
and
actually
like
I,
if
we're
talking
about
hard
consensus,
hard
consensus
with
55
people
in
a
way
that
limits
group
core
Dev
participation
like
to
me,
it's
just
it's
just
misaligned,
like
the
way
that
we
have
designed
cordovs
is
not
a
voting
body.
It's
not
a
like.
That's
not
how
it
works.
The
way
that
we
have
been
using
core
devs
in
the
past
is
generally
implementation
teams
across
the
board.
We're
like
hey,
yep.
C
We
plan
to
implement
this
thing.
This
seems
like
it's
good
for
the
network
super
rough
and
so
I
I
disagree
with
the
points
of
like
this
has
already
been
a
hard
like
majority
rules
governing
body
like
I.
Don't
think
that's
the
case
like
I,
don't
I,
don't
think
that's
how
core
devs
has
been
designed,
and
so,
if
we
want
to
create
that
body
which
I
can
understand
why
we
have
the
needs
around
it,
it
like
we
need
to
create
that
as
a
separate
thing
from
what
core
devs
is.
C
Maybe
it
is
choosing
a
subset
of
the
core
devs
Community
to
Step
Up
into
that
role
such
that
they
can
make
fast
emergency
decisions
or
high
context
decisions
on
XYZ
FIP
in
a
fast
like
voting,
validator
based
sort
of
way,
but
I,
don't
think
that
is
one
a
limit
on
the
the
participation
in
forums
like
this
core
devs
Community
call
or
our
core
Dev
slot
Channel,
where
we
coordinate
on
network
upgrades
where
people
you
know
across
the
Venus
team
and
the
forest
team
and
the
Lotus
team
need
High
context
within
those
areas
want
to
be
heavily
participating
in
the
design
implementation
iteration
on
that.
C
But
that
is
different
from
a
majority
rules.
You
know
great
okay,
one
of
those
teams
becomes
like
10
times
larger.
You
know
like
it's
subject
to
various
different
issues
along
those
lines.
I
think
we
need
to
refine
that
corner
and
probably
just
also
make
space
for
future
future
discussion
upon
that,
because
I
think
there's
a
lot
of
there's
people
I,
don't
feel
like
it's
it's
solidified
yet.
A
Great
so
as
mentioned,
yet
these
conversations
are
not
just
to
happen
here.
They
will
continue,
as
they
usually
do.
I
I
think
Alex
is
right,
that
what
we're
getting
really
hung
up
on
is
a
misunderstanding
of
labels
and
terms,
but
we
want
to
make
sure
that
what
we
have
is
actually
like
a
really
solid
organizational
structure,
that's
leading
to
better
outcomes
and
providing
more
capacity
for
us
to
move
forward
with
more
complex
tips.
A
J
Once
more
bit,
I
don't
fully
agree
that
it's
just
a
labeling
thing
where,
like
I,
think
like
it's,
it's
okay
to
have
votes
and
governing
bodies,
but
I
feel
like
we
should
take
a
step
back
and
Define
what
the
principles
and
criteria
and
then
I
assure
everyone
above
let's
like
go
back
to
the
drawing
board
and
really
like
craft
sustainable
governance
structure.
Instead
of
saying,
oh
all,
right
sure,
it's
a
label
we're
going
to
shuffle
the
definition
of
the
label,
but
we
haven't
really
gotten
down
to
what
constituted
that
label.
A
There's
we
we
have
worked
on
this
pretty
extensively
and
there
is
documentation
around
this,
which
is
also
already
Linked
In.
The
presentation
as
well
yeah.
J
I
understand
I
mean
we
can
discuss
more,
but
I
just
feel
like.
We
haven't
really
gotten
down
all
from
the
first
principal
reason
why
Southern
groups
should
be
represented
and
then
can
we
like
Define
that
super
super
clearly
and
and
also
not
just
the
definition,
but
also
the
composition
and
the?
Why.
J
C
Are
we
going
to
put
this
on
the
agenda
for
the
next
one,
because
I
just
think
I
think
it's
an
important
area
and
I
agree
that
I
don't
think
it's
a
labeling?
It's
not
a
label,
it's
issue,
it's
a
responsibilities
and,
like
you
know,
it's
adding
new
governance
expectations.
I
think
the
same
things
that
roll
is
flogging
in
the
chat.
It's
like
wait,
I've
been
a
cordov
for
the
past
two
years,
but
suddenly
there's
this
new
expectation
responsibility.
C
That
is
not
what
I
signed
up
for
not
what
was
expected
of
me
as
a
core
Dev
like
how
does
that?
How
does
that
work
and
should
I
still
be
a
courtev
in
that
Future
model?
And
so
like
that?
That's
it
there's
a
feeling
of
an
expansion
of
responsibility
there
and
it's
not
just
a
labeling
thing.
It's
a
additional
responsibilities,
piece
that
that
I
I
think
should
be
broken
out
from
the
court
of
label.