►
From YouTube: Filecoin Core Devs #58
Description
Recording for: https://github.com/filecoin-project/core-devs/issues/141
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
Hello,
everyone
and
welcome
this
is
filecoin
core
devs
number
58
today
is
Thursday
June
1st
2023.
lucky
is
out
of
office
today,
so
I
am
going
to
help
facilitate
this
meeting
for
all
of
us
on
the
agenda.
We
have
two
proposal
discussions,
one
on
pledge
shortfalls
led
by
Tom
Mellon
and
the
other
one
on
a
direct
filecoin
plus
proposal
by
Alex
North,
and
it
sounds
like
we
will
finish
this
meeting
today
by
having
a
discussion
brought
up
by
Stephen
Lee
about
set
milestones
for
protocol
change
and
growth.
A
All
right
so
with
that
I
will
jump
right
in
I
saw
Tom
was
on
the
line
Tom,
you
want
to
jump
in.
B
Hey
Kevin
thanks
very
much
yeah,
so
I
will
give
a
quick
introduction
to
the
pledge
shortfall
ideas.
So
this
is
something
that
there's
something
we've
been
working
on
together
with
crypto
net
and
Alex
North
for
the
past
month
or
two
moving
on
to
different
scenarios
and
trying
to
design
this
and
really.
This
is
something
that
came
up
about
a
year
ago
initially
and
then
it
initially
surfaced
in
some
work
from
Alex,
and
then
it
came
up
recently
about
three
or
four
months
ago
from
some
storage
providers.
B
I
think
it
was
dltx
and
some
other
groups
we're
saying
hey.
A
really
big
problem
is
we've
got
we've
got
this
pipeline,
we've
got
the
equipment,
we've
got
everything
in
place,
but
the
thing
that
we
don't
have
is
the
the
tokens.
So
there's
really
a
shortage
of
tokens.
That's
constraining
our
our
ability
to
to
grow
and
onboard
more
storage.
B
No,
we
know
there's
not
a
shortage
of
tokens
in
general,
but
there
can
be
a
shortage
of
tokens
until
the
The
Lending
markets
are
more
mature.
So
this
is
a
problem
we
wanted
to
look
at
so
the
way
that
we've
taken
to
considering
this
problem
is
by
enabling
a
shortfall
in
the
initial
pledge
a
month
to
be
taken
at
the
the
protocol
level
so
that
that's
the
general
General
nature
of
the
problem.
B
We
want
to
alleviate
this
constraint
and
talking
shortage.
That's
that's
talking
about
Network
growth
and
there's
also
a
supply
and
fashion
element
as
well,
so
Supply
inflation
can
damage
storage
provider
returns
and
also
Network
growth
and
potentially,
depending
on
the
specific
parameterization.
The
shortfall
proposals
can
help
with
this.
Also,
so
that's
that's
the
nature
problem
in
terms
of
the
the
principles
that
we're
trying
to
adhere
to
by
proposing
these
potential
Solutions
are
that
whenever
an
SP
takes
a
short
form
that
should
not
be
preferred
over
externally
at
least
tokens.
B
So
the
the
you
should
not
compete
or
damage
external
markets
and
we
want
their
ecosystem
to
thrive.
In
that
way.
Another
principle
that
we're
trying
to
think
about
whenever
we're
coming
up
with
these
proposals
are
that
we
want
to
minimize
risk
to
the
network,
so
that
could
be
in
terms
of
Supply
shocks
through
any
crypto
economic
changes.
It
could
also
be
in
terms
of
what
it
applies
for
terminations
if
you're
changing
the
initial
pledge-
and
it
also
applies
to
consensus,
which
initial
pledges
is
a
big
part
of.
B
B
Some
more
features
are
that
an
SP
will
need
to
put
up
most
of
the
Pledge,
so
you
have
to
put
up
at
least
two-thirds
of
the
Pledge.
So
it's
not
like
you
can
take
a
shortfall
of
90
around
two-thirds,
as
the
the
number
we've
seen
to
have
settled
on
is
reasonable,
but
this
is,
you
know,
ongoing
and
subjective
parameterization
as
well.
Another
point
to
make
is
that
the
the
the
sector
with
a
shortfall
effectively
gets
the
full
qap.
B
It
gets
the
full
qap
because
the
short
Force
should
be
repaid,
so
it's
it's
either
repaid
to
the
miners
balance
to
make
up
the
shortfall
or
it's
hard
so
that
so
these
are
the
two
different
variants.
But
what
they
have
in
common
is
that
the
sector
still
gets
the
full
qap.
So
you
take
a
show
form
on
the
initial
upfront
and
lines
or
you
get
the
full
QEP.
So
you
get
the
full
rewards,
but
you
should
end
up
eventually
paying
the
full
pledge.
B
And,
and
so
as
I
touched
on
before,
in
exchange
for
being
able
to
take
a
short
vote
to
be
able
to
onboard
more,
the
the
storage
provider
should
pay
some
fee
or
burn
some
amount
of
their
tokens.
And
again
the
precise
numbers
here
are
subject
to
parameterization,
but
we
want
to
respect
these
principles
that
you
should
not
compete
or
damage
external
lending
markets.
Okay,
I
think
we
can
go
to
the
next
slide.
Please.
B
Okay,
so
a
few
more
points
quite
high
level
stuff.
What
does
success?
Look
like
success
looks
like
greater
than
other
otherwise
expected
onboarding
if
onboarding
stays
the
same.
That,
wouldn't
that
would
be
a
signal
that
the
proposal
hasn't
worked.
What
we
also
expect
is
to
say
similar
or
greater
amounts
of
locking,
and
what
we
also
expect
to
see
is
an
increased
amount
of
burning.
If
people
are
making
use
of
insurance
for
proposal,
there
will
be
a
fee
to
do
so,
which
is
burnt.
B
So
that
is
one
outcome
which,
from
our
protocol
perspective
level,
is
a
good
thing.
What
does
failure?
Look
like
failure,
looks
like
no
optic.
Is
this
bad?
Is
it
relatively
bad
in
the
sense
that
we've
spent
time
and
effort
thinking
about
it?
But
it's
not
the
worst
thing.
What
would
be
worse
would
be
if
there
was
extensive
uptake
of
proposal,
so
many
storage
providers
are
taking
a
short
form,
but
there
is
no
growth
in
onboarding,
so
instead
there's
less
token
demand
and
but
not
necessarily
yeah.
B
So
so
the
shortfall
is
expressed
through
less
token
demand,
rather
than
in
terms
of
increased
growth
through
lifting
that
constraint.
That
would
that
would
be
a
poor
outcome,
but
that's
something
specifically
that
we
are
designing
trying
to
design
for.
B
Okay,
so
in
terms
of
some
basic
FAQs
will
miners
be
able
to
earn
the
same
or
more
pledge
for
Less
reward?
No,
they
shouldn't
be
able
to
earn
more.
The
fee
is
less.
B
The
initial
pledge
is
less
upfront,
but
eventually
that
should
be
made
up
and
there
should
be
some
fees,
so
you
should
not
be
able
to
earn
more,
but
there's
some
subtlety
here
and
it
depends
on
how
you
think
about
it,
whether
you
think
about
earning
more
in
aggregate
terms
or
per
unit
per
unit
of
pledge
so
per
unit
of
pledge,
you
shouldn't
be
able
to
earn
more,
but
if
you're
a
storage
provider
who
is
constrained
by
expanding
their
operations
because
they're
Limited
in
tokens,
but
otherwise
not
constrained,
then
you
should
be
able
to
to
benefit
from
the
benefit
from
this
and
increase
your
aggregate
returns.
B
So
there's
a
little
bit
of
subtlety
to
that.
But
that's
that's
the
answer.
So
will
the
shortfall
be
able
to
complete
external
lending
markets
again?
This
depends
on
the
parameterization,
but
this
is
something
that
we
are
specifically
trying
to
design
for
and
have
at
the
front
of
our
minds
and
would
not
want
to
to
suggest
a
parameterization
where
this
can
happen.
Okay,
so
in
terms
of
next
steps,
the
next
steps
are
really
to
understand.
Is
there
an
appetite
for
this?
B
What
do
you
guys
think
is
this
something
that's
worth
doing,
so
we
we've
been
working
on
it
for
some
time
and
there
is
a
few
more
steps
to
do
to
analyze
the
precise
effect
on
terminations
and
their
own
consensus
and
to
potentially
implement
it.
So
it's
like
a
non-trivial
amount
of
researchers
and
developers
time
to
do
this,
but
not
very
substantial,
but
it,
but
it
is,
it
is,
does
take
time.
B
So
that's
something
to
consider
whether
or
not
this
the
potential
benefit
from
The
Proposal
are
ways
this,
so
we
think
it
can
be
good
if
people
still
believe
there
is
a
problem
took
it
shortage
that
is
constraining,
Network
growth,
which
a
lot
of
people
were
talking
about
some
months
ago.
If
people
still
believe
this
exists,
then
this
can
be
a
good
solution,
but
really
what
we
do
in
terms
of
next
steps
depends
on
what
people
think.
C
D
C
I
would
have
to
say,
for
example,
if
this
is
a
butane
functionality,
it's
directly
tied
to
the
manufacturer.
You
know
the
power
actor.
That
means
you
know
to
start
fighter
using
any
external
Landing
market
today.
That
means
they
have
to
give
up
their
owner
keys
or
beneficiarities
and
such
sites
which
adding
the
complexity
to
the
ux.
So
that
will
be
you
know
from
a
ux
perspective,
it's
also
going
to
be
a
competition
with
regard
to
the
external
Landing
markets,
yeah.
B
B
So
you
have
to
carefully
balance
other
factors
against
that
to
make
sure
that
the
fees
are
sufficient
and
that
they
grow
sufficiently
with
onboarding,
so
so
that
this
scenario
doesn't
occur
where
these
things
are
directly
competing
with
with
each
other
I
mean
we
thought
about
this.
A
lot
and
we
think
it
should
be
possible
should
create
a
proposal
with
the
correct
parameterization
where
external
lending
markets
are
preferred.
Then
the
next
thing
is
buying,
and
then
the
next
thing
is
buying,
partly
and
taking
apart
shortfall.
B
So
so
despite
yes,
the
the
user
exchange
might
be
different
and
you
might
have
these
preferred
features.
Preferable
features
such
as
increased
safety
or
ease
of
use.
It
should
be
still
possible
not
to
to
compete
directly
with
external
lending
modes.
E
Yeah,
okay,
I
have
some
comments
actually
on
this
yeah
in
the
particular
discuss,
Slade
and
I
want
to
repeat
something
here:
one
is
that
I
think
we
need
to
be
really
careful
about
this
feature.
Implementation
is
because
that
I
think
this
is
actually
yeah
how
the
lead
work
as
a
vendor
yeah
to
the
the
story,
providers
and
so
yeah.
It
will
be
the
yeah
competitor
for
the
defect
project
or
any
other,
mainly
Market,
actually
yeah.
E
This
is
one
thing,
and
the
second
thing
is
that
I
didn't
say
made
in
supports
from
the
storage
providers
of
this
yeah
in
the
discussing
thread,
but
I
say
yeah.
There
are
some
commands
there,
so
I
will.
I
will
suggest
that
we
have
more
investigation
and,
as
her
mentioned,
that
I
understand
the
community
demands
to
yeah.
Perhaps
you
can
get
a
vote.
You
know
from
Storage
providers
yeah,
because
this
is
really
for
the
story.
Providers
right
so
just
message
using
here
and
also
I.
E
Think
because
this
is
try
trying
to
solve
the
problem
of
the
shortage
of
the
of
token,
but
really
I
didn't
say
that
so
we
have
actually
yeah
more
than
450
million
circulating
yeah
token
and
available
there,
but
we
don't
have
why
yeah
the
Lindy
Market
is
not
so
smooth
here
to
support
this
yeah
to
support
growth
in
as
in
is
there
are
some
other
sense
behind
so
yeah,
for
example,
yeah.
E
It's
not
so
easy
to
yeah
for
the
gender
and
brought
your
browser
to
get
yeah
to
to
to.
E
You're
satisfying
both
sides
and
also
yeah,
because
the
protocol
is
complicated
and
also
there's
risk-
is
unpredictable
to
handle
many
things
in
many
complicated
Sensations.
So
I
would
think
that
we
perhaps
we
need
to
directly
to
solve
a
zero
problem
and
over
there
yeah.
E
This
might
be
OT
near
here.
So
overall
I
need
I.
Think,
and
yes,
this
perhaps
could
help
on
this,
but
I
don't
I'm
not
so
sure
about
this.
So
I
really
suggest
that
we
have
a
most
yeah,
more
investigation
and
more
discussing
or
to
get
the
feedback
from
the
the
affordable
community.
B
Yeah
yeah
I
mean
I
I
totally
agree,
so
we
want
to
see
I
mean
it's
really
useful
to
hear
the
feedback
here,
but
also
to
get
more
engagement
on
the
GitHub
threads.
B
Whether
people
think
this
is
worth
something
something
worth
pursuing
in
in
terms
of
just
like
repeating
in
terms
of
like
competing
external
lending
markets,
the
the
the
shortfall
proposals
should
be
structured
specifically
such
that
they
become
more
punitive
as
shortfall
increases
and
the
fees
should
be
set
in
such
a
way
that
it
should
not
or
compare
to
more
directly
compete
with
lending
markets
in
general
and
that's
like
a
precondition
and
if
it
turns
on
for
some
reason,
then
we're
wrong
in
our
analysis
and
that
we
can't
achieve
that.
B
Then
I
don't
think
we
would
want
to
pursue
it
and
I
totally
appreciate
what
you're
saying
also
that
it
does
bring
complexity,
and
this
is
something
that
we
have
to
consider
together.
B
I
noticed
Jennifer's
point
that
it
may
prevent
liquid
fill
contributing
back
into
the
network.
It's
difficult
to
say:
I
mean
one
thing:
is
that
one
one?
The
proposals
are
partially
designed
to
improve
Supply
and
increase
burning
long
term,
which
can
have
an
effect
of
actually
helping
external
lenders
at
this
kind
of
mutualistic
effect
there,
which
may
actually
help
improve
liquid
feel
from
lenders.
F
Yeah
I'm
sensitive
to
time,
I'm
sure
we
want
to
be
moving
on
to
other
things,
but
I'm
very
much
agree
that,
like
you
know
realistically,
if
there's
not
positive
sentiment
and
adoption
or
like
desire
from
the
SP
community
in
terms
of
like
yes,
this
would
very
much
help
us
grow
faster,
especially
because
D5
Solutions
are
still
getting
off
the
ground.
F
At
least
you
know,
my
understanding
is
that
a
number
of
like
a
lot
of
the
the
liquid
fill
that
is
available
for
potential
you
know,
usage
is
collateral,
is
mostly
held
on
exchanges
and
other,
like
you
know,
OTC
desks,
and
so
it's
not
available
for
easy
access
to
storage
providers
without
access
to
those
D5
Solutions.
Those
D5
Solutions
are
scaling
and
scaling
quickly.
F
But
if
say
that,
we're
on
track
to
store
another
exabyte
of
of
data
in
the
next
year,
like
that,
would
would
point
to
a
significant
Demand
on
collateral
that
those
D5
Solutions
might
not
be
able
to
meet
by
themselves,
and
so
it's
like
you
know
these
two
things
together
might
help
increase,
increase
adoption,
but
I
very
much
agree
like
look
if
it's.
If,
if
we
don't
see
strong
signal
that
this
is
going
to
be
adopted
and
utilized
by
the
community,
we
shouldn't
put
the
time
and
effort
into
it.
F
We
have
many
other
important
things
that
we
need
to
go.
Work
on
that
are
are
core
to
improving
the
network
and
to
to
Steven's
Point
like
if,
if
this,
if
these
proposals
don't
get
positive,
like
traction
of
storage
providers
being
like
yes,
this
would
really
help
me
grow.
This
would
help
me
meet
my
clients
demands
in
terms
of
onboarding
their
data
smoothly.
Then
I
think
we'll
move
on
to
other
Solutions
and
keep
this
on
a
in
the
back
burner.
F
I
think
the
other
flag,
obviously,
is
that,
like
from
an
implementation
timeline
we're
a
little
bit,
you
know,
Defy
is
scaling
right.
Now
and
I
don't
know
if
people
can
predict
super
well,
I
think
a
lot
of
people
are
like
well,
hopefully
that
just
solves
all
the
demand
there
and
we
can't
really
tell
whether
it
will
in
one
to
two
to
three
months
from
now,
but
we
might
find
this
being
a
a
little
bit
more
of
a
burning
issue
down
the
line
if
D5
doesn't
scale
as
fast
as
we
hope
it
does.
F
A
Thanks
Molly
and
I
think
with
that
that'll
be
our
final
comment
on
this
proposal.
Again,
there's
two
links
here
and
we'll
also
include
them
in
all
the
meeting
notes.
Afterwards,
let's
jump
over
into
the
next
conversation
topic,
which
is
the
direct
file
claim,
plus
proposal
from
Alex
North.
G
Thank
you
great,
so
this
is
so
I'm
going
to
sort
of
work
backwards
from
a
slightly
larger
thing
to
a
smaller,
more
immediate
thing.
These
are
all
these
are
all
slightly
too
raw
to
have
been
fifth
discussions
yet,
but
I
expect
them
to
be
up
there
soon.
G
G
That's
a
significant
part
of
the
cost
of
of
doing
stuff
on
filecon
review,
onboarding
data,
and
we
have
a
situation
here
that
there's
a
good
opportunity
for
us
to
remove
to
reduce
these
gas
costs
quite
significantly
for
the
dominant
use
case
or,
for
you
know,
for
a
very
large
use
case
of
a
deal
that
is
fill
plus
and
does
not
involve
an
additional
payment
from
the
client
to
the
SP.
G
We
end
up
doing
some
duplicate
accounting.
The
verified
registry
actor
on
chain
records
all
of
the
important
things
about
a
field
plus
allocation
and
claim
it
does.
This
to
you
know,
have
on-chain
records
that
justify
the
the
10x
qap
associated
with
it.
G
G
But
it
is
adding
a
bunch
of
costs
and
so
very
rough
guesstimates.
You
know,
half
the
cost
of
deal
publishing
is
associated
with
the
the
market.
Actor
record
in
in
the
field
plus
case
and
the
other
half
is,
is
your
essential
things
related
to
the
full
plus
allocation
itself
and
other
deal
activation.
G
So
you
can
see
on
the
right
here.
The
verified
registry
already
has
on
chain
all
of
the
essential
information
about
about
Phil
plus
deals.
So
this
information.
We
want
this
information
to
be
on
chain
it's
on
chain
in
the
verified
registry,
for
many
reasons,
but
this
is
all
directly
observable.
So
if
we,
if
we
you
direct
for
plus,
is
going
to
propose
that
we
skip
making
the
deal
in
the
market
actor
and
the
information
we
want
is
still
going
to
be
observable
next
slide.
Please.
G
All
right,
so
this
is
a
proposal
for
yeah
we're
calling
direct,
full
plus,
which
is
process
a
simplification
of
the
process
by
which
a
fill
plus
you
know
simple
field
plus
deal
with
no
client
payments
can
be
made,
which
ends
up
being
cheaper
and
simpler
in
its
own
sense.
Although
of
course
it's
a
change
from
what
currently
happens,
and
so
it
does
involve
work
to
get
there.
G
And
so
here,
a
client
as
a
verified
client
that
has
data
cap
can
make
a
field
plus
allocation
directly
with
the
the
verified
registry.
Currently,
today,
the
the
built-in
Market
actor
actors
and
acts
as
an
intermediary
for
them
and
allocates
data
on
their
data
cap
on
their
behalf.
G
But
that's
extra
work,
that's
doing
that's
sort
of
not
necessary,
and
then
we
can
also
the
minor
actor.
The
minor
actor
already
directly
claims
full
plus.
You
know:
qap
went
out
when
onboarding
a
sector,
and
currently
you
have
checks
the
the
data
flow
issue
where
it
has
to
look
up
the
the
verified
allocation
ID
from
the
market
actor.
But
the
SP
knows
this
ID
they
could
provide.
They
could
provide
it
directly
when
they're
on
voting
a
sector
and
so
in
this
flow.
G
So
you
see
the
two
flow
flow
diagrams
here
there
is
no
Market
actor
in
the
right
hand,
flow
diagram
data
cap
gets
allocated
directly
by
the
client
and
the
SP
claims
it
directly
when
on
boarding
a
sector,
and
so
there
is
about
half
the
sort
of
account
keeping
work
that
needs
to
be
done.
In
the
second
case,
it
has
a
limitation
that
has
no
ability
to
process
a
payment.
G
So
there's
no
ability
the
verified
registry
doesn't
do
doesn't
do
sort
of
client
payments,
but
when
that
payment
was
going
to
be
zero
anyway,
this
is
much
more
direct
way
of
getting
what
we
want
next
slide,
please,
okay!
So
there's
one
thing:
we
have
to
do
first,
this
diagram
on
the
right
here
you
might.
This
has
changed
slightly
from
how
I
presented
it.
G
Last
week,
I
I
broke
a
dependency
added
a
bit
more
detail
in,
but
I
presented
this
sort
of
dependency
chart
last
week
and
I've
highlighted
the
areas
that
I'm
talking
about
right
now.
G
G
It
functions
very
similar
to
the
sector
termination
penalty,
but
is
attached
to
the
the
fact
that
there's
non-zero
data
in
the
sector
instead,
and
so
if
we
want
to
maintain
this
behavior
of
having
a
sort
of
mandatory
data
Assurance
penalty
that
the
network
is
enforcing,
then
we
need
to
move
that
so
that
it's
still
going
to
happen
for
these
direct
four
plus
deals,
even
if
they
don't
touch
the
market
actor
and
so
I
have
a
proposal.
That's
sketched
out.
G
There's
a
link
on
the
slide
here
and
I'm,
once
I
figure
out
some
details
about
yeah.
Well,
once
forget
a
couple
of
details:
I
publish
this
as
a
fifth
discussion,
but
in
brief,
we
can
move
this
penalty
from
the
Market
act
where
it
is
now
into
the
minor
actor,
so
the
minor
actor
can
enforce
it
for
all
data.
That
goes
into
sectors
whether
or
not
it
uses
the
built-in
storage
Market
and
then
I
I'm,
advocating
for
that.
G
We
change
this
also
to
parameterize
it
by
by
qap,
instead
of
robot
power,
which
will
equalize
the
penalty
in
terms
of
block
reward
between
Phil
plus
and
non-food
plus
deals,
but
that's
optional.
We
can
discuss
that
and
and
then
and
then
so
after
after
this
dead
termination
penalty,
which
is
a
very
simple
change
in
generally,
we're
then
free
to
do
the
you
know
there
is
a
more
work
required
to
make
this
director
for
plus
path
possible.
G
It
involves
changes
to
the
the
API
that
miners
use
when
the
onboard
sectors,
because
they
now
need
to
need
to
provide
their
full
plus
allocation
IDs
when
onboarding.
You
know,
the
full
plus
allocation
ID
takes
the
place
of
the
deal
ID,
but
we
could
also
yeah
anyway.
So
so
this
is
a
period
because
it's
a
fairly
small
prerequisite
but
I
want
to.
G
You
know
put
it
up
first
for
discussion
on
its
own
merits
and
but
then
we're
on
we're,
then
we're
on
a
path
to
this
direct4
plus
thing,
which
will
be
much
cheaper,
onboarding
and
field
plus-
and
it's
also
a
nice
step
to
on
to
do
a
much
more
scalable
version
of
this
as
well,
where
we
can
get
the
costs
to
go
sub
linear
in
the
data
size.
G
Okay,
I'll
stop
chatting
a
question
from
Molly
I'll
read
it
out
if
it's
okay,
relying
on
the
full
plus
registry,
would
this
require
new
apis
or
tooling
to
make
sure
we'd
retain
visibility
on
how
much
verified
data
XSP
stored
or
which
data
XSP
is
stored?
Yes,
to
the
extent
that
tooling
right
now
looks
at
the
built-in
Market
actor
state.
For
that
information
it
would
need
to
change
to
the
verified
registry
that
changed
coming
today.
G
If
I
was
writing
that
tooling
today,
I
think
the
verified
registry
is
the
right
place
to
look
at
for
that
data,
but
I
understand
that
you
know
things
that
were
you're
tooling.
That's
you
know
more
than
a
year
old
is
probably
looking
at
the
market
actor
the
verified
red.
She
has
an
API
that
smart
contracts
can
call
I,
think
all
the
relevant
methods
are
exported,
but
if
they're
not
I,
don't
wouldn't
see
any
barrier
to
exporting
the
relevant
methods
so
that
smart
contracts
can
access
this
as
well.
G
So,
yes,
I
think
there
is
some
change
for
some
tooling,
but
so
yes,
there
is
some
change
to
talk
all
right.
Let
me
open
for
more
questions.
G
No
I
don't
think
I
can,
because
I
would
also
be
quite
happy
with
that
path.
To
an
extent.
This
some
of
these
proposals
are
based
on
on
making
less
change
than
that.
To
achieve
these
outcomes,
removing
the
I
mean
so
the
built-in
Market
actually
has
to
stay
there
as
a
market,
lots
of
being
relied
on
for
deals
that
are
not
just
Phil
plus
and
so
on.
G
That
I
think
maybe
what
you're
searching
is
like
just
cutting
the
built-in
Market
actor
out
straight
away
and
making
it
non-mandatory
I
would
be
quite
happy
with
that.
Generally.
If
we
want
to
have
this
mandatory
deal
Assurance
enforced
by
the
network,
then
we've
got
to
put
it
somewhere
and
that's
what
this
data
termination
penalty
is
doing,
but
I
think
it's
a
good
question
whether
the
network
should
really
enforce
that
across
all
data
everywhere
or
whether
we
should
leave
that
up
to
Smart
contracts.
G
So
I
welcome
the
discussion
about
whether
we
should
just
drop
that
which
is
a
simpler
change.
H
I
was
just
thinking
like
which
this
is
going
to
complete
two
very
different
worlds
for
verified,
Deals,
non-verified
Deals,
and
that
adds
another
layer
of
complexity.
So,
if
there's
like
another
path
to
get
to,
the
similar
names
should
be
considered.
F
Thank
you,
someone
a
response
to
that,
but
feel
free
to
go.
First.
F
Yeah
just
trying
to
to
think
about
it
like
thinking
about
like
the
product
experience
of
using
Falcon
and
I
I.
Think
all
all
clients
of
Falcon
will
be
concerned
if
they
hear
about
other
clients,
data
like
falling
off
the
network
and
the
network
feeling
unreliable
for
repairing
and
renewing
that
data.
We're
trying
to
think
about.
F
You
know:
building
a
robust
foundation
for
humanities
information
like
that
having
a
economic
feedback
loop
within
the
protocol
that
tries
to
default
for
robust
data
storage
because,
like
work,
is
done
to
put
the
data
on
the
network,
and
so
it
really
sucks,
for
you
know
really
everyone
involved,
but
especially
for
the
client.
F
If
they've
like
relied
on
this
data
storage
mechanism
to
hold
like
the
key
copies
of
their
data,
and
now
they
no
longer
have
the
ability
to
repair
that
data
like
they're,
more
harmed,
and
so
it
it
definitely
a
a
sector
that
has
lots
of
deals
or
data
in
it.
F
I
think
needs
to
have
a
higher
termination
fee
or
penalty
then
been
one
that
is
just
empty
CC
data
waiting
for
client
deals
now,
where
that
happens
or
how
that
happens,
I
think
is
a
little
bit
more
TBD,
but
but
that's
like
I'm
just
trying
to
think
about
it
from
the
product
perspective,
if
we
kind
of
put
it
more
in
user
land
and
a
chunk
of
people
onboard
unreliable
data
like
it's
going
to
make
for
the
feeling
that
the
network
is
less
reliable
from
many
different
clients
which
which
could
have
a
reputational
harm
to
the
network
as
a
whole.
F
So
I
think
that
that's
pushing
for
hey
making
sure
that
there's
some
sort
of
deal
collateral
associated
with
data
storage
seems
like
a
good
thing
to
increase.
Overall,
you
know
incentive
to
live
out
data
storage
commitments.
F
Maybe
just
yeah
like
how
much
the
network
is
willing
to
spend
in
terms
of
gas
fees
and
complexity
on
that
is
probably
the
bigger
Crux
like
I.
Think
we
want
that.
But
how
much
are
we
willing
to
spend?
What
is
the
cost
of
it
and
are?
Is
there
a
lower
cost
way
of
achieving
that
same
goal?
I
think
is
the
is
how
I
frame
it.
G
Yeah
we
can
make
that
that
goal
achievable
much
cheaper
by
moving
into
the
minor
it'll,
be
essentially
free,
except
when
it
happens,
and
so
but
I'd
also
I
think
it's
also
helpful
pulls
this
out
as
an
explicit
policy
knob,
that's
a
bit
a
bit
more
obvious,
a
bit
more
obvious
to
this
thing
that
I
could
choose
to
change
in
the
future.
It's
like
you
know,
terminating
sector.
You
pay
this
much
for
terminating
capacity
and
this
much
for
terminating
the
data
and
their.
G
You
know,
parameters
that
could
change,
presumably
reducing
but
depends
on
what
happens.
G
By
40
I,
don't
oversell
this
here,
the
gas
associated
with
activating
a
deal
that
is
a
full
plus
deal
that
goes
this
direct
route.
Yes,
I
think
that
can
reduce
by
40
to
50.
It's
approximately
you
know
double
accounted
for.
There
are
still
many
other
costs
associated
with
onboarding.
A
sector
deals
is
a
large
part
of
it,
but
the
whole
thing
is
still
going
to
cost.
You
know
it's
not
going
to
reduce
the
whole
cost
by
40
I,
don't
think.
D
Whatever
it's
not
for
the
deal
cost
per
se,
but
it's
just
on
a
network
level
we're
looking
at
40
of
the
gas
costs
today,.
G
I
don't
want
to
commit
to
that
right
now.
There
is
still
so
so
today
when
you
publish
a
deal,
that's
full
plus,
it's
also
doing
the
The
Fill
plus
allocation
work,
and
so
that
whole
thing
doesn't
go
away.
We're
still
doing
the
full
plus
bit
just
the
deal
bit
in
the
middle
goes
away
so,
depending
on
what
your
base
is,
maybe
maybe
it's
20
of
the
total
gas
because
we're
cutting
out
it
might
be
the
right
answer.
A
All
right,
thanks,
Alex
and,
of
course,
when
you
actually
open
a
flip
draft,
we
will
share
it
for
everyone,
as
we
usually
do
across
all
of
our
normal
channels.
For
the
sake
of
time,
I
think
we're
going
to
move
on
to
our
last
discussion
topic
for.
D
A
And
that
is
sort
of
an
open
discussion
that
Stephen
wanted
to
lead
about,
setting
milestones
for
protocol
changes
and
perhaps
other
matters
Stephen.
You
want
to
give
a
little
bit
of
an
intro.
E
Sure
so
yeah.
E
In
you
know
different
conference,
yes,
there
are
yes,
research,
yes,
three
steps,
but
I
think
that
is
a
very
high
level
right,
yeah,
it's
about
the
vision
level,
yeah,
it's
not
about
the
protocol.
It's
too
high
level.
Yeah
I
was
thinking
that
as
a
chair
as
a.
E
E
We,
the
community
needs
to
some
yeah
guidance
or
Direction
defined
for
a
little
bit
long-term
of
the
yeah
proof
of
change
so
to
actually
overcome
the
challenges
we
are
facing
right
now,
yeah
to
have
the
falcon
yeah
to
have
a
real
yeah,
thriving
application,
yeah
ecosystem,
which
we
really
want
to
have
yeah,
and
actually
we
have
many
things
under
discussion,
and
but
we
don't
have
a
career
yeah
milestone,
for
example,
indexed
and
half
a
year
yeah.
E
What
I
want
to
do,
and
also
your
next
yeah
one
year
or
yeah
two
years?
What
you
want
to
do
right.
So
basically,
I
really
think
that
yeah
for
Falcon,
if
we
want
to
have
a
simplify.
E
Zero
one
protocol
yeah
because
you
always
you'll,
have
yeah.
We
need
to
have
as
few
as
possible
yeah
a
resource
and
they
yeah
very
basic
layer
yeah
the
fundamental
there
is
because
that
you
want
to
enable
and
yeah
different
kinds
of
innovation
and
yeah,
which
could
be
adapted
very
soon
and
not
like
you're
very
loud
any
change.
We
used
to
get
discussed
for
a
very
long
time,
so
yeah.
E
There
are
many
things
to
do,
and
and
as
I
discussed,
for
example,
to
remove
the
marked
alter
from
yeah
the
prevailage
position
or
to
have
perhaps
how
the
data
handling
the
deal
your
deal
handling
or
the
Samsung
to
the
user
space
code
yeah
moving
yeah,
we
could
move
your
Falcon
plans
to
yeah
to
user
space
like
this
and
also-
and
another
very
important
thing
is
that
currently
they
will
do
that.
E
E
Application
based
right,
so
we
need
to
you
solve
this
problem
too
yeah.
This
is
a
very
big
thing
with
you
to
yeah,
so
so
when
and
how
so
we
need
to
have
a
client
here,
yeah,
for
example,
what
how
how
we
could
yeah
and
I
really
don't
think
the
gas
line
will
solve
this.
Probably
yes,
because
you
yeah
we'll
make
sure
that
the
rule
message
and
yeah
well
yeah
will
be
protected,
yeah
very
popular
yeah,
but
how
about
the
application
there?
E
So
we
don't
have
much
yeah
enough
bandwidth
for
the
an
application,
a
message
wrong
names
right,
so
we
need
to
have
some
consensus
layer,
innovation
to
really
create
yeah,
better
architecture
right
to
also
protect
the
the
Contour
basic.
Is
the
council
and
basically,
and
also
we
have
enough
bandwids
yeah.
Perhaps
IPC
is
a
solution
or
perhaps
we
need
to
have
your
Samsung
like
sharing
or
something
like
that.
Yep
yeah,
but
anyway,
I
say
that
we.
E
E
So
many
many
of
these
we
need
to
and
I
would
suggest
to
reduce
them
out
and
we
have
a
plan
and
so
that
the
code
they're
meeting
and
also
the
code
of
Team
engineering,
you
could
have
some
Focus.
So
we
have
something
to
do
is
just
three
months
and
also
yeah.
You
need
a
half
year
and
the
next
time
yeah,
that's
my
opinion
here.
Yeah.
Thank
you.
A
Thanks
Steven,
if
I
could
just
summarize
for
a
second
it,
so
it
sounds
like
you're
saying
that
it
would
be
helpful
to
have
these
high
level
Milestones
plotted
out
in
this
kind
of
cross-functional
or
across
the
ecosystem
roadmap,
but
that
we
need
better
technical
infrastructure
and
architecture
as
well
right
to
gate,
check
technical
progress
so
that
we
can
inform
that
roadmap.
Does
that
sound,
correct.
E
Yeah
and
so,
and
so
I'm
here,
yeah,
focusing
and
and
on
a
product
label-
okay
and
they
yeah
so
yeah
because
and
I
know
that
yeah
purple
Labs
have
a
big
plan
for
yeah,
for
example,
yeah
some
other
parts,
the
the
turbo
Market
yeah
yeah,
many
other
things.
So
here
we
want
to
focus
on
the
code,
the
code
meeting
for
the
yeah,
the
portal
change
here.
F
Alex
is
ahead
of
me
in
the
handstock,
so
I'm
happy
to
let
him
go
but
I
definitely
I'm
giving
snaps,
because
I'm
like
totally
agree
I.
Think
us
having
a
core
devs
roadmap
would
be
really
beneficial.
Some
ideas
on
how
we
might
get
there,
but
I'll.
Let
Alex
go
first.
G
No
thanks
I,
like
a
lot
of
what
you're
saying,
Stephen
I'm
very
sympathetic
to
I
like
to
focus
on
like
the
protocol.
As
a
you
know,
important
subset
of
the
like
larger
Vision
that
protocol
Labs
often
often
communicates
talking
about
file
coin
L1
protocol
itself.
H
H
G
But
it's
it's
hard.
I
I've
I've
had
a
similar
thought.
A
couple
of
times.
I
have
sort
of
some
private
notes
where
I've
sort
of
sketched
out
some
some
some
things
and
have
held
back
from
communicating
them
every
time.
I've
done
that
it's
been
wrong
in
Fairly
significant
ways
because
things
have
changed
or
you
know.
Maybe
it's
been.
Maybe
it's
been
like.
G
You
know
not
directionally
wrong,
but
but
just
the
the
timeline
or
the
sequencing
is
off
so
in
a
sense
things
that
I'm
working
on
even
even
presenting
today
are
still
following
from
a
a
direction
that
I
set
out
and
wrote
down
sort
of
two
years
ago.
It's
it's
in
fifth
discussion
somewhere
and
I'm
still
sort
of
going
down
that
path.
G
But
you
know
I
couldn't
see
how
you
know
the
macro
and
economic
changes
would
take
up
so
much
of
our
attention
and
time
and
how
they
would
change
the
landscape
and
how
the
focus
would
shift
between
different
things
over
time
and
so
I,
I'm
sort
of
I
I
think
it's
very
danger.
Well,
not
dangerous,
but
I
think
it's
potentially
unhelpful
to
do
something.
Labeled
a
roadmap,
particularly
if
you
put
dates
on
it
because
it
has
some
it
has
this.
G
That's
just
slightly
that's
more
than
we
know,
but
it
would
be
very
helpful
to
have
a
strategy
like
a
set
of
directions
and
some
understanding
about
how
we,
how
we'd
reach
some
sort
of
goals,
I,
think
that
could
be
really
helpful
and-
and
you
know,
I'd
like
to
contribute
to
it-
there
are
probably
multiple
pieces
in
it
and
you
you
mentioned
some
of
them
one.
You
know.
G
One
final
thought
is
another
reason:
I'm
a
bit,
hesitant
to
sort
of
set
out
and
and
do
this
is
whenever
I
write
down
something
vaguely
like
that,
everyone
that
assumed
that
I'm
going
to
do
it,
and
so
everyone
forgets
about
it
and
so
in
a
sense
by
leaving
there's
a
fairly
conscious
decision
of
mind
to
only
write
down
things
that
I'm
actually
going
to
do
in
the
near
term,
rather
than
write
down
things
that
are
very
long
term,
because
I
feel
everyone
else
just
backs
off
when
they
think
someone
else
has
a
handle
of
it
on
it
and
there's
not
like
this
one.
D
G
Everyone
necessarily
go
along
with
that
and
I'd.
Rather,
there
were
more
in
fact
I'd,
rather
that
there
were
more
plans,
more
people
acting
executing
on
some
plans
that
were
just
just
not
at
odds
with
each
other
would
add
up
to
more
progress
than
us
having
one
plan,
but
everyone
just
sort
of
sitting
back,
because
I
think
it's
handled.
A
Yeah
I
would
just
jump
in
to
say
that
my
experience
has
been
very
similar
to
Alex's,
and
we
also
have
tried
to
do
this
several
times.
I
think
by
you
know
setting
this
idea
that
yeah
we
should
have
milestones.
We
should
have
a
road
map
and
that's
actually
a
really
really
large
bar
to
clear
I
think
what
we
could
do
is
sort
of
invert
this
problem
and
think
about
what
we
can
do
more
technically,
especially
as
we
look
to
perhaps
introduce
new
capacities
or
scaling
for
governance
in
the
near
future.
A
To
say
what
can
we
do
to
streamline
in
certain
ways
upgrades
perhaps
or
standardize
some
of
our
testing
again?
It
falls
into
this
problem
of
things
change,
and
sometimes
we
have
to
do
things
that
we
don't
anticipate.
A
It
may
just
be
that
we're
at
a
point
of
growth,
where
it
doesn't
actually
make
sense
to
try
and
predict
too
far
into
the
future,
and
we
have
to
be
comfortable
with
a
little
bit
of
chaos
or
a
little
bit
of
uncertainty,
but
Stephen
I
think
I
have
tried
and
failed
to
do
something
similar
several
times
pretty
publicly
and
I'm
more
than
happy
to
help.
A
You
kind
of
think
through
this
and
sort
of
carry
something
forward,
but
I
think
perhaps
the
best
place
for
this
conversation
right
now,
since
it
is
such
a
large
one
is
perhaps
opening
up
a
discussion
post
in
the
courthouse
repo
in
GitHub
and
just
having
sort
of
a
longer
term
conversation
about
what
this
might
look
like
because,
again,
I
think
it
changes
a
lot
and
I
think
as
Alex
sort
of
alluded
to
this
or
Molly
did.
A
Maybe
it
gets
harder
and
harder,
especially
as
more
teams
come
into
the
mix
and
and
we
decentralize
even
further
and
further
away
from
just
being
protocol,
apps
or
just
being
one
stakeholder
group
at
a
time
that
has
a
key
slate
of
changes
to
make.
F
Yeah,
maybe
maybe
to
that
point,
Caitlyn
I,
think
it
is
very
useful
when
individual
teams,
like
you
know
our
engineering
research
team,
put
their
roadmaps
or
upcoming
Milestones,
if
you
will
out
publicly
so
that
other
teams
are
aware,
as
Alex
points
out.
That
does
create
the
problem
of
like
great
you're
solving
those
problems
like
cool
I'm,
gonna,
assume
you're
gonna
do
all
of
those
things
that
you've
listed
in
your
roadmap
and
I'm
gonna
Focus
my
area
somewhere
else,
and
so
but
but
on
the
flip
side,
you
also
get
a
notification
for
hey.
F
You
know
groups
that
could
potentially
collaborate
together,
and
so
that's
something
that
we
do
on
the
Android
side.
But,
as
you
point
out,
Stephen
that
is
very
Broad
and
it's
covering
a
lot
of
different
topics:
data
storage
and
retrieval
refactors
to
ceiling
as
a
service
changes
around
compute
over
data
networks
and
all
of
the
IPC
work
that
you
are
referencing
such
that
we
can
have
Layer
Two
networks,
building
on
top
of
filecoin
I.
F
F
Obviously,
there's
lots
of
features
that
each
of
our
implementation
might
take
on
that
are
not
consensus
critical,
but
when
we
are
making
you
know,
consensus,
critical
changes
and
upgrades.
We
need
to
be
on
the
same
page
about
you
know
what
we're
making
and
why
and
how
that
is
improving,
and
so
one
thought
is
to
actually
get
our
groups
together.
F
F
We've
been
batting
around
the
idea
of
having
a
file
coin
thing
or
a
fill
thing
for
core
devs
and
researchers
and
folks
who
are
analyzing
and
pushing
forward
the
the
you
know
more
of
this
ecosystem
and
I
think
that
could
be
a
really
useful
place
to
talk
and
and
align
road
maps
with
each
other
across
different
implementations,
and
maybe
what
we
could
have
coming
out
of
that
is
a
you
know:
core
Dev
at
least
like
a
set
of
things.
F
It
might
even
just
maybe
it's
not
even
a
road
map
but
like
here
are
the
set
of
things
that
we
think
we're
going
to
do
right
now.
Here
are
the
set
of
things
that
are
kind
of
on
our
back
burner
that
we're
investigating,
and
this
is
kind
of
where,
where
we
hope
to
be
in
like
six
or
12
months,
and
some
alignment
along
those
Vantage
points
and
doing
that
together
as
a
group
during
the
during
an
event
like
that,
might
help
us
do
knowledge.
Sharing.
F
Do
you
know
Collective
alignment
across
a
number
of
different
groups
who
are
able
to
communicate
with
each
other
very
quickly
by
being
in
the
same
place,
and
so
that's
one
idea
for
how
we
can
get
more
alignment
there.
I
do
like
your
point.
You
were
like.
We
need
something
that
focuses
on
the
core
protocol
like
IPC,
where
it's
like
IPC.
F
Actually
at
least
right
now
is
being
developed
as
a
smart
contract
on
top
of
fvm,
and
so
it's
it's
actually
less
core
core
Falcon
protocol
than
or
at
least
it
wouldn't
require
Network
upgrades
in
its
current
form
from
from
folks
in
in
this
room.
But
but
it
is
very
core
to
hey.
F
How
are
we
going
to
think
about
applications
and
Builders
and
scaling
of
the
Falcon
protocol
and
I
think
those
are
the
exact
we
want
to
have
clear
alignment
across
this
group
on
like
okay,
you
know
how
is
Falcon
going
to
scale?
What
does
that
scalability
look
like
how
do?
F
How
are
our
nodes
going
to
support
and
our
tooling
going
to
support
a
you
know
charitable
chain,
State
region-based
chain
State,
and
you
know:
how
are
we
going
to
then
make
sure
that
the
data
in
filecoin
is
available
to
those
sorts
of
networks
and
things
along
those
lines?
These
are
like
there's
a
lot
of
conversation
topics
in
here
and
I.
F
My
my
hunch
would
be
the
conference
style
venue
is
going
to
help
us
synchronize
and
you
know,
make
make
alignment
and
like
working
group
decisions
in
a
way
that
discussion
posts
might
not
serve
us.
Yeah.
A
I
actually
think
it's
a
great
thing
Stephen
that
you
brought
this
up
because
again,
this
is
something
that
we
all
think
about
and
I'll
want,
and
it's
a
big
big
problem,
but
it
sounds
like
also
I,
like
Molly's
idea
as
well,
that
we
can
kind
of
continue
these
conversations
and
in
person
works
of
especially
effectively
I
think,
for
the
sake
of
time,
we
will
jump
in
and
just
a
quick.
F
I
Yeah,
just
gonna
be
quick
yeah
so
far
regarding
the
protocol,
you
know
roadmap
that
will
that
we're
talking
about
I
think
another
quick
thing
that
we
all
can
do
at
least
for
the
node
implementators.
We
we
maintain
like
an
open
road
map
anyway
on
our
forest
repo.
I
So
if
all
the
node
Implement
risk
could
do
that-
and
we
can
just
kind
of
go
from
there
so
for
one
example
would
be
like,
for
example,
recently
Forest
has
like
a
way
to
get
the
snapshots
so
before
it
was
previously,
mostly
Lotus,
but
now
you
can
get
the
snapshots
from
forest
as
well,
so
we
can
be
like
okay.
I
Now
we
have
further
decentralized
the
filecoin
network
through
through
these
way
of
maintaining
snapshots
that
could
and
then
potentially,
we
can
probably
have
like
a
PL
newsletter
update
or
something
and
say:
okay,
this
kind
of
adds
up
to
the
further
the
entire
fileco
and
ecosystem
or
vision
of
decentralizing
the
network
or
something
so
that's
something
we
can
start
small,
that's
kind
of
easier
for
every
one
of
the
projects
to
do
it,
just
open
source,
your
roadmap,
open
social
milestones
and
together
it
it
can
potentially
come
together
for
the
bigger
file
coin.
A
Thanks
Lee
any
other
comments
or
questions
that
I
may
have
missed.
H
A
Right
lots
of
big
conversation
topics
today
lots
of
links
to
sort
of
external
write-ups
and
proposals.
We
will
make
sure
that
you
have
all
of
those
again
lucky
is
out
for
the
rest
of
the
week.
So
if
you
feel
like
you
need
something
or
have
follow-up
questions,
please
feel
free
to.
Let
me
know
as
a
reminder:
next
Monday
we
have
our
next
Community
governance,
call
lots
of
interesting
topics.
A
If
you
have
some
Curiosities
about
what
we're
doing
in
governance,
especially
over
the
next
couple
of
months,
definitely
join,
we
can
talk
through
it
and
we
also
have
the
Phil
gov
slack
channel
for
coordinating
things
outside
of
that,
specifically
so
feel
free
to
join
as
well.
Otherwise
we
will
leave
q
a
for
now
because
we're
at
the
top
of
the
hour.
Thank
you
all
so
much
and
we
will
see
you
in
July.