►
From YouTube: Filecoin Core Devs #46 (Meeting 1)
Description
Recording for: https://github.com/filecoin-project/tpm/issues/105
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
today
is
thursday
june
30th
2022,
and
this
is
meeting
one
of
two
today,
as
always,
we're
going
to
go
through
our
sort
of
typical
updates
from
the
implementation
teams
get
quick
updates
from
the
file
queen
foundation
also
and
then
touch
base
briefly
about
the
pending
v16
network,
upgrade
as
well
as
the
forthcoming
b17
network
upgrade,
which
we're
all
still
eagerly
kind
of
planning
around
then
at
the
end,
and
for
I
think,
most
of
this
meeting
today,
we're
going
to
have
vic
and
some
other
folks
from
the
crypto
econ
lab
team,
discuss
a
new
fifth
that
was
recently
added
to
the
repo
which
concerns
increasing
or
providing
an
additional
multiplier
for
longer
sector
durations
upon
ceiling.
A
B
B
So
we
have
removed
a
significant
amount
of
code
that
has
moved
into
into
the
fvm
and
moved
into
fvm
related
crates.
So
it's
it's.
It's
feels
very
great
from
from
the
voice
perspective
not
to
have
to
like
carry
the
burden
of
all
of
all
this
code.
That
is
now
now
shared
in
the
community,
and
then
we
are
moving
forward
with
making
forest
easier
to
use
and
we
will
soon
make
a
new
release.
A
All
right,
lotus
team.
C
Yeah
kind
of
kind
of
a
pre-shared
async.
Obviously
we
shipped
our
1.16
release,
which
supports
nv16,
because
we've
been
getting
a
lot
of
questions
such
confusion
about
this.
Our
release
is
not
1.16
just
because
it's
a
network
16
upgrade.
That
is
actually
just
a
complete
coincidence.
This
time,
so
do
not
expect
that
to
keep
happening.
We
have
a
whole
release,
philosophy,
doc
that
you
can
read.
C
Yeah,
the
other
thing
we
were
excited
to
share
is
that
we
kind
of
now
that
the
fbm
m1
sprint
is
slightly
wrapping
up.
We
were
thinking
about
what
we're
going
to
be
focusing
in
the
second
half
of
the
year,
so
laid
out
our
h2
road
map
right
now.
C
Q3
is
more
second
stone
than
q4,
because
things
will
evolve,
but
our
chief
priorities
that
we're
working
on
are
supporting
any
flips
that
will
be
going
into
b17
and
the
m2
upgrades
a
bunch
of
improvements
to
the
lotus
miner,
just
to
continue
to
improve
the
ceiling
pipeline
scalability
and
meet
filecoin's
goals
of
being
able
to
rapidly
onboard
large
volumes
of
useful
data
and
the
split
store
feature
which
I
think
we'll
do
a
deep
dive
on
sometime
in
july.
In
this
column,
that's
okay,
but
the
high
level.
C
It
brings
us
a
bunch
of
performance
improvements
and
achieves
online
garbage
collection,
which
is
one
of
the
most
requested
things
from
the
partners
that
we
work
with
so
yeah
exciting
times
and
lotus.
We're
excited
for
the
second
half
of
the
year.
After
taking
a
little
bit
of
a
break
post
m1
to
to
decompress.
D
Yeah,
so
adding
on
to
that,
we
are
also
shipping.
Well.
This
v1170,
which
is
our
june
like
release,
turns
out
to
be
a
big
release,
because
we
are
fixing
a
lot
of
like
tech
that
and
like
bugs
in
the
index
provider
from
the
market
side
of
the
things.
So
the
community
should
be
like
please
looking
forward
to
that,
and
the
indexer
provider
bug
should
be
backported
to
venus
as
well.
D
As
I
know,
they
are
already
supporting
that
too
happy
2.0
apr
once
needed,
but
the
other
thing
I'm
just
being
doing,
updates
for
other
teams,
but,
like
boost,
has
launched
officially
b
1.0.0
their
first
stable
release
last
week.
I
believe
that
also
marks.
They
are
shipping.
The
market
protocol
v2.
D
I'm
sure
that
they're
working
on
frc
to
standardize
that
for
all
the
like
as
a
reference
market
protocol
for
the
found
queen
network,
but
take
a
look
if
you're
supporting
market
in
the
ecosystem
and
also
they
shipped
b1.1.0,
which
supports
the
network
v60
upgrade
as
well
and
is
compatible
with
modus
v160,
but
that's
just
a
little
fyi
for
the
people
that
are
listening
to
this
call.
A
Thanks
jennifer
and
on
the
the
frc
thing
for
for
boost
yeah,
I
think
I
saw
you
also
had
provided
feedback
to
brenda
about
that
actual
draft.
That's
going
to
be
pushed,
but
we
do
now
have
space
in
the
fips
repo
on
github.
For
those
file.
Coin
requests
for
comments.
Those
standardization
docs,
there's
currently
only
one
there,
so
it's
frc
38,
I
believe,
which
is
the
index
or
advertisement
protocol
that
had
been
presented.
A
A
couple
of
core
devs
calls
back
and
then
boost
is
going
to
be
the
second
one,
so
any
like
specs
or
other
documentation
will
be
found
there
just
like
for
any
other
fip.
But
again
it's
not
like
mandatory,
as
everyone
knows
so,
yeah
all
right.
Any
questions
for
the
lotus
team.
A
All
right,
and
so
for
the
venus
team
today
updates
are
pretty
consistent
with
weeks
past
they're
continuing
to
to
really
like
focus
on
updating
the
venus
chain.
Services
support
b16
some
ongoing
feature
enhancements,
as
always,
but
no
concerns
about
joining
mainnet.
On
july
6.
stephen
had
also
flagged
that
there
had
been
an
api
change
that
hadn't
been
properly
documented,
so
follow
up
with
him
and
make
sure
that
it's
in
the
release
notes
going
forward
but
other
than
that
nothing
out
of
the
ordinary.
A
All
right
so
from
the
file
queen
foundation,
nothing
huge
to
flag.
Here
we
have
the
same
number
of
accepted
fips,
so
this
is
great,
obviously
we're
moving
towards
implementation
during
v16.
So
this
will
condense
relatively
soon.
We
have
a
couple
of
new
drafts
that
have
been
pushed
into
the
repo.
A
So
the
repo
is
fully
up
to
date.
You
can
see
them
in
the
readme
docs
and
the
table
of
all
the
fips
and
now
frc
documents,
so
they
should
be
easy
to
find
and
again
as
we
look
to
sort
of
change
up,
the
core
devs
meeting
template
going
to
find
new
ways
to
present
this
information
so
that
it's
a
little
bit
more
accessible
to
you
during
these
calls.
A
Okay,
so
for
network
v16,
everything
should
be
on
track
and
I
feel,
like
teams
know
very
much
what
each
other
is
doing.
So
we
should
be
good
to
go.
I
did
want
to
give
you
a
chance
to
kind
of
chat
here,
a
little
bit
about
the
war
room
proposal
that
you
had
made
on
the
agenda.
C
Totally
so
warm
is
a
very
dramatic
term.
Jennifer
doesn't
like
it
so
generally,
when
the
network
upgrades
happen.
Obviously
we
at
least
like
the
lotus
team
gets
together
in
a
virtual
zoom
room
to
watch
the
upgrade
happen,
and
you
know
if
and
then
perform
a
bunch
of
like
small
sanity
checks.
Our
storage
providers
still
submitting
their
posts
saw.
Is
the
power
fine?
Did
the
chain
halt?
All
these
obvious
things
to
check?
Usually
it
just
winds.
C
Up
being
you
know,
30
minutes
of
us
kind
of
taking
deep,
breaths
and
being
like.
Okay,
everything
looks
good,
everything
looks
good
and
then
we
drop
out,
and
but
if
something
does
go
wrong,
then
it's
also
useful
to
have
everyone
online
to
quickly
troubleshoot
and
we
generally
split
up
into
smaller
groups
so
like
if
it
looks
like
a
vm
thing,
the
bm
folks
can
go
and
investigate
and
so
on,
and
so
we'll
be
doing
that
as
always
with
this
upgrade.
C
But
I
was
thinking
given
that
genuinely
there
are
like
multiple
different
teams
that
have
contributed
to
this,
and-
and
so
you
know,
if
there
is
investigation
needed,
it
might
be
the
fm
team
that
needs
to
jump
into
it.
It
might
be
folks
are
familiar
with
the
actors,
in
which
case
the
forest
folks
have
the
greatest
familiarity.
C
It
might
be
proves
things
because
so
yeah,
so
I
thought
it
would
be
an
idea
to
essentially
extend
that
room
and
have
have
a
yeah,
a
broader
group
that
were
all
on
the
on
the
same
call
for
and
if
things
go
wrong,
then
we
can
identify
the
group
of
people
needed
more
easily.
Who
can
then
go
into
their
kind
of
sub
room
to
investigate.
D
For
first
time,
if
we
do
have
this,
we
are
going
to
have
the
room
open
around
like
9am
or
9
30
on
next
wednesday
est
in
the
morning
utc.
That
will
be
1pm.
C
Also,
someone
would
like
to
volunteer
to
organize
this,
that
we
can
use
one
of
kind
of
pl's
rooms
if
necessary,
but
also
if
we
wanted
to
use
a
foundation
room
for
it.
That
would
work
as
well.
D
I'm
sorry
is
there
interest
from
the
forest
team
to
do
this
with
us
together.
E
Sorry
that
the
exact
what
was
the
date
you
guys
mentioned.
D
E
D
The
next
wednesday
july,
the
6th
from
9
to
11
a.m,
yeah.
E
C
A
A
A
All
right,
any
other
questions
or
flags
to
raise
about
b16
from
anyone.
A
All
right
seems
like
we're
chugging
along
then
thinking
about
network
v17
as
before
sort
of
understanding
and
tamping
down.
The
scope
for
this
upgrade
is
still
very
top
of
mind
and
jennifer,
and
alex
north
in
particular,
have
added
some
really
helpful
comments
in
the
community
discussion
post,
which
is
in
the
tpm
repo.
A
As
always,
this
is
linked
in
all
of
our
past
meeting
notes
also.
But
if
you
haven't
sort
of
taken
a
look
at
this,
I
highly
recommend
it
right
now.
Obviously
this
is
very
up
in
the
air,
but
before
we
can
even
get
close
to
a
timeline,
we
need
to
figure
out
which
fips
we
are
considering,
including
and
right.
Now
there
are
five
that
seem
to
be
the
highest
priority.
A
So
what
I'd
like
to
ask
is
that,
after
this
call,
I
can
send
out
some
documentation
with
obviously
there's
links
here.
This
will
be
available
in
the
meeting
notes,
also
but
links
to
all
of
the
drafts,
as
well
as
other
open
fifth
documents
and
discussion
posts
that
could
potentially
be
readied
as
final
fips
prior
to
sort
of
a
tentative
cutoff
date
for
inclusion
in
the
upgrade
and
as
discussed
before.
A
It
would
be
great
if
all
of
the
implementation
teams
could
sort
of
plot
that
implementation
pathway,
so
that
we
can
begin
to
understand
what
sort
of
capacity
demands
these
fips
are
going
to
have
upon
your
teams
very
important
to
remember
and
reiterate
that
it
is
technically
a
core
dev
decision
about
what
gets
included.
So,
if
you're
looking
at
something
and
realize
that
there
are
complexities
to
these
things,
that
may
not
be
possible.
That
is
a
really
important
flag
to
raise
and
the
earlier
you
raise
it
the
better.
A
We
can
sort
of
plan
around
it
so
happy
to
have
a
conversation
about
any
of
these
now
or
if
anyone
has
any
particular
platform
tool,
whatever
that
they
would
like
notes
captured
in,
so
that
you
can
provide
feedback
on
what
your
potential
implementation
pathway
is
going
to
be.
That
would
be
helpful
too.
Otherwise,
I
will
send
it
to
you
in
a
notion
doc
that
you
can
that
you
can
write
and
edit
in
as
well
any
questions,
ideas,
thoughts.
A
This
is
the
same
thing
that
we
had
discussed
in
the
last
meeting
as
well,
so
it
shouldn't
be
totally
new.
It
just
is
about
incremental
process
to
get
to
a
point
in
which
we
can
confirm
the
scope
more
confidently.
A
All
right
so
sort
of
flying
through
today's
presentation,
but
vic
we'll
turn
it
over
to
you
and
your
team.
If
you
want
to
lead
a
conversation
about
the
fit
that
you
guys
have
been
working
on,
that
would
be
great.
F
Yeah
great,
thank
you
yeah
good
to
meet
you
all
for
those
I
haven't
met.
I'm
vic,
I'm
joined
by
tom
and
maria
from
crypto
uconn
lab.
The
main
motivation
today
is
a
kickoff
discussion
on
this
proposed
sector
duration
extension
multiplier
caitlin.
Is
it
okay?
If
I
share
screen
or
is
that,
can
you
give
me
the
the
controls
yeah?
I
for
sure
can't
I
can
say
thank
you.
F
Awesome
so
so
quick
kind
of
overview
of
the
motivation
here,
crypto
ecolab,
wants
to
design
incentives
to
align
the
behavior
of
network
participants
with
one
another,
but
also
with
the
larger
vision
of
the
platform
network.
We
see
the
possibility
of
the
current
economic
state
of
the
network
requiring
some
new
incentive
kind
of
designs.
F
The
reason
we
have
proposed
this
fip
is
therefore
twofold.
The
first
is,
we
think
there
are
incentives
that
are
missing
that
could
better
align
us
with
the
longer-term
goal
of
the
network.
We
also
think
that
there
are
current
macroeconomic
circumstances
at
play,
in
which
there
might
be
some
persistent
unfavorable
conditions
used
to
certain
stakeholders,
which
is
why,
from
a
macroeconomic
perspective,
we
think
that
this
would
be
kind
of
a
good
idea.
F
The
most
important
thing
to
consider,
though,
is
we
want
this
change
to
be
as
minimal
as
possible.
We
want
the
smallest
chain
surface
change
surface
to
the
protocol,
and
we
also
want
to
be
very
transparent
and
active
about
how
we
make
this
decision.
With
that
in
mind
a
couple
weeks
ago,
we
put
forth
a
suggestion
for
protocol
improvement.
F
This
was
authored
by
juan
mali
and
by
crypto
crypto
econ
lab.
The
idea
is,
we
want
to
introduce
a
sector
duration
multiplier.
F
F
We've
posted
this
as
a
discussion,
and
then
we
submitted
a
pr
request
in
the
fib
repo.
The
most
important
thing
to
note
is:
while
we
have
submitted
a
pull
request,
we
are
very
much
in
the
draft
stage.
We
really
want
community
feedback
and
we
really
want
to
iterate
on
the
initial
example.
F
The
the
initial
kind
of
example,
though,
would
be
to
we
want
to
increase
the
minimum
saturation
time
to
one
year
and
increase
in
maximum
stress
duration
time
from
540
days
to
five
years,
and
we
would
also
want
to
have
this
kind
of
linear
scaling
of
consensus
power
with
respect
to
how
long
you
commit
your
sectors.
F
These
are
tunable
parameters
and
they're,
subject
to
change
based
on
kind
of
what
we
the
feedback.
We
are
hearing
from
the
community
and
we've
already
kind
of
been
entering
into
a
fairly
robust
discussion,
but
the
most
important
thing
is
regardless
of
what
we
decide.
F
We
want
to
make
sure
that
we
have
a
really
really
good
consideration
of
these
potential
scenarios
and
an
understanding
of
what
these
changes
will
do
and
also
not
make
too
kind
of
shocking
of
a
change
and
introduce
things
in
a
way,
but
still
kind
of
achieve
our
intended
goal
of
of
you
know
we
want
to
have
a
more
stable
economy.
We
want
to
have
funds
locked
in
a
certain
way
in
relation
to
this.
You
know
circulating
supply
and
released
schedule
of
phil
and
also
reward
miners
fairly
for
their
commitments
to
the
network.
F
So
again,
just
sticking
kind
of
concluding
thoughts
from
from
from
our
end
is
that
we
are
certainly
very
much
in
the
discussion
phase.
Our
cryptic
econ
lab
opinion,
however,
is
that
the
speed
of
deployment
does
matter.
We
don't
want
to
rush
things.
We
want
to
deploy
this
in
a
way
that
is
most
in
line
with
what
the
community
wants.
Our
kind
of
take
is
that
there
is
a
there
is
a
some
kind
of
necessity
to
do
this
quicker,
rather
than
you
know,
wait
wait
longer,
given
the
current
network
state.
F
But
again
that
is
our
view,
and
that
is
something
that
is
up
for
discussion
as
well,
and
we
are
also
certainly
considering
alternatives
to
the
initial
proposed
model.
But
the
initial
kind
of
proposition
was
phyllis
is
kind
of
our
philosophy
on
what
we
think
might
an
improvement
might
look
like,
and
we
will
always
consider
you
know
something,
maybe
something
that's
more
easily
implementable
or
something
that
that
the
community
thinks
is
preferable.
F
With
that
in
mind,
we
have
some
questions
for
you
guys,
based
on
what
we've
kind
of
described,
and
you
know
feel
free
to
ask
questions.
How
difficult
is
something
like
this
to
implement
and
how
would
it
interact
with
the
existing
protocol
and
also,
I
think
you
know
caitlin
kind
of
kind
of
showed
us
some
timelines
for
network
upgrades,
given
that
we
think
this
is
fairly
critical.
F
When
will
we
need
this
kind
of
community
in
line
alignment
to
buy,
and
how
would
you
like
to
spec
out,
and
when
do
you
first
see
this
actually
becoming
a
change
implemented
on
the
protocol?
So
that's
the
so.
I
gave
you
a
lot
of
questions
there
and
I'm
sure
you
have
lots
of
questions
for
us,
but
I'll
stop
there,
and
then
we
can
continue
this
discussion
based
on
what
you
guys
think.
F
A
F
A
A
So
from
from
my
understanding
of
having
read
through
your
fifth
draft,
my
general
understanding
at
a
at
a
high
level
of
certain
things,
so
it
seems
like
this
kind
of
proposal
would
actually
be
a
pretty
light.
Lift
in
terms
of
implementing.
It
would
just
be
a
code
change,
but
there
is
a
lot
of
sort
of
hesitation
from
storage
providers
about
this
proposal
who
are
concerned
about
this.
A
The
scope
of
what
would
effectively
be
a
50x
rewards
increase,
but
also
that
this
would
largely
disincentivize
smaller
storage
providers,
who
don't
have
the
collateral
costs
necessary
to
take
longer
term
storage
deals.
F
So
there
are
there,
those
the
concerns
are
valid
and
we
we
do
plan
on
responding
to
them,
but
I
think
the
best
way
to
respond
to
them
is
kind
of
presenting
a
set
of
assumptions
for
simulating
how
the
protocol
might
react
to
this
change
and
then
kind
of
having
a
more
quantitative
analysis
as
to
why
or
why
not,
there's
those
those
initial
kind
of
gut
you
know,
knee-jerk
reactions
might
be
not
as
bad
as
people
think
you
know
we
have.
F
We
are
in
that
we,
we
are
doing
a
you
know,
kind
of
in
the
process
of
simulating
and
analyzing
these
potential
scenarios,
and
we,
when
we
engage
in
discussion
with
the
community,
we
plan
on
leveraging
those
to
provide
those
kind
of
answers
and
obviously
in
a
public
public
way,
but
also
very
sensitive
to
when
we
do
release
his
responses.
We
want
to
make
sure
that
we
have
a.
We
have
a
fair
amount
of
confidence
in
in
in
what
we're
saying
in
our
assumptions.
F
A
So
then,
I
wonder
so.
You
also
asked
them
about
the
timeline
right,
so
so
for
the
v17
network
upgrade,
we
are
already.
There
are
more
fifth
drafts
than
we
will
be
able
to
include,
and
so
it's
a
question
really
for
for
core
devs
to
sort
of
negotiate.
What
is
the
highest
priority?
I
understand
that
ceo
feels
like
this
is
high
priority,
which
is
great
in
order
to
be
included.
A
That
would
likely
mean
that
you
would
need
to
achieve
pretty
broad
consent
by
the
end
of
july,
so
that
we
could
successfully
complete
that
last
call
process,
and
we
can
talk
offline
too,
a
little
bit
more
about
the
details
of
that.
But
I'm
wondering
what
the
other
implementers,
what
the
lotus
team
are,
what
the
forest
team
think
about
this
proposal
and
again
at
a
high
level
where
they
see
sort
of
motivation
to
include
not
include
what
questions
they
would
have
to
help
get
them
there.
E
Yeah,
so
I
just
going
through
the
discussion
threads
here
and
from
my
understanding
of
the
proposal
here,
it
looks
like
I
think
it's
a
good
proposal
overall,
because
currently
the
minimum
deal
like
you
know
it's
minimum.
F
E
However,
I
think
there's
a
lot
of
not
a
lot
of,
but
from
what
I
see
there
is
definitely
and
concerns
from
the
storage
providers
on
on
a
few
things
which
includes
you
know
from
what
I
see
here
like
concerns
about
small
small
storage
providers,
not
being
able
to
have
the
resources
for
longer
deal
term
making
and
also,
like
maybe
certain
things
about
the
reward
incentivization
related
to
it
before
that
can
be
sorted
out.
I
think
it
might
be
difficult
to
put
this
fib
into
the
next
nv17.
E
That's
my
initial
thought.
Perhaps
you
know
we
can
filter
out
and
come
into
consensus
with
these
provider
net
storage
providers
and
probably
think
about
incorporating
into
the
next
next
network,
upgrade
that's
basically
my
initial
overview
and
talk
from
what
I've
understood
in
the
last
you
know,
30
minutes
or
so.
F
Yeah,
so
if
I,
if
I
hear
you
correctly,
the
main
kind
of
block
here
is
this
consensus:
is
this
alignment
with
storage
providers
on
their
preferences
for
how
they
would
like
something
like
this
included
if
they
would
even
like
something
like
this
implemented?
F
Even
if
that
kind
of
let's
say
that
consensus
has
arrived
that
over
the
course
of
the
next
coming
weeks,
do
you
so
do
you
see
that
you
still
see
the
difficulty
in
potentially
including
this
in
the
v17
upgrade
and
the
reason
we
asked
we
asked
this
is
mainly
because
of
the
temporal
nature
of
why
we
think
this
is
fairly
important.
Given
the
current
state
of
the
economic
state
of
the
network.
E
Yeah,
so
for
as
far
as
implementation
is
concerned,
I'm
probably
not
the
best
person
to
answer
that.
Considering
you
know
that
they're
I
don't
remember
the
list.
Do
we
do
have
a
few
level
of
fips
and
I
think
for
nbc17
we
did
have.
E
We
did
mention
that
we
will
keep
it
a
little
less
heavy
on
the
client
implementations,
because
for
at
least
for
forest
we
were
doing
a
little
catch-up
after
the
fpm
testing.
So
we
personally
on
our
end,
we
would
like
to
keep
it
a
little
light
on
the
client
implementation,
but
I'm
not
really
sure
how
heavy
this
goes
into
climb,
implementations
or
not
at
the
moment,
definitely
not
the
best
person.
Maybe
our
team
can
review
it
and
try
to
give
you
guys
an
answer
async.
B
No,
I
don't
really
have
any
any
comments.
No
ideas.
A
So
I
think
one
of
the
perhaps
a
proactive
way
forward
in
this
is,
as
mentioned
for
all
of
the
fips
that
are
being
considered
for
v17
implementers.
Just
go
around
are
going
to
be
asked
to
design
those
implementation
specs
prior
to
us
confirming
a
scope
so
that
we
do
understand
what
sort
of
work
demands
are
going
to
look
like
on
teams.
A
I
I
think
my
perspective
is
the
governance
one.
This
seems
like
a
lighter
lift
than
some
of
the
other
ones
we're
considering
so
inclusion
may
be
quite
possible
from
a
capacity
perspective,
it's
more
just
about
understanding,
sort
of
what
that
sort
of
impact
modeling
looks
like
and
making
sure
we're
confirmed
that
this
is
like
a
strong
technical
change
with
well
well-intended
consequences,
and
we
understand
how
it
will
sort
of
affect
existing
like
business
models
or
other
more
qualitative
efforts
in
the
network
and
and
we
could
move
towards
getting
these
things
done.
A
But
I
think
again
as
a
starting
point:
if
teams
want
to
again
take
a
look
at
what
would
be
required
implementation
wide
just
so
we
understand
what
additional
scope
of
work
we're
discussing.
That
may
be
the
first
step
towards
understanding
whether
or
not
implementation
teams
are
comfortable
potentially
including
this.
F
Right
that
sounds
good
to
me.
I
think
it's
fairly
clear
what
what
we
want
to
continue
with
on
our
end,
which
is
kind
of
just
further
validation
from
a
more
rigorous
standpoint
of
the
specs
of
this
fifth-
and
you
know,
we
presented
that
kind
of
general
idea,
but
all
of
this
is
subject
to
tune.
Obtainability
function,
changes,
parameter
changes
as
well
as
some
you
know,
changes
dependent
on
on
what
we
hear
from
people
like
nicola
crypt,
et
cetera.
So
so
I
think
I
think,
that's
very
fair.
F
A
All
right,
then,
I
think
that
brings
us
to
the
end
of
today's
call
again.
Thank
you
guys
for
presenting.
We
had
a
smaller
meeting
today,
but
we'll
have
a
second
call
this
afternoon
as
well
hope
to
see
you
at
and
otherwise
we
will
make
sure
that
all
of
this
is
captured
in
the
documentation
and
shared
with
implementation
teams
as
well
and
we'll
add
you
to
the
fill
implementers
channel
on
slack.
A
So
if
you
want
to
see
that
documentation
you'll
be
able
to
as
well
thanks
caitlin
awesome
cool
all
right
thanks,
everyone
see
you
in
two
weeks.