►
From YouTube: Filecoin Core Devs #50
Description
Recording for: https://github.com/filecoin-project/tpm/issues/111
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
good
morning,
good
evening
this
is
filecoin
core
devs
number
50.
today
is
Thursday
the
6th
or
7th
of
October,
depending
on
where
you
are
in
the
world
and
as
usual,
we
have
a
very
large
and
probably
quite
packed
agenda
today.
So
we
are
going
to
jump
into
it.
A
Do
you
want
to
first
flag
what
we're
going
to
be
discussing
today,
because
there
were
some
last
minute
changes
as
different
core
devs
surface
different
interests
and
needs
we're
going
to
first
start
with
just
a
quick
review
of
sort
of
the
rules
that
govern
the
cordov's.
Call.
A
We've
sort
of
debated
this
over
the
last
couple
of
weeks
as
we've
gone
through
the
fill
pool
process,
but
want
to
remind
everyone
of
sort
of
the
decisions
we
made
in
June
of
this
year
and
then
also
add
a
couple
of
qualifying
elements
to
that
as
well,
then,
just
a
very
quick
update,
also
on
sort
of
next
steps
related
to
fip36
and
the
fill
pole
process,
and
then
Jennifer
is
going
to
also
give
us
a
quick
update
about
planning
for
the
v17
network
upgrade
then.
A
Finally,
we
will
turn
it
over
to
steb
and
he
is
going
to
walk
us
to
the
F4
address
class
proposal
that
has
been
in
the
discussion
forum
for
a
couple
of
weeks
now
and
we
will
open
up
to
q
a
all
right.
So
let
me
check
make
sure
no
questions
all
right,
great,
so
core
devs.
This
is
the
definition
we've
always
had.
A
I
am
going
to
ask
for
some
Grace
a
little
bit
I'm
quite
tired
this
week,
going
to
refine
this
language
a
bit
just
so
it's
direct
and
exact,
but
this
is
really
always
how
we've
thought
of
core
devs
and
as
there's
more
interest
in
having
people
join.
This
meeting
just
want
to
make
sure
everyone
is
on
the
same
page
about
the
purpose
of
this
meeting
and
what
you
do
as
a
core
Dev.
A
What
is
expected
of
you
so,
very
importantly,
core
devs
are
a
technical
governing
body
and
although
there
are
many
instances
in
which
the
people
on
this
meeting
overlap
in
other
work
areas
and
are
asked
to
wear
many
hats,
Jennifer
I'm
going
to
use
you
as
an
example,
it's
on
the
Lotus
team,
she's,
a
FIP,
editor
she's,
also
a
core
Dev
when
you're
in
this
meeting.
A
The
ask
is
that
we
surface
technical
discussions
that
affect
broad
swaths
of
the
protocol
and
that
we
really
focus
on
discussing
sort
of
the
technical
developments
and
strategic
changes
on
the
governance
and
technical
side.
The
core
deaths
are
going
to
ask
to
provide
expertise
around
at
a
given
moment.
A
So
this
includes
Hosting
technical
discussions,
reviewing
fips
weighing
in
on
critical
Network
infrastructure
and
security
issues,
and,
as
we
saw
very
recently
with
the
fill
pool
process,
it
also
means
over
time
taking
on
more
and
more
governance
rights
in
the
network
and
helping
us
reach
consensus,
especially
when
we
have
very
critical
or
divisive
issues
to
work
through.
Very
importantly,
I
want
to
stress
that
the
core
devs
group
should
not
be
a
technical,
Planning
Group
per
se.
A
This
is
a
place
where
we've
had
some
process
collapse
in
the
past
and
again
I
want
to
stress
that
individual
core
devs
may
be
very
relevant
to
the
technical
planning
for
Network
upgrades
Etc,
but
going
forward.
We
should
create
clear
your
delineations
between
what
is
the
plan,
the
timeline,
the
scope
and
the
actual
content
of
fifths.
We
are
discussing
rather
than
asking
this
very
large
group
of
different
stakeholders
to
weigh
in
and
provide
very
detailed
guidance,
because
that
is
probably
not
the
most
effective
use
of
everyone's
time.
A
So
a
couple
of
expectations
for
core
devs
also
and
a
way
to
sorry,
if
there's
a
member
of
your
team
who's
trying
to
enter,
and
they
can't
please
let
me
know:
there's
someone
in
the
waiting
room,
I,
don't
know
who
they
are.
But
that
being
said,
a
couple
of
things
I
want
to
flag
core
devs
are
expected
to
attend
meetings,
and
that
is
really
the
threshold
we
use
to
determine.
Who
is
a
core
Dev?
A
We
have
a
slack
Channel
as
well.
The
slack
channel
should
really
mirror
those
who
are
standing
members
of
this
meeting
and
in
the
past
this
has
always
been
the
expectation
as
well.
We
have
just
not
actually
kept
really
solid
attendance
or
been
very
strict
with
this
requirement
going
forward.
I
think
we
will
be
right
now.
The
numbers
that
we've
considered
are,
if
we're
meeting
on
a
monthly
basis.
You
know
if
you
missed.
Two
three
meetings
will
definitely
be
in
touch
to
make
sure
that
you're
still
able
to
participate.
A
If
you
miss
more
than
four
within
a
year,
we're
going
to
remove
you
as
a
standing
participant-
and
this
is
just
to
ensure
that
core
devs
are
engaged
over
time
and
are
a
consistent
point
of
reference.
When
we
need
governance
decisions
made,
we
don't
want
poor,
devs
sort
of
coming
in
and
out
as
they
have
different
fips
that
they
may
be
authoring
Etc.
A
Additionally,
one
new
thing
that
we'd
like
to
propose
is
to
actually
cap
the
number
of
core
devs
who
can
come
from
a
single
team
for
a
lot
of
teams
within
the
biocoin
ecosystem.
Your
team
is
tasked
with
working
on
the
protocol,
so
it
would
make
sense
that
you
have
protocol
expertise
and
may
all
want
to
be
here,
but
again,
because
poor
devs
imbue
governance
responsibilities.
A
As
always
these
meetings
are
reported.
Anyone
is
welcome
to
watch
them
afterwards
and
additionally,
if
you
are
a
FIP
author
at
a
time
or
we
are
discussing
something
that
is
related
to
your
work,
of
course,
observers
and
participants
are
welcome
to
come
in.
They
just
wouldn't
be
considered
standing
members
and
the
last
thing
is:
we
expect
just
sort
of
consistent
engagement
over
time
if
you're
pinged
in
the
core
devs
Channel,
please
respond
Please,
be
aware
of
fips
as
they
move
through
the
repo
and
also
be
engaged
in
providing
feedback.
B
A
I
think
this
last
piece:
this
is
not
like
a
really
strict
like
list
of
applications.
This
is
more
just
to
say
that
you
know
if
you're
coming
to
a
courthouse
meeting
and
we
flag
that
we're
going
to
be
talking
about
three
different
proposals.
It's
expected
that
you've
actually
read
through
those
proposals
before
the
meeting.
A
It's
great.
If
core
devs
are
you
know,
kind
of
maybe
once
a
week
or
every
couple
of
days,
taking
a
look
at
new
discussions
that
come
in
and
participating
in
those
across
the
board.
I
think
people
are
really
good
at
this.
We
see
a
lot
of
Engagement
and
really
good
conversations
happening
in
the
governance
Forum.
But
it's
just
a
reminder
in
general
that
this
is.
This
is
part
of
that
workflow.
It's
not
a
strict
requirement
again,
but
it
is
something
we
want
to
see.
A
And
I
will
note
also
that
all
of
this
this
is
sort
of
a
high
level
overview,
but
we
will
add
details
to
the
TPM
repo
and
make
this
very
explicit
as
well.
It
will
always
be
there
as
a
point
of
reference
and
again
the
goal
of
having
kind
of
like
rules
and
procedures
for
this
thing
is
just
to
make
sure
everyone
is
on
the
same
page.
It's
not
to
keep
anyone
out.
So,
of
course
it
can
be
flexible.
If
you
want
changes
and
you
feel
very
strongly
about
them,
you
can.
A
Let
me
know
too
and
I
think
the
last
thing
to
know
is
that
when
it
comes
to
admitting
new
members,
if
someone
asks
we're
happy
to
add
them
as
support
Dev,
we
can
flag
it
for
the
group
in
the
channel
in
case.
Anyone
has
a
reason
why
they
don't
think
they
should
be
here,
but
we
want
to
give
people
the
benefit
of
the
doubt
that
they
have
a
reason
to
participate
until
they
give
us
a
reason
to
think
otherwise.
A
C
Makes
sense
two
quick
notes:
I
I
think
you
mentioned
this
verbally,
but
I
think
it
would
be
useful
to
be
clear
that
being
a
core
Dev
is
not
the
the
sole
way
to
have
access
to
the
core
Dev
meetings,
and
so
you
know
those
are
two
distinct
rules,
kind
of
the
distinction
between
standing
members
and
folks
who
have
contributions
to
make
whether
that's
they
have
a
new
FIP
or
they
really
feel
strongly
about
some
discussion.
C
That's
happening
or
they
just
want
to
attend,
so
I
think
that'll
be
we're
not
trying
to
keep
the
meetings
themselves.
I.
Think
second
note
is
with
regards
to
what's
on
the
slide
right
now,
I
think
they're,
especially
with
leadership
and
engagement.
There
is
a
little
bit
of
subjectivity
there,
but
I.
Don't
think
this
is
a
problem.
C
We
are
a
small
enough
group
that
we
can
subjectively
in
a
case
by
case,
so
we're
not
saying
we,
you
can
subjectively
in
a
case,
I
guess
faces,
decide
whether
consistent
engagement
has
been
met,
and
so
on
one
day
we
might
be
so
large
groups,
that's
no
longer
feasible,
but
I
think
this
is
fine
for
today
and
for
the
near
future.
A
Yeah
I
have
no
problem,
pinging
people
and
asking
to
do
stuff
so
I
think
we'll
be
okay
and
I.
Think
Axel
asked
in
the
chat.
Do
we
have
a
list
of
teams
that
each
would
have
two
members
on
our
system?
This
applies
to
every
team
applies
to
the
Falcon.
Foundation
applies,
the
Cel
should
apply
to
Lotus
and
Forest
as
well.
A
D
I
think
this
is
important,
because
I
think
it
happens
more
and
more,
that
teams
start
fragmenting
and
was
forming
something
so
I
I
mean
like
in
crypto
conduct
we're
reorganizing
ourselves
and
dividing
in
three
substance,
but
presumably
we
would
be
still
cryptic
a
lot,
but
in
that
sense
maybe
not
right
now,
but
in
the
near
future,
maybe
useful
to
formalize.
These
are
the
teams
that
we
keep
track
of
not
this
new
something
server
evidence.
D
A
Yeah
I
think
I
think
I
follow
happy
to
make
it
explicit
if
that
drives
Clarity
for
everyone,
too
I
think
within
crypto
econ
lab,
as
you
guys
reorg
a
bit.
It
will
also
just
be
up
to
you
to
how
you
want
to
delegate
that
work.
If
you
think
you
know,
there's
three
sub
teams,
you
want
three
members.
We
can
talk
about
it.
It
probably
makes
sense
again
we
don't
want
to
be
overly
rigid.
We
just
want
to
make
sure
that
there's
a
good
balance
of
representation
on
the
call.
B
B
So
it's
like
if
the
next
like
priority
is
working
our
storage
market,
then
maybe
you
know
Zen
will
be
our
experience
during
the
core
lab
on
that,
like
I've
heard
for
that
parent
and
if
we
are
working
on
consensus,
maybe
a
issue
and
and
Magic
World
like
people
is
Step
a
and
like
switch
the
swap
out
to
listen
like
I,
think
we
we
might
rotate
within
the
team
as
well
sure.
A
And
again,
people
can
come
in
if
they're
working
on
something
of
interest
to
the
group,
I
think
for
individual
teams.
We
can
just
look
at
it
on
case-by-case
basis
too
a
firm,
a
standard
and
go
forward.
We
do
have
a
lot
of
topics
to
get
through
today,
so
I
don't
want
to
spend
too
much
time
deliberating
this
Molly.
Do
you
have
a
question
as
well.
E
E
You
could
maybe,
when
it
comes
to
voting
on
things,
cap
number
of
votes,
sure
cool
the
governance
piece
of
it,
but
being
a
core
Dev
means
something
different,
which
you
know
engaging
in,
like
technical
leadership,
about
the
evolution
and
development
of
the
Falcon
network,
from
an
implementation
perspective
from
a
design
from
security
Etc,
and
there
can
totally
be
teams
where,
like
there
are
multiple
people
who
are
very
core
to
that
playing
those
sorts
of
roles
and
I.
E
Don't
think
it
makes
sense
that,
like
two
of
you
are
core
devs
and
four
of
you
are
not
Corda,
you
know,
I
think
it.
It
sets
a
very
weird
expectation
of
what
it
means
to
be
a
port
of
I.
Think
people
who
are
on
core
implementation
teams
who
are
making
important,
Technical
and
design
decisions
for
the
evolution
of
the
network
are
all
core
devs.
What
it
means
from
a
voting
perspective
can
be
something
else
and
I
think
that's.
Okay
and
so
I
would
delineate
those
two
things.
E
The
other
thing
I,
don't
think
synchronous
participation
in
this
meeting
should
be
a
bar
for
whether
or
not
someone
can
be
a
core
Dev
again
we're
a
remote
distributed
Community
across
many
different
time
zones
like
I
know,
we
moved
this
meeting
around
to
try
and
to
enable
that,
but
I
think
asynchronous,
like
important
participation
by
proposing
reviewing
like
commenting
on
fips
and
their
evolution.
E
Things
like
that
should
also
be
a
viable
way
for
people
to
participate
in
a
leadership
role
in
the
the
community
like,
for
example,
I
think
it
would
be
kind
of
a
I
expect
one
to
very
infrequently
come
to
synchronous
meetings,
because
people
are
super
super
busy.
However,
I
think
you
know
core
Dev
sets
a
lot
of
very
core
leadership
direction,
for
the
network
is
very
involved
in
like
reviewing
and
and
like
commenting
on
on
Direction,
giving
people,
mentorship
and
advice,
and
so
some
of
the
bars
here
seem
to
be
excluding
participation.
E
Instead
of
of
pulling
the
knowledge
and
expertise
needed
to
to
make
this
network
great.
A
Yeah
I
I
understand
where
this
is
coming
from
and
it's
we
have
actually
run
this
meeting
historically
in
that
way
where
it's
much
more
open,
there's
no
real
requirements,
and
we
have
this
much
looser
definition
of
how
we're
using
this
meeting,
and
we
have
found
that
that
has
caused
problems
and
actually
enabling
us
to
like
make
decisions
and
understand
who
is
responsible
for
what.
E
But
I
think
sorry,
the
difference
is
this
is
a
meeting
and
this
meeting
can
have
its
own
structure
and
format.
The
core
devs
group
and
membership
of
making
decisions
is
a
different
thing
and
you
know
again:
we
follow
the
ethereum
model
when
we
started
out
on
this
and
core
devs
are
not
only
the
people
who
show
up
to
this
meeting.
E
These
do
not
have
to
be
one
in
the
same
thing,
but
I,
don't
think
you
can
Define
the
core
devs
Community
the
people
who
are
like
discussing
fips
and
their
implementation
by
who
shows
up
to
a
synchronous
meeting.
Often
the
people
who
show
up
to
a
synchronous
meeting
are
the
ones
who
are
involved
in
active
design
and
implementation
of
what
happened
happens
to
be
the
important
thing
at
the
moment
and
then
maybe
for
six
months.
E
That
is
not
the
important
thing
and
they're
focused
on
Research
or
they're,
focused
on
some
other
piece
and
they're,
not
coordinating
as
closely
with
other
people
in
the
core
deaf
Community,
but
they
remain
a
core
Dev
through
that
period
of
time,
and
so
these
are
two
different
things.
From
my
vantage
point,
who
who
attends
this
meeting
and
who
is
considered
a
part
of
yeah.
A
I
think
we
just
have
a
different
perspective
or
a
vantage
point
about
like
what
we
are
trying
to
achieve
with
this
meeting
in
particular,
so
I
think
we
should
just
have
we
can
do
it
publicly
too,
but
I
don't
think.
We
should
take
too
much
time
to
deliberate
this
here,
because
we
have
40
minutes
left
in
the
meeting.
If
that's
all
right.
A
A
And
I
think
Molly
may
have
oh
you're
still
there.
Great
okay
is
that
okay.
E
Yep
yep
I'm,
trying
to
find
to
move
through
it
I
think
we
should.
We
should
again
have
a
public
definition
of
what
what
a
core
Dev
is
and
put
that
you
know
in
the
the
TPM
notion
or
TPM
repo,
but
I'm
happy
to
also,
like
you
know,
having
having
started
this
initial
group
I'm
happy
to
Define
kind
of
what
was
in
my
head
when
we
created
it
and
like
the
examples
were
pulling
from
other
from
other
networks.
A
Sure
sounds
good
Raul.
Did
you
have
a
question.
F
All
right,
I
had
a
I
had
a
thought
around
this,
but
I
don't
know
if
you
want
to
move
on.
Basically,
my
my
thought
was
I'm.
Just
gonna
like
try
to
be
very
concise,
I
would
I
would
love
it
if
the
definition
of
core
devs
would
be
centered
around
meritocracy.
F
This
is
how
it
works
in
many
other
open
source
contexts
like,
for
example,
the
Apache
software
Foundation,
where
in
general,
like
apply
to
to
the
context
of
of
a
filecoin
I,
would
expect
that
core
devs
are
actively
engaging
in
FIB
discussions.
Core
devs
are
actively
in
proposing
new
standards.
F
Core
devs
do
not
necessarily
need
to
attend
synchronous
meetings,
because
I
do
agree
with
Molly
that
you
know
the
the
attendance
to
meetings
is
going
to
vary
on
on
a
lot
of
factors,
but
in
general,
there's
a
general
expectation
that
every
core
Dev
would
review
fips
would
provide
a
stewardship,
would
provide
what
stride
discussions
proactively
and
would
just
contribute
to
evolving
the
protocol,
and
in
general
this
is
like
you
know:
it's
Broad
addending
the
definition
to
not
a
set
of
hard
rules.
F
It's
maybe
a
more
softer
a
softer
definition
that
is
kind
of
like
the
hinges
on
the
concept
of
meritocracy,
but
I
I
can
post
my
thoughts
as
well.
Async.
A
Yeah,
that's
very
valuable,
I
think
that's
the
trade-off
we
have
to
balance
is
we
want
a
group
of
experts,
but
we
also
need
to
know
when
we
have
to
make
decisions
or
ask
for
consensus
who
they
are
and
in
the
past,
when
we've
had
a
broader
definition,
we
haven't
had
that
engagement,
so
we
can
strike
a
better
balance.
We
can
do
it
publicly
appreciate
your
input,
do
want
to
move
on
real
quickly
and
make
sure
that
we
have
plenty
of
time.
A
So
a
quick
update,
Switching
gears,
but
relatedly
fill
pole
and
fib36.
There
have
been
a
couple
of
different.
You
know,
updates
asks
requests.
A
We
have
a
bunch
of
different
sort
of
stages
of
Retros
planned
right
now
we
are
working
through
planning,
an
in-person
retro
for
internal
stewards,
core
devs,
the
engineers
who
worked
on
this.
Anyone
who
was
in
that
fit
36
slack
Channel.
We
can
think
of
as
a
general
mechanism
for
me
by
internal
at
protocol
Labs
lab
week.
We
will
also
have
a
virtual
component
to
that.
So,
if
you
will
not
be
in
Lisbon
in
person,
you
can
participate.
A
We
will
have
async
feedback
surveys
for
both
internal
and
external
community
members,
and
a
lot
of
teams
have
already
been
doing
small
Retros
and
Dave
costanaro
from
the
CEO
team.
He
and
I
are
working
to
sort
of
gather
that
async
feedback
that
teams
have
generated
amongst
themselves
so
that
we
can
incorporate
that
as
well.
In
a
giant
case
study
that
the
Falcon
Foundation
is
also
writing
about
this
process.
A
A
Catalin
from
the
d-mob
team
has
already
put
together
a
technical
retro
for
the
fill
pool
tool.
If
we
decide
to
use
it
in
future
and
also
additional
guidance
for
proposing
economic
changes
after
Phil
Paul.
If
that's
been,
the
group
wants
to
do
Molly.
E
Yeah
I
think
awesome.
Thank
you
so
much
for
for
holding
all
these
retro
items-
and
you
know,
there's
really
important
work
to
be
done
here
on
the
feedback
survey
for
external
community
members.
I'm
curious
like
how
how
detailed
this
is
already
planned
to
be
because
I
think
there
is
a
subset
of
the
community.
That
feels
feels
motivation
to
continue
pushing
on
components
of
what
went
into
fit36
and
one
of
the
things
that
I
think
is
really
necessary
to
Empower.
E
That
group,
with
the
understanding
of
what
you
know,
diverse
Community,
very
different
feelings
about
what
they
did
and
didn't
like
if
we
are
to
find
something
that
is
non-controversial
that
we
can,
like
you
know,
get
behind
as
a
network
without
needing
to
go
through
this
process
again,
where
there's
like
a
lot
of
split
perspectives,
I
think
it's
really
important
to
understand
as
part
of
that
survey,
a
not
just
for
like
the
folks
who
to
look
at
the
different
subgroups
that
were
a
part
of
the
poll
and
do
like
a
deeper
dive
into
what
pieces.
E
A
So
this
one
this
is
something
that
came
as
a
request
like
from
the
foundation
side
as
well,
and
this
feedback
is
really
related
just
to
the
governance
process.
It's
not
related
to
like
assessment
of
context,
interest
area
or
like
perceived
needs
in
regards
to
economic
changes,
I
think
if
we
were
to
do
feedback
surveys
related
to
these
things,
they
should
be
separate.
The
content
and
planning
for
potentially
future
changes,
and
then
governance
process
shouldn't
be
co-located
in
this
case.
But
this
is
the
one
super
flexible
with
this
one.
A
We
wanted
to
make
sure
that
storage
providers
in
particular
had
a
way
to
air
their
thinking
and
really
just
a
way
to
share
their
thoughts
and
feedback
and
feel
heard.
So
if
you
want
to
talk
more
about
how
we
sort
of
co-locate
that
work,
that's
fine
too,.
E
Yeah
I
think
there's
a
question
of
like
yeah.
Maybe
this
is
another
thing
too
it's
not
quite
it
is.
It
is
a
it's
a
retro
in
some
ways,
but
it's
like
it's
a
retro
for
understanding
like
where
the
community
now
stands,
because
there's
a
lot
of
learning
done
over
this
period
of
time
and
I
think
people
a
lot
of
people
have
ended
up
at
different
places
than
where
they
started
out
in
terms
of
understanding
of
like
importance
of
various
different
improvements
and
so
I.
E
Don't
and
I
also,
don't
think
that
there's
consistent
visibility
say
among
the
cordovs
group
about
the
amount
of
division
or
the
amount
of
support
for
different
sub
pieces
of
this
proposal,
and
so
if,
if
we
can
do
a
good
job
reflecting
that
to
the
community,
we
can
enable
any
future
proposals
to
be
less
contentious
and
be
you
know
easier
to
to
build
on
top
of.
And
so
it
sounds
like
this
is
a
different
survey.
So
maybe
we
add
it
as
a
different
item.
E
But
if,
if
anyone
wants
to
be
involved
in
helping
make
that
happen,
I
think
it
could
be
be
pretty
valuable
for
giving
the
community
that
feedback
on
where
people
are
very
split.
A
For
sure
yeah
I
think
so
these
Retros
are
just
related
to
the
governance.
The
actual
process
I
agree
that
that
would
be
super
valuable.
If
we
can
help
coordinate,
we
can,
but
my
feedback
Focus
for
these
lectures
will
be
a
little
bit
different
and
I.
Don't
think
you
want
me
involved
in
the
second
one,
just
in
terms
of
making
sure
work
is
distributed.
A
All
right,
Molly,
you
and
I
should
just
connect
after
this
meeting.
Anyway,
it
sounds
like
so
we
can
align
on
these
things
generally.
We
do
want
to
keep
moving
forward
again
we're
about
halfway
through
the
meeting
lots
of
things
left
to
discuss
so
Jennifer.
With
that
going
to
talk
about
Network,
v17
timeline,
Etc
I
will
turn
it
over
to
you.
B
B
I
will
I
will
be
really
quick.
Let
me
17s
like
stay
on
track.
Oh,
we
just
kick
off
the
butterfly
upgrading
yesterday
we
are
so
we
are
successful
successfully
on
shark
outbreak.
In
case
you
missed
it
it'll
be
submitting.
The
name
is
the
code.
Name
is
gonna,
be
shark.
We
are
all
shark
on
butterfly.
We
started
to
do
some
like
the
early
testing.
The
migration
is
going
well.
The
notice
for
the
longest
team
today
is
like
merge
day.
B
We
are
planning
to
merge
a
lot
of
the
Golden
State
type
changes
a
and
working
towards
that
our
like
early
stage,
RC
one
to
make
sure
everything
looks
good
from
the
gold
part
of
the
things.
I
need
to
sync
up
with
Forest
on
how
things
going
on
in
d70,
but
the
early
timeline
here,
I'm
gonna
share
my
screen.
Really
quick.
Everyone
got
got
to
look
at
my
very,
but
it's
by
the
way
everything
is
public
in
a
lot
of
the
project
board
is
in
the
file.
B
Queen
GitHub
Ripple
is
also
like
public,
but
from
our
side
of
the
things
we
are
planning
to
do.
The
first
rc
of
lotus
v118
serial
next
Thursday
October,
the
13th
and
the
calibration
upgrade
is
scheduled
a
week
later,
which
is
the
b27s.
The
butterfly
testing
is
going
to
last
a
week
and
a
half
from
now
on
to
make
sure
we
don't
work
the
calibration
upgrade
and
then
the
calibration
upgrade
is
going
to
last
for
about
like
three
weeks
and
the
minute
upgrade
will
be
on
the
November,
the
10th.
Any
questions.
B
C
B
I
agree
this
date
wrong,
sorry,
20
days,
but
yeah
any
concerns
and
stuff
I
mostly
want
to
hear
from
the
forest
because,
like
I
know
like
for
you,
it's
mostly
just
make
sure
the
migration
goes
well
and
updating
the
first
note:
you
don't
have
much
like
minor
set
of
interpretation
to
do,
but
so
any
concerts.
D
I
think
it
sounds
sounds
good,
like
we
would
love
to
like
be
able
to
test
on
on
butterfly
net.
But
if
that's
not
possible,
then
like
we
can,
we
can
make
it
work
on
like
just
testing
with
with
calibration
net.
C
Yeah,
absolutely
so
long
as
it's
easy
to
add
a
new
network
for
y'all.
That
should
be
too
fun
the
one
the
one
thing
I
will
flag,
which
will
be
a
decent
amount
of
work,
for
you.
Folks
is
the
migration
itself,
because
that
doesn't
happen
in
the
fem,
so
that
does
need
to
get
implemented.
C
B
It's
the
forest
team
need.
We
can
do
it
early
call
next
week
that
you
show
you
about
migration,
we're
doing
on
the
Go
Side
to
keep
to
catch
you
up
as
well.
G
D
B
That
sounds
good.
Do
I
risk
that
I'm
staying
out
in
the
17
years,
the
the?
Where
do
you
have
week
in
two
weeks
many
of
us
were
being
listed.
That's
why
we're
trying
to
wrap
up
all
the
developer
engineering
effort
before
the
last
week.
So
during
the
library,
the
only
thing
we
should
be
doing
is
monitoring
the
calibration,
hopefully
in
a
single,
strong
and
push
the
button
of
the
federal
release
uploaders,
but
so
far
from
casting
this
looks
on
trackers,
but
that's
pretty
much
it
Shameless
plugin.
B
We
are
hosting
a
low
distance
brand
Summit
on
November,
the
second
English
class.
Well,
if
you
are,
there
do
talk
to
us.
We
can
sing
about
shark
as
well.
A
Thank
you
Jennifer
and
sorry,
if
I
missed
it,
but
when
will
the
shark
upgrade
schedule
be
released
publicly
today.
A
All
right,
I'm
surprised
we
moved
through
that
so
quickly,
all
right!
Well
then
Steph!
It's
over
to
you
back
to
our
scheduled
programming,
less
updates
of
the
proposal
on
the
F4
address
class
Step.
You
should
be
able
to
share
your
screen
if
you
want
to.
D
C
H
H
Basically,
this
proposal
here
is
to
add
an
extensible
addressing
system
where
users
can
add
new
actors
to
the
chain
to
extend
the
existing
pressing
system
without
having
to
get
everyone
to
agree
on
that
extension,
a
person
background
here.
The
current
address
classes
are
one
two
and
three
or
sorry:
zero,
zero.
One.
Three
and
two
and
someone
asked
a
question.
H
So
yeah
yeah,
so
the
current
address
classes
are
zero.
One
three
and
two
zero
is
the
ID
address
class.
This
is
kind
of
like
what
we
use
on
chain
for
really
really
short
representations
of
addresses.
These
are
not
predictable.
You
can't
know
your
idea
ahead
of
time
and
they're,
not
where
you're
stable.
They
change.
If
you
give
the
change
of
your
orgs
or
if
messages
get
reorder
or
whatever
happens
there,
we
also
have
these
count
Keys.
These
are
derived
from
public
key
material.
H
These
are
larger,
they're,
21
or
49
bytes,
depending
which
one
you
use.
They
are
predictable,
which
is
really
nice.
It
means
I
can
take
a
a
a
key
locally
predict.
The
address
I'll
have
on
chain
and
I
could
even
use
this
address
ahead
of
time
without
actually
having
to
create
the
account
and
as
long
as
once,
someone
sends
funds
to
it.
They
can't
just
magically
starts
existing,
so
this
is
really
useful.
H
You
can
just
kind
of
generate
more
and
more
keys
locally,
and
you
basically
have
accounts
that
you
just
haven't
been
reflected
on
the
Chain.
Yet
it
doesn't
matter
what
happens.
Okay,
I
might
have
gotten
the
number
bytes
wrong
yeah,
so
the
the
stable
across
the
orgs,
the
final
type,
is
the
the
sort
of
stable
actor
address.
This
is
F2.
These
addresses
are
assigned
to
actors
when
you
deploy
code
to
the
actor
or
code
bearing
actors,
specifically
they're,
not
predictable.
I
can't
know
ahead
of
time.
H
What
like
an
actor's
address
will
be
until
I
create
the
message
that
creates
the
actor.
However,
once
I've
created
the
message
that
creates
the
actor,
that
actor
will
always
have
the
same
address.
H
The
really
nice
property
about
this
is
it
means
I
can
I
can
make
one
message
and
then
based
on
that
message,
I
can
make
another
message
and
then
I
can
make
another
message,
and
then
I
can
actually
sort
of
string
these
messages
together
and
know
that,
like
the
the
second
message,
will
always
refer
to
the
first
message
Etc,
so
it
lets
me
send
a
sequence
of
messages
from
my
account.
They,
like
will
always
refer
to
like
the
correct
actor.
If
something
goes
wrong
anywhere
in
this
chain.
H
Worst
that
will
happen.
Is
that
actor
won't
exist?
No
one
else
will
be
able
to
just
take
that
address
and
take
my
money
yeah.
So
this
is
some
really.
The
point
of
F2
addresses
it's
a
bit
of
background
there,
okay.
So
what
we
needed,
though,
was
kind
of
a
new
address
class
that
supported
both
interactions
with
actors
as
code
bearing
actors.
They
don't
yet
exist
on
chain.
We
need
this
people
to
act.
One
contractional.
This
is
a
phrase
you'll
see
in
ethereum.
H
You
don't
see
very
much
against
one
yet,
but
the
counterfactual
interactions
are
really
important
for
for
payment
channels.
Basically,
what
this
means
is
like
I
need
to
be
able
to
talk
about
an
address
off
chain.
I
might
email,
people
I
might
even
need
to
be
able
to
refer
to
it
in
like
a
payment
channel
voucher
somewhere
in
this
address,
may
not
ever
actually
be
relevant
on
chain,
but
I
need
to
be
able
to
like
this.
H
We
talk
about
an
actor
that
could
exist
on
chain
at
some
point
and
know
where
it
will
exist
if
it
does
exist
yeah.
So
this
is
this
is
the
point
of
predictable
aggressing
or
basically,
I
can,
like
think
of
an
actor
I,
can
sort
of
think
about
how
to
construct
this
actor
and
then
a
good
locally
construct.
The
address
that
would
exist
on
chain.
H
Then
it
could
talk
about
addressing
consent,
funds
the
address
and
do
whatever
I
want
with
it
and
eventually,
if
I
want
to
I,
can
put
in
a
champ
I
don't
actually
have
to.
The
second
thing
we
really
need
is
foreign
addressing
schemes,
so
the
fev
I'm.
This
is
really
the
the
original
point
of
this
proposal.
It
needs
a
way
to
use
ethereum
style
addressing
within
PowerPoint,
basically
like.
We
need
to
be
able
to
compute
account,
addresses
and
really
don't
know
ethereum.
So
we
have
compatibility
with
ethereum
tooling.
H
We
all
seem
to
be
able
to
do
the
same
thing
for
actors
because
like
if
you
have
an
actor
or
sorry,
if
you
have
a
ethereum
style
contract,
an
evm
contract
on
chain,
and
it
calls
like
the
create
to
ethereum
up
code.
H
It
expects
the
address
that
comes
back
to
come
back
in
a
very
specific
format
to
be
derived
in
a
very
specific
way
from
the
init
code
and
the
Constructor
parameters,
all
this
kind
of
stuff,
and
if
it's
not
a
lot
of
the
ecosystem,
which
is
break
so
we
need
some
way
of
sort
of
like
embedding
ethereum
style
addresses
and
popcorn
style
addresses
and
ideally,
we'd
have
some
way
of
going
backwards.
H
So
that's
what
I'm
trying
to
get
across
here
where,
like
ideally
if
having
ethereum
address,
is
0x1234
I
would
be
able
to
send
them
had
this
in
some
kind
of
file
pin
address
that
has
one
two
three
four
somewhere
in
it
same
thing.
The
other
round
I'd,
ideally
be
able
to
go
from
this
style
of
output.
Address
back
to
the
theorem
address.
H
Just
it's
not
actually
required,
but
it
makes
it
really
nice
for
tooling,
because
it
means
the
tooling
to
like
look
at
a
five-point
actor
somewhere
and
say
I
know
this
is
an
ethereum
style
address,
embedded
in
a
51
cell
address,
so
yeah.
That's
the
goal
here.
Another
bonus
goal
is
we
never
want
to
have
this
discussion
again?
So
I
want
to
make
a
system
where
we
can
just
keep
on
extending
building
on
it
without
having
to
like
go
back
and
and
like
add
an
address
class
right
now.
H
H
So
it's
better
to
sort
of
make
lift
this
into
a
user
programmable
position
right
now,
so
that
users
can
just
extend
it
and
add
more
systems
to
it.
Otherwise,
like
like,
like
we'll
kind
of
have
to
get
everyone
to
agree
on.
Yes,
we
want
this
new
thing
and
that's
just
hard
to
do
so.
Those
that's
kind
of
the
background
of
the
goals.
Does
anyone
have
any
questions
before
I
move
on
to
the
specifics
of
like
the
F4
proposal?
H
Nope?
Okay,
so
the
high
level
proposal
is
yeah.
We
want
to
use
our
extensible
address
class
really
where
actors
on
chain
can
assign
addresses
from
within
some
subclass
within
the
stress
class.
So
concretely,
some
user
definable
actor
called
address
manager
with
in
this
example,
an
idea
one
two
three
would
be
able
to
assign
F4
addresses,
starting
with
f4123f.
H
H
Sorry
an
example
address
is
f4123
f,
a
three
four,
whatever
whatever
that's
just
an
arbitrary
dress
chosen
by
by
that
actor,
and
while
we
ask
if
there's
any
security
concerns
about
I,
think
links
this.
This
proposal
has
a
maximum
length
or
basically
it
it
states
that
the
maximum
length
of
the
of
the
actual
address
is
54
or
sorry.
The
sub
address
is
54.
To
give
us
a
maximum
total
address
size
of
64..
H
The
current
largest
address
is
smaller
than
that
I
think
it's
like
50,
something
bytes
vertical
correctly
or
40.
Something
bytes
I
can't
remember:
I
have
to
go
back
and
look
so
this
will
make
it
slightly
larger,
but
64
still
fits
pretty
well
within
most
systems
and
it's
large
enough
to
allow
users
to
basically
put
in
some
32
byte
ax
or
something
like
that,
and
then
they
get
a
few
extra
bites
to
store
whatever
else
they
need
yeah.
That's
the
idea.
H
Okay,
the
components
of
this
proposal,
three
main
components,
one,
the
F
Bar
address
class
that
we
just
saw
to
a
concept
of
embryo
actors.
This
is
a
like
a
way
to
be
able
to
send
to
an
address
before
it's
actually
an
active
deploy.
There
we've
deployed
there.
We
need
to
put
something
there.
So
the
idea
is
you
put
a
quote-unquote
embryo
in
that
position
and
then,
finally,
this
new
method
on
the
unit
actor
called
exit
four.
H
This
is
basically
how
you
would
create
an
actor
that
has
a
class
4
address
so
first
part
the
class
four
address,
and
now
I'm
going
to
be
specific
and
Define
exactly
what
this
is
its
interest.
It
starts
with
four
as
class
then
has
a
Leb
128.
This
is
a
variant
address,
management,
actor
ID.
So,
basically
take
you
take
the
actor
ID
of
the
address
manager.
The
actor
is
assigning
the
address
encoded
as
a
parent
and
tacked
that
on
and
then
finally,
you
append
the
sub
address.
H
The
textbook
format
is
is
basically
just
a
coding
of
this.
It
starts
with
F4.
Then
it
has
the
decimal
encoded
actor
ID.
We
chose
to
to
have
a
decimal
code
adverty,
so
you
could
quickly
look
at
an
F0
address,
look
at
an
F4
address
and
determine
that.
Yes,
these,
like
this
F
sorry,
this
actor
with
zero
address
is
control
and
F4
subclass
separated
Again
by
f
Then,
followed
by
the
base
32
encoding
of
the
sub
address,
followed
by
checksum
this.
H
The
second
this
last
part
here
is
like
is
the
same
way.
We
do
our
all
of
our
F1
through
F3,
addressing
where
basically
we'll
take
the
the
actual
address
attack
on
a
check.
Some
checks
I'm
still
a
four
byte
checksum
over
the
the
rest
of
the
address.
Then
we
basically
to
encode
it
to
make
it
sure
it's
not
too
big,
but
it's
also
case
insensitive.
It's
an
URL
all
this
kind
of
stuff.
H
If
you're
wondering
what
we
chose
F4
decimal
than
F,
this
is
suggestion
by
Magic
and
Juan
initially
had
proposed
actually
a
dash
here.
Unfortunately,
it
turns
out
that
you
can't
double
click
and
select
everything
with
a
dash
level
of
it.
This
is
really
important
for
Mobile
use
cases
and
stuff,
like
that,
so
it
had
some
ux
problems,
So
currently
I'm,
posing
at
FDR,
because
you
kind
of
get
this
mirror
between
the
off
and
the
F.
H
You
can
see
F4
some
number
F
and
it's
it's
reasonably
clear,
it's
not
as
readable
as
a
dash,
but
it
it's
it's
easy
enough
to
just
see
like
or
you
could
at
least
tell
which
actor
created
this
address,
which
should
be
someone
usable
that
we
we're
hoping
that
the
tooling
will
make
this
even
easier,
but
we
still
won't
be
able
to
look
at
at
a
glance.
H
Okay,
exit
four
is
how
we
then
actually
create
actors
of
the
dress.
Basically,
it's
like
the
exact
param,
so
if
you've
ever
seen
the
exec
method
on
the
internet
actor,
it's
exactly
like
that,
except
the
radical
sub
address
fields
of
this.
H
In
the
sub
address
field,
the
the
calling
actor
can
specify
the
the
the
calling
actor
can
specify
the
sub
address
of
that
they
want
to
assign
to
this
new
active
they
are
creating
then,
and
then
the
full
computed
F4
address
would
include
the
sub
address,
start
with
a
zero
and
then
have
the
the
the
the
creating
actors
or
the
the
address
management
actors
ID
in
the
middle.
So
that's
where
you
get
at
the
end
there
and
rules
asking
if
the
F
would
appear
in
test
Nets.
H
My
plan
is
to
say
no.
That
would
be
somebody
consistent
with
test
Nets,
but
I.
Don't
really
care
too
much
about
that.
It
is
something
unfortunate
we
could
use
another
separator
here.
I
did
also
with
underscore
but
underscores,
are
kind
of
ugly
and
really
hard
to
type
on
mobile
phones
that
we
consider
other
things,
but
we're
somewhat
limited
on
our
choices
here.
H
So
I'd
be
happy
to
take
additional
suggestions,
but
we
can
talk
about
that
later
or
actually
really.
Just
if
you
have
a
suggestion,
there
make
a
comment
on
the
discussion.
It's
the
best
way
to
do
it.
Okay.
Finally,
the
embryo
embryo
is
just
like
it's
basically
a
prototype
actor,
so
it's
a
way
to
create
an
actor
that
has
technically
has
a
code.
Cid
is
embryo
code
CID,
but
the
embryo
code
CID,
the
embryo,
doesn't
do
anything.
H
It
rejects
all
all
non-methoded
zero
sentence,
so
basically
it
only
accepts
funds,
and
importantly,
it
is
recognized
by
the
FM.
So
if
you
try
to
call
exit
four
on
some
new
code,
the
fbm
will
be
willing
to
replace
an
embryo
code
CID
with
your
new
coaching
ID,
usually
exec
and
exit
four
will
not
like
you'll.
That's
not
gonna
like
replace
the
code
of
an
existing
actor.
This
is
the
one
case
where
exec4
will
actually
replace
the
code
of
this
actor.
H
H
So,
finally,
wrapping
this
up
some
use
cases
we're
trying
to
Target
here
one
is
predictable,
addressing
counter
factuals.
This
is
already
talked
about.
Basically,
the
system
lets
users
sort
of
deploy
and
Define
arbitrary
addressing
systems,
so
they
can
basically
enforce
arbitrary
constraints.
Here
you
can
do
some
cool
things
here.
H
One
you
can,
for
example,
like
ahead
of
time,
I
compute
the
address
from
an
actress
code
plus
parameters,
and
that
means
I
can
kind
of
like
I
can
bind
to
class
addresses
to
All
actors
that
are
constructed
with
specific
code
parameters.
I
can
even
like
Define
I
can
add
additional
things
here.
We
can
say
well
code
parameters
and
origin,
but
like
I
mix
the
origin
into
this
address,
so
that,
like
everyone,
sort
of
get
their
own
copy
of
the
actor,
you
can
even
do
weird.
H
Things
like
like
include
constraints
on
epochs.
So,
for
example,
like
I
can
I
can
define
an
a
an
address
management
actor
that
like
looks
at
the
sort
of
like
a
requested.
H
Epoch
constraint,
validates
it
like
you're
between
between
two
requested
epochs
they're,
like
hashes,
some
statement
that
describes
that
it
creates
an
address
from
that.
That
would
let
you
basically
have
like
specific
addresses
that
can
only
be
deployed
between
some
set
of
epochs,
which
could
be
really
useful
for
like
time
to
lay
things
lockups
that
kind
of
stuff
and
you
can
actually
enforce.
This
is
entirely
within
the
addressing
system
and
like
be
like
basically
look
at
the
address
and
know
from
the
address
of
it
like.
H
This
is
the
guarantee
you
have
the
the
other,
but
again
the
main
goal
that
I
had
personally
was
for
addressing
schemes
like
the
fbm.
The
system
lets
us
completely
embed
foreign
dresses
within
the
the
within
normal
files.
One
addresses
so
it
typically
solves
that
problem.
H
Yeah
I
know
I,
spoke
very
quickly.
There
I'm,
hoping
people
understood
what
I
was
trying
to
get
across
what
questions
people
have
any
discussions
comments.
A
Thanks
Steven
I
think
there
were
two
pretty
good
questions
in
the
chat.
The
first
one
is
Molly,
any
security
concerns
re-addresses,
potentially
getting
reordered
or
squatted
by
users
in
unpredictable
ways.
H
Oh
okay,
sorry
I
misread
the
question
I.
So
yes,
actually,
so
this
is
a
like.
These
addresses
are
user
definable,
so
the
New
York
properties
will
be
up
to
the
actor.
This
is
actually
why
we
have
like
the
current
proposal
actually
does
not
propose
to
replace
F2.
So
whenever
you
deploy
an
actor,
if
you
deploy
using
the
current
exec
method,
you
will
get
only
an
fto
address
if
you
deploy
with
the
exit
four
method,
you'll
get
to
address,
you'll
get
an
F2
and
an
F4.
H
So
this
means
that,
like
tooling,
that
needs
reorg
stable.
Addressing
we'll
use
F2
addresses
if
you
need
the
other
guarantees
of
f4
use.
The
F4
address
many
f
word:
draft
classes
will
also
just
happen
to
be
New,
York
Stable,
but
that's
not
guaranteed.
H
You
could
have
similar
to
some
kind
of
race
somewhere,
where,
like
two
parties,
try
to
deploy
something
and
one
party
wins
and
because
of
like
how
this
this
addressing
system
like
sorry,
because
of
how,
like
that
specific
address
management
actor
assigns
addresses,
it
could
assign
two
different
addresses
across
every
yard.
There's
isn't
really
a
great
way
for
us
to
enforce
that.
These
are
actually
Bjork
stable.
That's
why
we're
keeping
the
F2
addresses
here.
A
H
Yeah,
so
probably
not,
that
was
not
my
plan.
That
is
actually
a
very
good
question
and
we
really
should
discuss
more
about
like
what
we
actually
want
to
put
there
I
just
updated
this
post
last
night
to
use
an
F
instead
of
a
dash,
because
the
dashes
is
clear
out.
It's
not
going
to
work
f
is
is
kind
of
the
best
option
we
have
right
now,
but
please,
like
just
follow
up
on
the
the
discussion
page
and
ask
questions
there.
H
Yeah
so
basically
in
the
fvm,
you
can
send
to
any
address
any
arbitrary
address
and
it
will
just
sort
of
create
an
active
with
no
code
there.
It's
actually
it's
even
more
complicated
than
that.
So
like
not
only
could
an
actor
exist
there,
an
account
could
exist
there
and
there's
no
way
to
know
ahead
of
time.
H
This
is
actually
one
of
the
the
goals
and
one
of
the
motivations
for
this
F4
address
class
was
that
we
not
only
need
to
be
able
to
like
out
of
an
arbitrary
actor
it's
in
some
Target
address.
We
need
to
be
able
to
not
even
know
what
type
of
actor
that
is
until
later
on
when
it's
actually
deployed
so
so
yeah.
We
need
to
be
able
to
be
able
to
process
sentence
like
this.
We
considered
a
bunch
of
Alternatives
some
of
the
terms.
H
We
also
did
not
write
up
in
the
fit
because
they
were
very,
very
EDM
specific,
but
one
was,
for
example,
to
have
like
an
on-chain
registry
of
like
pending
funds,
we're
basically
like,
if
and
fevm
account
sorry
ethem
actor
even
contract
on
PowerPoint
sent
to
some
ethium
address,
and
we
couldn't
find
that
within.
Like
the
five
point
system,
we
would
hold
it
in
some
evm
specific
holding
Zone
and
only
release
it
once
an
actor
actually
gets
created.
H
We
did
not
want
to
go
with
that
approach
because
it
makes
it
really
hard
for
chain
explorers.
It's
really
confusing
for
users,
it's
really
complicated
and
yeah.
It's
just
really
complicated.
So
that's
why
we
would
like
some
way
to
actually
hold
these
in
a
real
actors
on
chain.
H
We
we
can
all
like
I'm,
also
happy
to
discuss
not
having
embryos,
but
instead
automatically
deploying
a
specific
code.
Cid
these
actors,
I,
don't
think
that'll
work
in
all
cases
by
it
technically
does
work
for
for
for
the
febm
case,
but
I
think
like
like
other
counterfactual
cases,
would
really
like
to
sort
of
have
a
generic
embryo
deploy
here.
G
Yeah
thanks
I
think
just
to
to
make
sure
I
fully
get
it.
So
there
are
these
two
properties,
there's
the
counter
factuals
and
there's
the
foreign
addressing
thing,
but
we
need
the
counter
factuals,
because
the
evm
requires
it.
So
you
could
have.
This
will
support
some
not
like.
If
you
just
had
the
foreign
addressing
part,
you
could
support
some
other
foreign
address
scheme
which
didn't
need
manufactuals.
Okay,
yes,.
H
Yeah,
but
no
I
also
want
to
be
careful
about
using
the
working
on
Rock
Tools.
So
I
put
it
here
because
we've
talked
about
it
a
lot
in
those
kind
of
practicals,
the
more
I
read
on
this,
the
more
I
realize
it's,
not
the
right
term,
the
correct
way
of
phrasing.
This
is
like
actors
or
basically
addresses
that
do
not
yet
exist
on
chain.
It's
a
really
wordy
phrase,
but
it's
the
correct
way
of
doing
it.
H
H
Contractual
interaction
basically
means
like
I,
can
talk
about
these
dresses
off
chain
like
in
payment
channels
and
stuff
like
that
in
vouchers
or
whatever,
and
it's
as
if
they
really
existed
on
a
chain,
but
they
never
actually
have
to
exist
so
like
we
can
go
back
and
forth,
like
basically
in
our
minds,
create
all
these
actors
that
it
might
exist,
but
but
they
don't
and
it's
as
if
we
went
through
all
the
process
of
creating
them,
but
they
never
actually
have
to
exist.
So
you
can.
H
You
can
actually
like
basically
save
a
lot
of
of
gas
and
make
really
cool
systems
that
don't
have
to
necessarily
interact
with
the
Chain
by
basically
doing
a
lot
of
off-chin
operations
right
kind
of
passing
back
into
saying.
Well,
I
could
do
this,
but
I'm
not
going
to,
and
then
you
you
say
well,
because
you
could
do
that.
I
could
do
this,
but
I'm
not
going
to
and
we
can
kind
of
go
back
and
forth
like
talking
in
the
contractional.
It's
really
cool.
G
H
H
H
Deploying
this
wallet
is
expensive,
so,
instead
of
deploying
the
wall
and
getting
addressed
and
keeping
the
address
instead,
I
just
give
you
an
address
where
the
wall
would
be
deployed
if
I
deploy
them
now,
if
you
decide
to
actually
send
funds
to
that
address,
then
I
can
deploy
the
wallet
and
claim
the
funds.
H
This
is
useful,
for
example,
for
like
for
like
exchanges
for
like
or
merchants
or
whatever,
but
like
they
just
need
to
be
able
to
like
very
quickly
just
like
give
you
an
address
to
send
your
funds
to
for
like
a
sale
or
something
like
that,
but
they
don't
have
to
spend
any
money
to
create
that
address.
This
kind
of
system
lets
them
just
create
the
address.
H
So
just
to
know
like
this
is
this
is
the
same
thing
we
can
do
currently
with
accounts
with
F1
and
F3.
This
extends
this
to
arbitrary
musicified
doctors,
basically
yeah,
where
the
difference
with
F1
F3
is
that
we
don't
deploy
embryo,
we
deploy
the
specific
actor,
because
we
know
exactly
what
type
of
act
will
be
there
from
the
the
the
address
type.
In
this
case
we
don't
know
the
exact
type
of
actor
I'm.
Actually,
like
I,
have
my
head
a
future
proposal
to
allow
the
address
management
actor
to
specify
an
actor.
H
That
is
not
the
embryo
actor
that
should
be
deployed
on
send,
but
that's
a
future
thing
that
is
not
critical.
This
proposal
here
so
I,
don't
want
to
mix
them
up
too
much
foreign.
A
Thanks
Deb,
thank
you.
Yeah.
A
You
can
also,
if,
if
not,
you
can
leave
your
screen
up
too
I
think
we're
at
the
end
of
the
meeting.
If
there's
any
other
questions
for
step,
but
we
did
link
a
few
chats
up
the
link
in
the
fips
repo
to
the
draft
we'll
merge
this
today.
It
will
still
be
there
so
that
you
can
review
it.
Add
comments,
questions,
Etc
and
lucky.
It
would
be
great
if
you
could
flag
this
one,
in
particular,
in
this
week's
governance
update,
so
that
folks
can
find
it
pretty
easily
as
well.
A
We
have
only
a
couple
of
minutes
left.
Usually
we
have
q,
a
Jennifer
I.
Think
you
messaged
me:
you
quickly
want
to
flag
something
for
folks.
B
So,
as
we
are
shipping
out
on
this
Eventing
I
want
to
I
started
a
new
discussion
in
the
TPM
repository
to
start,
like
talking
about
to
for
people
to
raise
ideas
for
what's
the
next
Network
outbreak,
gonna
be
I,
know
like
the
product
team
was
kind
of
like
in
consensus
like
three
months
ago
that
if
mv18
it's
been
a
period
about
if
evm
and
2.1
launched
into
the
file
Queen
Network,
which
is
projected
At
a
next
year
of
February
I,
just
want
to
make
sure
that
we
are
still
agreeing
on
that.
B
If
not
what's
the
other
options,
what
do
you
have
any
other
higher
priority
that
we
have
to
ship
sooner?
I
think
we
have
to.
We
don't
have
time
today,
but,
like
we
I
think
we
should
start
discussion
so
much
Brother
Sam
later,
because
if
we
want
to
change
the
scope
or
change
the
timeline,
we
have
to
start
like
planning
accordingly.
Already
we
do
have
that
five
minutes.
So
if
there's
any
like
quick
comments,
people
should
like
race.
B
C
I'm
personally
continuing
to
work
on
the
assumption
that
yeah,
the
fpvm
will
be
the
next
Network
upgrade
I.
Don't
think
I,
don't
know
how
many
trips
we
have
opened
that
how
many
Feb
one
related
fips
we
have
open
that
are,
you
know
close
to
being
ready
that
we
can
have
a
conversation
of
whether
or
not
we
want
to
include
prefer
to
not
include
but
yeah.
Nothing,
not
much
has
changed
for
me.
B
That's
a
very
good
point
like
I
want
to
call
out,
or
we
we
also
reach
our
constances
just
like
if
we
are
doing
a
copyright
for
a
Feb
and
that
operation
only
contain
that
flips
that
needed
for
every
VM
launch
and
it's
a
secure,
operated.
D
Yeah
yeah
I
I
agree
with
all
those
like
description
of
previous
agreements
that
we've
made,
but
I
I.
Thanks
for
having
a
discussion,
we
can
do
most
of
it,
I
think,
but
I
think
we
definitely
should
open
discussion
about
the
opportunity
to
make
some
crypto
economic
changes
in
in
lieu
of
36
something
simpler,
faster.
You
know
more
easily
accepted.
I,
definitely
think
we
should
make
space
for
that,
because
you
know
the
problems
that
that
Professor
was
going
after
are
real
and
it
would
be.
D
You
know
we
either
decides
the
you
know.
Network
upgrade
well,
not
exactly
I,
guess,
because
Caitlyn
just
to
find
that
that
we
don't
but
I
think
implementers
should
be
open
to
us
making
space
for
something
sufficiently
small
and
simple.
If
it's
targeting
those
same
problems
as
long
as
we
can
avoid
threatening
the
the
fvm
timeline
too
much,
it
would
be
handy
to
get
an
update
on
the
fbm's
projections.
I
guess
maybe
in
that
thread,
to
help
us
understand
what
space
exists.
D
As
you
know,
things
get
more
and
more
clear,
but
you
know
this
group
has,
as
the
you
know,
as
we
shouldn't
lock
ourselves
into
our
own
previous
decisions,
where
there
were
decisions
we
made,
we
have
the
scope
to
change
them
for
the
future.
We're
opening
that
discussion,
I've.
B
Already
seen
a
couple
like
tips
that
be
opened
up,
like
as
a
follow-up
of
Feb
36
I,
will
encourage
everyone
in
this
group.
To
start
like
async
conversation
are
like
the
motivation,
The
Power
Team.
The
urgency
for
like
related
challenges,
that's
needed
for
the
network.
We
can
move
it
to
async
I.
Would
love
to
lucky?
I
would
love
to
propose
that
for
the
next
quarter
in
November
we
can
have
like
two
agenda
items
on
the
call
versus
get
getting
a
new
update
from
like
fvm
team.
On
the
projected
timeline
engineering
updates.
B
A
This
sounds
really
good.
I
think
there
were
lots
of
ideas
and
open
threads
open
during
this
conversation,
so
Raul
as
follow-up.
We
will
sort
of
segment
out
steps
presentation
so
that
that
is
individually
accessible
to
everyone
on
YouTube
I'll
also
write
us
up
a
summary
in
the
core
devs
Channel,
with
links
to
FIB
drafts,
not
just
steps,
but
also
the
ones
that
Jennifer
is
mentioning
the
planning
thread.
A
Thank
you
everyone
for
your
contributions
today
again,
it
is
great
to
see
this
meeting
continue
to
grow,
even
as
we
have
lots
and
lots
of
big
questions
to
work
through
I
think
everyone
has
another
meeting
the
ecosystem
all
hands
right
now,
so
I'll,
let
you
all
go
but
see
you
all
soon
and
talk
to
you
probably
even
sooner
bye.
Thank
you.