►
Description
The EOS Node Operator Roundtable meets every Wednesday at 14:00 UTC to share and discuss feedback to improve the Antelope protocol.
Timestamps
00:00:00 Welcome
00:00:35 Update on Leap Upgrade
00:03:01 Greymass & Request for Permission
00:31:04 Fivdata (non updates)
00:34:10 Greymass & Request Permission
00:47:45 NodeOS & Packaging Configuration Management App
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
A
B
All
right,
thank
you,
Daniel,
good
morning,
good
afternoon,
good
night.
This
is
my
new
greeting
these
days
because
of
the
global
nature
of
nude
operators
and
people
who
crazy
people
who
join
this
call
at,
like
you
know,
midnighter
or
things
of
that
nature,
but
to
kick
this
off
I'll,
give
a
quick
update
on
a
leap
upgrade
and
then
we'll
do
some
some
topic
Gathering
to
to
see
what
the
main
folks
of
today's
call
will
be
so
or
today,
which
is
July
12th.
B
C
B
Yeah
now
so
these
are
these
releases
all
contain
a
fix
for
a
security
vulnerability,
and
so
we
do
suggest
that
that
security
vulnerability
affects
all
nodes.
So
we
do
suggest
that
all
node
operators
of
any
kind,
whether
you're
a
block
producer
or
a
running
API
nodes
or
State
history,
nodes
or
whatever,
to
upgrade
to
these
versions
at
their
earliest
possibility.
B
In
addition
to
a
fix
for
a
vulnerability,
there
are
other
backboarded
bug
fixes
in
those
and,
of
course,
the
release.
Notes
on
GitHub
in
the
Antelope
leap
repository
go
into
detail
on
on
what
those
different
fixes
are
so
you're
getting
some
stability
fixes
and
a
critical
vulnerability
fix
as
well
so
upgrade
today.
B
D
We
have
on
the
wharf
weekly
calls
gray
mass
is
planning
to
put
effort
into
a
feature,
they
called
request
for
permission
and
that
will
allow
Wharf,
which
is
meant
to
replace,
replace
eosgs
among
the
ual
and
other
things.
It
will
allow
it
to
create
a
private
key
locally
in
the
front
end
or
back
end,
wherever
Wharf
is
being
used
and
then
request
from
anchor
or
other
wallets.
That
will
Implement
that
feature
to
create
a
new
permission
for
the
user.
D
Of
course,
he
needs
to
accept
it
and
assign
that
permission
to
different
actions
in
different
contracts,
and
that
will
allow
without
allow
like
dabs,
especially
games,
to
have
a
seamless
experience
when
they're
playing
a
game.
So
say
you
have
a
game
and
you
need
to
do
a
lot
of
actions
when
you're
playing
a
game.
You
don't
want
to
get
out
of
the
immersion.
So
if
you
have
to
click
a
button
and
then
you're
out
into
anchor
it's
an
issue.
So
how
can
this
be
tackled?
D
Leveraging
Antelope
features
is:
is
this
a
request
for
custom
permission
now?
One
thing
I
was
thinking
about
is
this
can
all
be
implemented
without
any
changes?
Of
course
to
to
you,
know,
Theos
or
deep,
but
I
do
have
a
feature
request
if
it's
possible
to
do
in
a
timely
manner,
of
course,
for
maybe
5.0
is
to
add
an
expiry
option
for
permissions
kind
of
how
we
have
the
weight
option,
but
kind
of
the
opposite.
B
D
D
B
B
B
I
think
there
are
some
folks
who
are
not
on
the
call
today
who
have
had
some
concerns
about
that
that
I
probably
won't
represent
well,
but
just
know
that
some
of
the
core
developers
have
discussed
this,
and
there
are
some
concerns
around
implementing
an
expiry
option,
but
it
is
an
option
that
we
have
considered
and
potentially
could
roll
with
some
competing
options
that
have
also
been
discussed
around.
This
are
implementing
a
standard
for
off-chain
authorizations.
E
B
And
then
a
variation
on
that,
that's
even
more
specific
that
we've
discussed
is
baking
some
of
these
things
into
into
like
a
token
standard
proposal,
or
something
like
that.
So
in
other
words
the
the
the
token
standard
itself,
let's
say,
for
example,
it's
it's
like
you
know
for
crypto
tokens
right.
So
it's
we're
talking
about
balances
and
things
like
that
right
that
you
could
apply
the
same
concept
to
things
that
aren't
crypto
tokens
like
you
know,
nft
contracts,
or
you
know
things
of
that
nature.
B
So
going
back
to
the
the
you
know,
cryptocurrency
token
sort
of
standard.
You
can
imagine
the
the
the
contract
itself
being
smart
enough
to
allow
you
to
set
very
detailed
application.
Specific
permissions
like
well
I
want
this
sort
of
sub
wallet.
If
you
will
to
only
be
able
to
be
withdrawn
by
this
account
and
I
only
want
it
to
be
withdrawn.
At
a
rate
of
you
know,
X
tokens
per
period,
whatever
period.
C
B
Right,
etc,
etc.
Right
so,
in
other
words,
moving
to
implementing
standards
for
the
most
commonly
needed
use
cases
that
are
more
application
specific
in
nature,
and,
of
course,
none
of
these
things
are
necessarily
mutually
exclusive.
Concepts,
so,
like
the
answer,
might
be
some
combination
of
those
things.
D
And
I
think
they
serve
a
bit
of
a
different
purpose,
there's
some
overlap
for
sure,
but
they
might
serve
a
different
purpose
like
having
the
smart
contract.
Do
it
versus
right?
What
we're
trying
to
achieve
with
this
feature
is
effectively
safer,
whitelisting,
as
in
you
know,
in
Scatter
you
had
white
listing
before
yeah,
but
this
is
more
of
like.
C
D
At
the
wallet
level,
of
course,
you
can
go
as
granular
as
you
want.
So,
if
you
add
like
white
listing
in
a
wallet
you
can,
you
know,
set
conditions
based
on
the
field
types
and
ranges
and
whatever
you
want
and
just
verify
the
code
hash,
for
example,
but
I
think
having
an
ability
to
do
it
through
permissions.
D
Where
now
the
onus
of
work
is
not
on
the
dab
developer,
the
dab
developer
can
continue
building
all
their
because
a
complicated
game
you're
going
to
have
a
ton
of
contracts
so,
instead
of
them
having
to
retrofit
this
with
some
custom
logic
where,
if
something
goes
wrong
there,
you
know
there
are
serious
consequences.
I
think.
Having
that
request
for
permission
idea,
I
see
I
mean
it
works
also
has
a
use
case.
B
Yep
agreed
yeah
I
I
I
actually
years
ago,
designed
a
workflow
for
gosh.
What
did
we
call
the
call
it
well
anyway,
but
it
was
this
basic
concept
of
or
for
the
es
network
of
requesting
certain
permissions
sort
of
in
advance.
Now
I
do
want
to
also
share
just
a
principle
that
has
come
up
in
conversations
before
that
I
agree
with
that
is
I'm
going
to
share
it
through
telling
a
brief
story
back
in
like
I,
don't
know
this
must
have
been
like
2013
or
something
like
that.
B
C
B
Do
wonder
if,
like
the
first
step
like
I'm,
I,
am
supportive
of
this
concept,
but
I
do
wonder
if
the
first
step
that
might
make
more
sense
is
for
trusted
wallets
to
implement
this
in
the
wallet
logic
rather
than
in
the
system,
so
that
we
can
see
how
they
approach
it
and
what
problems
they
run
into
before
building
a
protocol
feature
around
it
right.
Well,
I!
Guess
it's
not
a
protocol
feature,
but
a
before
building
a.
D
D
Then
provide
at
that
point.
There
is
no
control,
for
you
know
like
you,
like.
The
wallet
may
lose
connection
with
the
front
end,
and
then
you
have
no
way
to
to
change
that
unless
you're
saying
when
you're
doing
the
request
for
permission
as
the
user
signs
it,
it
almost
does
like
a
scheduled
transaction,
but
no
schedule
transaction
like
just
keeps
it
in
its
own
I,
guess,
wallet,
memory
and
then
goes
and
automatically
removes
that
permission.
D
Of
course,
the
issue
with
that
is,
if
somebody
just
closes
their
wallet
or
or
or
you
know
it's
on
another
like
it's
on
your
phone
and
maybe
it
can
do
anything
while
it's
nothing
in
focus,
but
that's
something
to
explore,
but
definitely
we
can
build
the
initial
part
of
it
and
prove
the
concept
and
show
them
the
Improvement.
In
user
experience.
F
D
Well,
they
definitely
won't
disappear
on
their
own,
like
blockchain
will
happen
and
so
on,
but
like
I
mean
the
user
can
either
request
that
to
remove
it
or
they
can
just
like
next
time
they
do
a
request
for
permission.
The
wallet
itself
can
can
clear
that
can
like
do
whatever
action
is
necessary
to
remove
that
RAM
used.
B
And
I
think
request
for
permission
is
a
great
example
of
seeing
that
implemented.
First,
like
that,
might
automatically
act
or
not
automatically.
That
might
ultimately
that's
what
I
meant
to
say
actually
makes
sense
as
a
as
like
a
core
feature,
you
know
like.
Obviously
it
would
need
to
be
presented
through
a
wallet,
but
actually
part
of
you
know
leap
in
some
way,
but
it's
something
that
would
be
like
a
bad
idea
to
implement.
Now,
because
we
don't,
we
haven't
seen
the
pitfalls.
B
People
are
going
to
run
into
with
it,
because
you
know
the
the
the
obvious
risk
I
see
there
is
around
sort
of
deceptive
permission
requests,
which
is
to
say
burying
the
lead
right.
Like
oh
yeah,
we're
requesting
permission
to
you
know:
I
don't
know,
do
this
innocuous
challenge
thing
and
this
innocuous
thing
and
then
like
down
there
down
somewhere.
It's
like
this,
not
innocuous.
You
know
and.
D
This
is
living
on
the
user's
browser,
so
the
only
way
to
take
it
is
if
he
has
malware
or,
and
then
he
has
probably
bigger
issues,
but
the
idea
is
to
use
it
for
not
important.
Obviously,
and
people
will
do
whatever
they
want,
but
the
idea
is
to
use
it
for
not
important
actions
where
say
you're
in
a
game.
You're
just
doing
actions
in
the
game
so
worst
case
of
somebody
gains
physical
access
or
or
finds
another
way
they're.
Just
you
know
kind
of
messing
with
your
gameplay
versus
messing
with
tokens.
B
Right
to
that
and
to
another
concept,
that's
like
what's
the
word
I'm
looking
for
almost
too
simple
right,
that
has
has
come
up
before
and
there's
a
caveat
with
this,
which
is
goes
right
back
to
that
Ram
concern.
But
another
concept,
is
you
know
what
if
wallets
made
it
well,
this
would
require
some
leak
features
too
I
think.
B
There
is
no
risk
right
like
they
can't
they
can
only
they
can
only
do
whatever
you've
explicitly
given
them
access
to
by,
like
you
know,
transferring
stuff
into
that
account
right,
and
so
now
you
don't
necessarily
need,
as
you
don't
necessarily
need
like
a
sophisticated
permission
system
as
much
as
you
just
need
a
need
to
be
like
cognizant
of
like
okay
I've
transferred.
If
you,
you
can
almost
think
of
it
like
in
web
2,
sort
of
way,
which
is
like
oh
yeah,
like
I
I
trust.
B
You
know,
I'm
gonna
make
it
Financial
I
Trust
Bank
a
with
you
know
my
life
savings
there's
this
other
financial
institution
that
seems
kind
of
shady,
but
they
have
like
you
know
one
thousand
percent
daily
yield
or
something
so
I'm
gonna
put
a
little
in
there
to
to
see
how
it
goes
and
to
take
advantage
of
that
yield,
but
I'm
not
going
to
trust
I'm,
not
going
to
put
all
of
my
all
of
my
assets.
There
right.
D
B
So
I
think
about
problems.
I
think
it
potentially
could
be
a
a
good
experience,
but
there's
some
fundamental
problems
that
would
have
to
be
solved
for
it
to
be
an
option
right.
One:
there's
the
technology
sort
of
side
problem
which
is
yeah
it
takes.
It
takes
Ram
right
like
and
everybody
having
lots
of
accounts.
D
B
Well,
so
yeah,
that's
where
I
was
going.
The
next
piece
of
this
is
that
I
think
all
of
that
would
need
to
be
abstracted
right.
The
user
would
would
think
of
it
as
like,
a
single
account
and
they
wouldn't
need
to
know
the
details
of
how
things
are
sandboxed,
but
they
would
just
understand
that
apps
only
have
access
to
what
they
explicitly
give
them.
Access
to.
B
You
know
through
that.
So
an
example
of
this
is
the
again
going
back
to
like
sort
of
a
oauth
sign-in
thing
right
when
you
log
into
an
app
with
like
your
Facebook
account
or
your
Google
account
or
whatever
right.
You
understand
that
one.
You
only
have
one
Google
account
right,
so
that
feels
easy,
but
two,
the
app
you're
logging
into
is
not
your
Google
account
right,
and
so
it's
like
a
it's
a
noon.
D
Yeah,
like
social
login,
is
just
going
to
use
your
or
talk
and
token
to
verify
that
you
are
that
email,
but
then
you're
gonna
obviously
have
your
own
database,
where
you're
associating
that
email
address
with
the
own
data
that
you
want
to
keep.
But
for
the
user
experience
it's
one
account
even
in
a
game
or
or
a
blockchain.
You
want
that
one
account,
because
that
one
account
might
be
linked
to
maybe
nfts
that
can
be
used
in
the
game.
They
might
be
linked
to
tokens
on
another
contract
and
not
necessarily
everything
you
want
separated.
D
What
you
want
is
a
permission
separated,
but
not
that
count
so
I
think
the
solution
might
have
to
do
with
either
working
the
permission
system
if
it
even
needs
to,
or
or
potentially
will
have
another
smart
contract.
That's
generic
and
can
be
used
for
the
game
to
that
has,
like
anybody,
can
add
the
public
key,
so
it
can
sign
on
their
behalf.
Some
things
like
there
might
be
something
that
could
be
done
as
before.
Choosing
the
permission
system
to
do
it
on
a
separate
contract,
yeah
and
potentially.
B
The
point
of
debate
that,
like
a
kind
of
rebuttal
to
that,
is
like
I,
actually
I,
think
you're
totally
right,
sometimes
and
then
in
other
use
cases.
It's
not
that
way,
because,
as
an
example
of
that
right,
like
yes,
interoperability
and
stuff,
I
would
want
apps
to
you
know,
be
able
to
interoperate
in
good
ways,
but
by
contrast,
I
would
not
want
to
use
my,
for
example.
You
know
bank
account
to
to
play
a
shady
web
game.
D
Right
now
that
can
do
anything
which
can
do
anything
with
your
account
that
they
use
the
Google
account
to
generate,
and
in
this
case
with
permissions
you
would,
you
would
effectively
have
the
same
thing
where
sure.
With
that
permission,
they
can
do
anything
in
that
game
ecosystem,
but
they
can't
let
anything
outside.
B
It
that's
actually
where
I
was
going
with.
This
is
I
actually
think
these
are
not
mutually
exclusive
Concepts
they
they
are.
They
are
compatible
complementary
Concepts,
because
in
some
cases
you
want
to
Grant
an
app
permission
to
do
things
specific
things
on
your
behalf
with
your,
like.
You
know
in
this
metaphor,
with
your
Google
account
right,
but
you
also
the
app
needs
its
own
sort
of
sandbox
right
where,
where
it
can
do
its
own
stuff,
right
and
so
I
could
see
these
as
potentially
compatible
Concepts,
where
it's
like.
B
Yes,
you
have
the
ability
to
request
permissions
in
a
merry
oauth
style
and
now
that
game
can,
on
your
behalf,
do
certain
things
right,
but
also
the
game
does
have
with
that
game.
You
do
have
some
kind
of
sandbox,
whether
it's
a
separate
account-
or
you
know
some
kind
of
name
spacing
within
account.
You
know
I'm
imagining
Blank
Slate
right
now,
so
that
I
don't
have
to
deal
with
the
complexities
of
reality,
but
anyway
yeah.
So
my
anyway
I
think
this
is
just
backing
up
a
little.
The
concept
makes
sense.
B
B
B
B
B
So
that's
that's
kind
of
where
we
are
the
other
potential
release
blocking
feature
that
we're
working
on
is
internally.
We
we
call
it
chicken
dance.
It's
a
the
purpose
of
it
is
to
gain
confidence
that
consensus
has
not
been
broken.
It's
particularly
important
for
releases
like
five
data
that
have
protocol
upgrades
that
are
more
likely
to
potentially
break
consensus
right
and
so
we're
we're
working
on
that
as
well.
B
It's
in
the
sort
of
it's
in
some
solution
to
sign
stages,
and
so
all
of
that
has
to
happen
before
we
can
estimate
timelines
there.
So
that's!
The
non-update
is
still
working
on
figuring
out
the
timeline
winner
release
candidate
can
be
ready
for
5.0,
but
I
wanted
to
bring
it
up
because
I
think
the
nature
of
this
call
is
about
to
temporarily
change.
Coming
soon,
it'll
go
back
to
a
more
of
a
you
know:
leap
3.1.
You
know
win
upgrade
type
of
thing,
probably
more
run
by
Daniel
than
myself.
B
Coordinating
a
consensus
sort
of
protocol
upgrade
so
so
that's
coming.
I
just
want
people
to
it's.
I,
don't
think
it's
like
immediate
future,
but
coming
soon.
The
purpose
of
this
call
will
will
sort
of
temporarily
change
in
nature
and
then,
once
once
we
get
through
that
process,
we'll
we'll
come
back
to
more
of
a
topical
discussion
or
mat
like
this
before
I
move
to
the
next
potential
topic.
A
F
Go
ahead,
I'm
sorry
I
was
moving
around
whenever
you
were
asking
about
the
questions,
but
if
you're
you're
talking
about
the
linking
of
permissions
that
prevents
the
the
active
key
to
science,
so
I
would
think
that
that
could
potentially
cause
an
issue,
especially
if
there
was
a
temporal
aspect
to
that
and
then
I
did
share
sort
of
like
a
solution.
That
I
was
talking
about,
which
you
mentioned
as
well.
F
D
Like
a
key
would
be
generated
on
worth
running
on
the
front
end
and
that
public
key
object
will
be
passed
to
create
a
new
permission
for
a
specific
contract,
slash
action
and
that's
feasible
in
theory
now.
But
the
question
was
more:
if
we
can
have
an
expiry
option
opposite
to
the
kind
of
Weights
permission
where
you
can
have
a
permission
that
hasn't
expiry
so
every
time
somebody
tries
to
use
that
permission,
that
expiry
field
is
checked
and
only
allows
it
off
if
that
expiry
is
met.
D
As
part
of
you
know,
two
out
of
two
say
author,
like
like
authorize
like
how
the
weight
was,
you
know,
so
you
have
an
expiry
that
that
needs
to
be
met
like
that.
The
transaction
is
happening
before
that,
as
well
as
the
key
needs
to
work
and
that
key
being
coming
from
the
front
end
and
of
course
white
listing,
like
you
mentioned,
is
different
than
creating
permissions
and
linking
them.
This
is
more
to
effectively
get
something
similar
to
white
listing
for
a
temporary
session
in
a
game
or
in
a
test
net.
F
Okay,
I
guess,
then.
My
concern
that
I
wanted
to
raise
is
the
implications
with
third-party
applications,
for
example,
I'm
using
custom
permissions
in
my
applications
to
Mint
nfts
and
one
of
the
reasons
I
do.
That
is
because
I
don't
want
to
ever
put
an
EnV
file
with
permissions
that
would
give
owner
or
even
active
Keys
to
somebody
who
could
potentially
hack
my
Amazon
or
whatever
account.
F
F
Maybe
that's
not
a
valid
concern,
but
it
seems
like
if
you
are
linking
permissions,
especially
if
it's
a
non-project
token,
especially
if
it's
something
like
Atomic
assets,
which
could
would
be
a
common
use
case
of
of
such
a
thing.
You
may
run
into
interdap
issues,
so
that
was
all
I
wanted
to
to
sort
of
raise.
D
Just
to
jump
on
this
just
very
quickly,
that
would
be
definitely
a
UI
issue.
I've
seen
similar
not
the
same
but
similar
issues
in
anchor,
for
example,
where,
if
you
have
a
cosine
transaction
and
it's
both
like
cosigners,
have
the
same
key,
it
will
try
to
get
you
to
sign
with
the
wrong
account.
Slash
permission.
Obviously,
the
UI
and
when
you
log
in
you're,
not
logging
into
an
account
you're
logging
into
an
account
as
permission
and
that
should
be
honored
by
the
wallet.
B
It
occurs
to
me,
you
know
going
back
to
this
thought
of
like
the
wallet
implementing
the
expiry
sort
of
that
concept.
As
a
first
step,
I
mean
it
occurs
to
me
that
the
wallet
you
know,
obviously
you
trust
your
wallet,
because
your
your
keys
are
stored
there
right.
So
perhaps
the
wallet,
what
am
I
trying
to
say
rather.
B
Well,
no,
no!
So
that's
that's
one
way
of
doing
it.
I
I'm,
just
so
A
variation
on
this
idea
right,
so
the
at
so
let's
go
to
the
way
it
works
today.
Right,
the
app
itself
doesn't
store
the
key
right,
the
the
wallet
stores,
the
key
and
so
then
the
app
when
it
wants
a
signature.
It
asks
the
wallet,
hey
sign
this
and
then
the
wallet
asks
the
user
hey.
B
Right
exactly
so,
but
if
it
worked
that
way,
then
that
also
means
that
the
expiry
would
be
you
know
a
trivial
extra
piece
of
functionality,
because
it
when
it
receives
a
request
to
sign
it
would
go.
Oh
yeah,
my
I
don't
have
an
unexpired
permission,
so
I'm
not
going
to
sign
that,
for
you
right,
one
I
think
that
would
solve
most
of
the
use
cases
of
like
having
an
obtrusive
sort
of
flow.
D
D
Even
potentially
you
know
just
warn
the
user
when
he
logs
out
from
your
adapt
like
give
them
an
option
to
you
know,
remove
that
permission
or
have
the
wallet
itself
track
and
show
you
like
hey.
You
have
here
permissions
that
expired,
but
you
still
didn't
remove
that
from
from
the
chain
and
I'm
thinking
of
this
more
as
a
temporary
solution
and
to
see
if
it
does
really
improve
the
ux,
and
we
can
eventually
have
expiry
on
chain.
E
D
So
here
for
app
we're
going
to
say
front
end
just
to
to
kind
of
make
sure
it's
not
the
smart
contract
and
the
front
end
will
before
it
requests.
The
permission.
Part
of
that
request
is
going
to
be
the
public
key
that
is
going
to
be
associated
with
the
private
key
that
gets
generated
on
the
front
end
by
Wharf
in
the
UI,
so
it
will
generate
a
new,
unique
private
key
and
part
of
that
request
for
permission.
D
D
Right
sure,
but
control
has
been
added,
I
wouldn't
say
lost.
This
controller
has
been
added
to
the
front
edge
to
the
front
end
limited
control.
That
is
also
obviously
the
UI
will
have
access
to
it
if
it's
malicious,
but
it's
a
limited
control
it
doesn't
have,
and
by
default,
as
we
said
like,
it
won't
allow
for
any
EOS
IO
actions
so
and.
E
It's
already
possible
to
add
custom
permissions
today,
so
we're
not
adding
any
new
risks,
we're
adding
the
added
ability
to
have
that
permission
expire.
For
example,
EOS
name
service,
we're
getting
ready
to
relaunch.
We
will
likely
be
adding
a
request
in
order,
so
what
EOS
name
service
does?
Is
it
allows
you
to
resell
your
premium
names?
So
so
you
know,
for
example,
I
bought
the
name
on
the
EOS
name.
E
Auction
I
can
resell
daniel.inc,
but
to
do
that
on
a
Marketplace
like
we're
doing,
the
smart
contract
needs
permission
to
sell
names
using
your
premium
name,
so
we're
going
to
be
having
people
add
a
custom
permission
that
gives
our
smart
contract
the
the
permission
to
sell
names
on
your
behalf,
and
that's
the
only
thing
it
has
permission
to
do
so.
This
feature
Shack
is
is
requesting
would
allow
the
user
to
say.
E
Well,
you
only
have
permission
for
X
period
of
time
to
sell
names
on
my
behalf
as
opposed
to
in
perpetuity
right,
but
I'm
wondering
is
it?
Is
it
I,
don't
know
the
Can
a
permission
remove
itself
or
do
you
always
need
an
owner
key
to
add
or
remove
any
permission,
and
it's
if
it
is
possible
for
a
permission
to
remove
itself,
you
could
have
one
of
the
permissions
it
has
access
to
is
to
remove
itself
and
the
smart
contract.
E
G
D
And
also,
let's
distinguish
because
we
don't
need
to
remove
things
automatically
because
that's
like
that's
not
what
you
know.
That's
not
how
you're
gonna
necessarily
do
things
on
the
blockchain.
You
want
it
so
that
the
next
request
or
next
time
you
know
it
can
check.
What's
it
expired
and
then
remove
them.
So
I'm
not
concerned
with
necessarily
removing
the
permission
right
away,
but
if
it
hasn't
expiry
where
the
permission
has
requires.
B
B
B
B
The
larger
topic
which
we
won't
get
into
today,
because
it
would
take
too
long,
is
understanding
sort
of
your
dream,
install
and
upgrade
processes
for
nudios,
as
a
you
know,
longer
range
change
to
make
to
make
staying
current
much
more
trivial
right
as
the
in
the
the
ultimate
solution
might
not
even
involve
this
at
all.
But
it's
just
as
something
that
we
could
discuss
quickly
right
now,
curious
about
about.
Like
the
various
package
managers
that
people
use
and
the
you
know
preferred
you
know,
package
and
configuration
management.
G
I
I
mean
Nations
I
know,
has
a
crazy
big
process
that
they
use,
Detroit
I
think
is
who
wrote
some
big
ansible
whatever
it's
not
like.
That's
not
my
thing,
so
I
could
speak
too
much
on
it,
but
I
mean
there
are
some
automated
deployment.
It
really
comes
down
to
what
chain,
what
features
and
then
being
able
to.
You
know
retrieve
like
Nations
or
specific
configuration.
Well,
that's
what
I
was
gonna
say
the
reason
they
they
wrote.
G
G
G
Here's
all
your
different
types
that
you're
deploying
and
then
obviously
your
deployment
method
tended
to.
Oh,
it's
a
ship
node
turn
this
on
turn
these
extra
parameters
on.
Oh,
it's
EOS!
Okay,
it's
a
vanilla,
binary!
Oh
it's
wax!
It's
got
to
be
this
other
binary
and
then
obviously
things
respective
to
it,
but
it
basically
dynamically
builds
that
config.
D
I
think
build
Tools
in
general
are
specific
to
the
infrastructure.
Generally
different
people
are
going
to
use
different
things.
A
lot
of
people
are
going
to
script,
their
own
things
using
system,
services
or
other
things,
so
I
think
maybe
the
effort
if
we
want
to
improve
that,
could
be
more
in
the
stuff
Michael
mentioned
earlier,
which
is
regardless
of
the
configuration
that
you
set.
There
is
some
things
that
nude
EOS
handles
itself
like
if
you're
restoring
from
snapshot,
you
know,
leave
the
state
and
remove
the
reversible.
D
G
For
them,
I
agree.
Auto
peer
Discovery
is
another
big
one,
because
that's
where
you
got
to
kind
of
go
out
and
figure
out
who
you
can
sync
with,
and
that's
why
I
say
that
documentation
and
I
even
talked
about
it
yesterday
on
a
call,
it
was
a
BP
ask
me
anything
thing
that
there's
not
really
much
documentation
about
all
these
different
nuances
and
quirks,
but
a
substantial
efforts
being
made
to
identify
them
and
at
least
provide
like
that
documentation.
G
That's
what's
going
to
be
the
Bible
so
to
say
or
nations
to
know,
I
mean
to
do
this
this
this
this
and
this
Detroit
to
say
well,
I
do
the
same
things:
I
just
do
a
VA
ansible,
but
to
give
them
the
recipe
for
whatever
tools
you
want,
like
Amsterdam
I
forget
what
they
use
signia
or
whatever
it
is
here's
what
you
need
to
do.
Do
it,
however,
the
hell
you
want
to
do
it.
You
know.
G
Oh,
it's
like
node,
OS,
here's
what
you
need
to
run
it
run
into
the
system
service
run
it
as
in
a
container
whatever
the
hell.
You
want
to
do
right,
but
these
are
the
expectations
and
the
The
Playbook,
because
that's
where
I
mean
they
can
read,
there's
just
not
much
to
read
and
it's
so
archaic
in
so
many
different
parameters.
Basically
now
I.
C
G
B
All
right!
Well,
we're
excuse
me
we're
over
time.
So
but
that's
you
know
a
good
introduction
to
that.
We'll
come
back
to
this
topic
in
a
future
call,
but
thank
you
for
everyone
for
weighing
in
circling
back
to
what
I
mentioned
at
the
beginning,
July
12
2023
is
today
and
we
are
pushing
a
updated
versions
for
both
3.1
3.2
and
40.