►
From YouTube: EIPIP Meeting 56
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/136
A
Welcome
to
eipip
meeting
56.,
I
have
shared
agenda
in
chat.
The
first
item
listed
here
is
core
eips
in
an
executable
spec
world.
The
proposal
and
discussion
link
is
added
to
the
agenda
item
so
as
we
know
that
this
item
has
been
under
discussion
for
a
while,
I
have
added
it
as
the
first
item.
So
we
get
enough
time
for
discussion.
However,
greg
in
a
comment
below
has
requested
to
postpone
the
final
decision
on
this.
His
comment
is
added
on
the
agenda
itself.
A
So
as
for
the
rough
consensus
from
the
last
meeting,
they
were
supposed
to
collect
the
feedback
from
the
alco
dev
meeting,
but
as
anticipated,
the
all
coder
meeting
agenda
was
jam-packed
and
I
intend
thought
that
it
would
be
better
to
first
finish
up
with
the
merge
thing,
and
maybe
we
can
bring
it
up
to
the
next
code
meeting
or
maybe,
if
tim
can
collect
the
thoughts
asynchronously.
A
B
Not
specifically
about
greg's
comment,
but
we
did
get
a
little
bit
of
discussion
in
the
all
core.
Devs
discord
like
text
channel
and
it
seems
like
people
are
pretty
mixed
about
it,
but
yeah.
It
wasn't
like
a
super
in
depth
or
like.
A
Sounds
good
so
for
people
listening
to
this
call,
if
you
are
interested
in
following
this
discussion,
there
is
a
fem
link
added
to
the
agenda
and
you
may
also
follow
earlier
meeting
notes
available
on
ea
repository
but
I'll
keep
it
on
the
next
meeting.
A
Moving
on
to
item
number
two
splitting
out
eip
repo
into
eips
and
ercs,
just
to
get
some
context
here,
the
number
of
standard
track,
erc
proposal
and
standard
track
core
proposals
submitted
every
month
are
generally
equal
in
number.
But
the
merge
as
final
for
core
and
ercs
the
ratio
is
not
same.
A
So
this
topic
was
an
active
discussion
about
a
year
ago,
and
people
may
find
the
link
below
to
follow
earlier
discussion,
and
this
has
been
brought
back
into
active
discussion
with
core
eips
for
executable
specs.
Thanks
to
tim's
tweet.
A
few
weeks
ago,
people
reached
out
to
provide
suggestions
and
even
help,
as
tim
mentioned
in
the
discard,
and
also
one
contributor
showed
up
yesterday
in
the
internship
meeting,
to
maybe
help
with
the
process
so
inviting
kilian.
I
see
him
on
the
call
today
to
share
his
thoughts.
C
Hi,
all
I'm
killian
we've
been
working
on
a
product
using
github
and
a
lot
of
bots
and
scripts.
Therefore,
we
wanted
to
propose
our
help
there
to
split
eips
and
ercs.
It
would
be
not
too
hard
to
do
that
at
the
moment.
C
D
Yes,
well,
I
just
was
wondering,
is
the
precisely:
is
the
vodka
and
the
ap
but
can
actually
classify
the
which
is
eip?
And
what
do
you
say
erc?
That's
not
the
problem.
I
think
that
the
problem
is
to
define.
Is
it's
gonna
be
another
repo
for
for
what
I
was
reading
into
the
discussions?
D
I
think
that
the
classification
is
it's
not
pretty
much
the
issue.
I
think
that
the
what
I
was
reading
there
and
on
even
I
I
go
back
with
your
notes
that
the
the
that
you
sent
the
conversation
that
you
sent
and
I
went
back
to
the
leggy
lee
guy
he
he
actually
proposed
like
two
years
ago,
so
it's
just
a
matter
of
defining
it.
It's
going
to
be
one
additional
repo
for
the
ercs.
F
G
That's
probably
a
good
enough
like
crutch
for,
like,
basically,
you
know
having
a
subset
of
people
who
are
assigned
the
ercs
and
and
we
may
choose
to
make
that
subset
zero.
Basically,
if
we,
if
we
want
like,
if
nobody
wants
to
be
an
erc
editor,
then
you
can
still
have
a
world
where,
like
we
only
have
vip
editors
and
and
just
no
one
gets
paid
when
there's
a
new
erc,
which
is
obviously
not
great.
But
that
also
happens.
G
If
we
split
the
repo
and
yeah,
I
I
think
figuring
out
something
that's
long
term
that
works
long
term
with
the
executable
specs
across
both
like
the
consensus
and
execution
layer
is
like
pretty
important
just
because
we're
starting
to
see
the
like
technical
depth
creep
up
there,
where
there's
like
these
weird
pr's
in
the
consensus,
specs
repo
that
are
basically
eips
and
then
there's
stuff
like
an
eip484
folder
showing
up
in
the
consensus
specs
as
well.
G
A
So
the
one
major
problem
that
seems
to
be
pertinent
here
is
like
we
definitely
need
more
people
who
will
be
able
to
review
the
erc
category
proposal.
So
if
we
get
the
number
of
reviewers
increased
number
of
rivers,
probably
it
will
help.
I
mean
splitting
the
repo
may
not
be
helpful.
Getting
erc
category
proposals
on
board.
G
Yeah,
I
think
that's
right
and
I
think
mika.
The
other
thing
you
you
mentioned
in
that
chat
with
alex
was
like
you
currently
watch
the
entire
repo,
because
you
want
to
make
sure
no
notification
slips
through
the
cracks,
and
so
another
like
valuable
thing
we
can
do
is
just
have
somebody
who's,
maybe
not
an
editor
who,
just
like
monitors
the
notifications
in
the
repo
and
then,
if
something
hasn't
been
like
updated
in
like
three
days
or
like
a
week,
then
they
ping
either
mika
or
editors
or
I'm
not
sure
who.
G
A
I
see
a
comment
in
the
agenda
here
by
lifeline,
maybe
for
having
people
who
can
maybe
own
the
working
group
like
land.
If
you
would
like
to
speak
about
it,.
H
She
so
this
is
a
little
unrelated
to
splitting
out
the
rc
repo
and
just
on
that
topic
before
we
close
it.
I
sort
of
feel
like
what
is
most
likely
to
happen
is
that
the
execution
specs
takes
over
for
core
proposals
and
then
the
erc
eip
repo
sort
of
becomes
the
erc
repo.
I
think
it's
going
to
be
pretty
hard
to
actually
migrate
the
erc
repo
somewhere
else,
because
we
have
you
know
lots
of
issues
there.
Lots
of
links
that
are
linking
to
that
repository.
H
It
seems
a
lot
easier
to
try
and
no
eaps.
I
don't
know
I
mean
it's
not
like
a
perfect
solution.
I
just
don't
know
a
better
way.
It
seems
like,
like
the
people,
the
easiest
thing,
the
easiest
part
of
this
equation
to
change
is
the
core
part,
because
that
those
are
the
people
that
we
are
in
cl
most
close
communication
with,
and
it's
the
easiest
to
say
this.
H
It
has
changed
and
I
think
the
erc
portion
is
a
lot
harder
to
change,
because
you
have
this
long
tail
of
people
who,
like
don't
follow,
what's
happening,
and
I
think
we
are
really
successful
with
renaming
things
to
el
and
ceo,
because
we
were
able
to
just
do
it
at
this.
Like
small
core
group
of
like
sub
100
people
yeah,
I
zero.
I
don't
know
we
need
to
figure
out
exactly
what
this
will
look
like.
G
F
F
I
I
fully
agree
with
you
that
we
need
a
place
to
put
useful
documents
that
we
can
link
people
to
and
we
can
discuss
and
we
can
talk
about
on
core
dev
calls
blah
blah
blah.
That
is
a
useful
thing.
I
think
that
we
should
not
sacrifice
the
the
standardization
process
to
achieve
that
goal.
We
should
create
a
new
process
or
a
new
thing
that
fulfills
that
need,
which
is
very
different.
In
my
opinion,
from
the
need
of
specification
and
standardization
in
centralization,
you.
F
G
G
Well
but
then,
when
somebody
comes
out
once
and
they're
like,
I
have
eip4844
and
they
show
the
specs,
then
the
first
question
people
ask
is
like
what
is
this
thing?
Is
there
like
a
meta
thing?
I
I
wouldn't
care
if
we
literally
use
meta
eips
for
that,
because
they're
like
not
used
anymore
like
if
we,
if
we
want
to
use
meta
eips
as
a
like
weird
rapper
around
like
right,
but
it's
basically
saying
meta
eips
become
corey
ips.
F
Right
so
I
agree
with
you
that
it
would
be
very
valuable
to
have
a
place
for
the
thing
you
described.
My
only
argument
here
is:
I
do
not
think
that
we
should
take
over
the
the
standardization
process
with
that
process.
I
think
we
need
a
new
process
and
you've
convinced
me
that
we
do
need
this
new
process
like
the
thing
you're
describing.
I
agree
we
need.
F
I
just
I
really
don't
want
to
throw
away
like
turn
the
standardization
process
into
that,
because
then
we
lose
the
standardization
process
as
like
a
a
clean,
pristine
modular
thing,
and
we
now
have
it
it's
kind
of
this
ever-growing
thing
that
is
hard
to
define
and
it
covers
lots
of
lots
of
ground.
We
have
lots
of
people
involved.
I
think
it's
really
valuable
to
keep
those
standardization
process
isolated
and
tiny.
Well,
that
means
nobody
uses
eips
anymore,
except
for
ercs
right.
F
No,
so
you've
still,
we
still
have
this
specification
process
for
core
chain
for
executable
spec
changes,
and
that
goes
through
the
executable
spectrum.
Exactly.
H
H
F
F
Sure
I
mean
from
a
navy
standpoint
like
I
am
totally
okay
with
the
specification
process
not
retaining
the
name.
Eips
like
that
part
doesn't
bother
me.
I
I
just
think
the
specification
process
is
isolated
from
the
that
kind
of
meta
thing
that
you're
describing
so
what.
F
F
G
F
G
F
When
I
maybe
I
want,
I
disagree
with
keeping
them
in
sync
again,
I
I
really
do
think
specifications
should
be
isolated
and
you
should
not
need
to
worry
about
having
your
specifications.
Seeing
another
specification,
because
things
get
really
complicated,
then
like
tcp,
is,
as
an
example
is
very
isolated,
like
lots
of
things,
build
on
it
and
integrate
with
it
and
use
it,
and
it's
all
over
the
internet,
but
the
specification
for
it
is
isolated
from
everything
else,
but.
G
That's
yeah,
and
this
is
why
I
want
to
keep
eips,
because
then
you
get
the
number.
So
it's
like
I
keeping
eips
as
like,
just
the
english
description
and
the
number,
and
then
you
add
two
links
to
that
one
to
the
cl
one
to
the
el
like
this
is
why
it's
my
dream:
it's
like,
because
you
keep
the
number
it's
still
called
484
people
then
go
to
consensus
specs
and
they
look
for
484
and
they
find
it
and
they
don't
need
to
deal.
G
There's
only
one
place.
You
need
to
deal
with
numbering.
It's
like
once.
You
get
your
eip
number,
then
you,
like
you,
know,
change
your
folder
name
and
the
specs
repo
and
that's
it
and
it's
it's
super
easy.
But
then
you
can
still
have
the
community
go
to
eeps.ethereum.org
c4844,
it
says
hey,
this
is
going
to
add,
chart
blob
transactions,
it's
going
to
scale,
ethereum,
there's
a
bunch
of
security
considerations
and
here's
the
implementation,
here's
the
specification
in
the
cl
and
the
yell.
G
F
So
I
think,
there's
two
remaining
places.
We
disagree,
one
I
like,
as
mentioned.
I
don't
think
we
should
have
try
to
maintain
consistent
naming
across
them.
I
think
that
in
the
execution
actual
spec
it
should
be
isolated,
which
means
like,
when
a
there's,
a
spec
change
proposal
to
it
that
would
have
whatever
its
numbering
system
is.
It
would
get
that
numbering
system
just
like
rfcs
have
their
memory
system.
Ietf
has
this
memory
system
and
the
two
are
isolated
from
each
other?
I
don't.
F
Much
about
that
yeah,
that's
fine!
The
second
thing
that
I
would
like
is,
I
do
think
that
things
like
so
for
let's
take
four
four
four,
which
touches
with
yellow
and
seal
the
security
considerations
section
so
like
there
will
be
an
overarching
security
considerations
set
of
things
that
affects
both
the
seal
and
the
eo.
There
will
also
be
things
that
are
very
specific
to
the
el
and
I
think
those
security
considerations
should
live
in
executable,
specs
repo
and
similarly
any
security
considerations
related
to
the
consensus
layer.
F
Change
should
live
in
the
consensus
layer,
repo
again
trying
to
make
sure
that
you
know
when
there's
a
change
to
the
executable
spec
everything
that
you
need
to
know
about
that
is
in
that
repo
by
itself.
Now,
if
you
want
bigger
contacts-
and
you
want
the
bigger
picture,
then
I
agree
we
should
we
can
use
the
aps.
I
don't
even
mind
if
we
take
the
name-
I'm
not
okay,
so
yeah
the
name.
F
So
I
guess,
of
course,
a
set
of
things
that
needs
to
be
in
the
repo
with
with
the
code,
in
order
for
it
to,
you
know,
be
useful,
like
it's
literally
just
a
code
change,
then
there's.
I
think
we
run
into
problems.
Okay,.
G
G
F
Weird,
so
I
do
think
yeah,
I
I
think
there's
different
types
of
considerations
so
like
a
dos
vector
is
almost
certainly
going
to
be
against
just
one
of
the
layers
and
so
that
surface
type
security
configuration
would
go
in
the
relevant
spec,
and
so
it
could
be
the
reason
it
should
go.
There
is
because,
if
someone's
working
off
of
the
spec,
they
need
to
be
aware,
while
they're
writing
their
code.
For
this
thing,
hey,
you
know
specific
to
the
code.
You
write,
you
need
to
make
sure
you
deal
with
this.
Okay.
G
Yeah,
that's
right,
yeah!
That's
our
district!
I
guess
because
with
dos
like,
I
think
my
experience
is
like
with
most
security
considerations.
You
don't
really
deal
with
them
as
you're
writing
the
code,
but
you're
dealing
with
them
as
you're
like
iterating,
on
the
specification,
so
it's
like
and
maybe
I'm
wrong
there.
Yes,
I.
G
F
Have
what
you
described
exactly
as
you
described,
were
there
the
security
considerations
that
like
when
we
were
designing
this?
We
thought
about
these
things
and
we
designed
around
them,
and
this
is
why
it's
okay
and
those
I
I
I
would
be
okay
with
those
type
of
things
going
in
that
the
meta
place.
Similarly,
if
we
have
security
considerations
that
do
affect
like
talk
about
the
interaction
between
the
two
clients,
okay,.
G
I
can
see
that
yeah,
but
but
I
can
see
something
like
weird
like
imagine
this.
What's
uniswap's
eip
like
the
transient
storage,
one
and
there's
some
weird
security
considerations
about
like
the
inter
frame
calls
or
whatever,
like
I'm
totally
fine
with
that
just
being
in
the
executable
spec
like,
oh
and
now,
like
client,
disagrees
with
all
of
this.
H
F
H
H
F
Yeah
we
want
modularization,
I
think
it's
yeah.
In
order
for,
in
order
for
us
to
scale
development,
then.
F
That
would
be
my
hope.
Yes,
like.
I
would
like
to
pull
out
the
mempool
out
of
the
clients
and
put
it
into
a
third
service
like
just
from
a
development
standpoint.
If
we
want
to
keep
velocity
going
up
for
ethereum,
we
need
to
have
separation
of
things
like
you
can
actually
see
this
already.
So
with
executables
like
execution
layer,
everybody
knows
that
like
martin
is
the
person
that
you
need
to
sell
on
everything
right
like
martin
is:
is
the.
F
Yeah,
that's
the
alpha
like
like
martin
is
the
guy
who
will
tell
you
your
stuff
is
wrong
and
it
will
break
because
of
reasons
that
go
way
back.
We
don't.
I
martin
no
longer
has
to
worry
about
consensus,
stuff,
danny
does,
and
so
now
we
have
two
people
doing
the
job
that
usually
used
to
be
just
martin
doing
and
because
danny
knows.
H
I
just
don't
see
why
that
has
to
be
at
the
spec
level
like
you
can
still
have
this,
like
imagine,
there's
this
world
where
all
of
these
changes
go
through
some
eip
repository
that
has
both
python
specs
for
el
and
cl.
I
don't
see
why
you
can't
just
have
martin
reviewing
el
danny
reviewing
cl
and
then,
when
you
have
these
changes
that
go
across
both,
then
you
can
actually
have
it
all
in
one
place,
rather
than
trying
to
build
these
systems
to
create
meta
specs
around.
Like
many
changes.
F
I
think
the
answer
to
that
is
because
humans
suck
and
if
we
put
everything
into
one
repo,
then
I
think
we're
going
to
end
up
with
lots
of
bleeding
between
the
two,
whereas
if
we
keep
them
in
separate
repos
and
fully
isolated
from
each
other,
it
basically
protects
us
from
our
future
selves.
Who
will
do
bad
things?
F
F
So,
by
having
the
specs
in
two
separate
repos,
it
forces
us
to
draw
very
clear
boundaries
between
the
two
pieces
of
software
and
it
doesn't
allow
us
to
blur
the
line
and
and
kind
of
blend
the
two,
and
I
think
that
that
separation
being
very
clear
and
a
hard
line
forces
you
to
think
about
things
a
certain
way
and
that's
the
same
reason.
F
Why,
like
in
just
as
it's
a
kind
of
analogous
example
in
my
personal
projects
when
I'm
building
a
library,
I
put
it
in
a
separate
repo
and
I
work
on
it
because
it
forces
me
to
have
a
very
clear
api
layer.
It
makes
it
forces
me
to
interact
with
it
as
a
third-party
thing
and
that
changes
the
way
I
think
about
the
project
as
a
whole.
F
F
It
provides
a
very
useful
tool
for
segregating
these.
These
two
things
mentally
that
humans
have
a
tendency
to
not
do
naturally,
like
the
natural
inclination
is,
if
you
have
two
things,
they're
sitting
right
next
to
each
other.
You
kind
of
blend
them
together,
especially
if
you're
constantly
working
on
them
at
similar
points
in
time
and
you're,
integrating
them
together.
It's
really
easy
to
just
blend
those,
and
so
having
these
very
clear
lines
protects
us
from
future
us
because
future
us
are
going
to
do
dumb
things
if
we
allow
it.
G
Yeah-
and
one
thing
I'll
add
is
I
I
may
be
a
bit
more
pessimistic
than
you
matt
like
I,
I
don't
think
we'll
ever
see
a
spec
for
the
mempool
just
because
people
in
practice
have
such
a
hard
time
letting
go
of
the
thing
they
control.
So
like
I,
it's
almost
like
a
nice
accident
of
history
that
we've
ended
up
with
these
two
separate
specs,
and
now
we
get
to
manage
them
in
parallel
and,
like
I,
I
think
it's
really
hard
to
unbundle
things.
G
Yeah
right,
you
know,
alex,
would
thrive
forever
and
like
the
evm
would
be,
would
be
great
and
like-
and
that's
just
never
gonna
happen,
because
I
think
it's
like
a
human
problem.
It's
like
or
maybe
it'll
happen
once
all
the
current
coordinates
have
like
retired
and
the
people
who
come
have
like
less
of
an
attachment
to
this
stuff.
But
it's
yeah,
I
I
don't.
H
H
Yeah
I
mean
I'm
just
like
not
sure
that,
like
in
my
mind,
it's
just
a
lot.
It
would
be
a
lot
better
if
there
was
this
perfect
world,
where
we
had
one
repository
that
you
could
see
the
diff
across
both
layers,
and
you
know
those
people
can
see
immediately
like
what's
happening
rather
than
having
a
situation
where
now
we
have
to
have
like
you
know,
meta
specs
built
on
top
of
like
two
different
changes,
and
you
know
always
like
keeping
that
up
to
date,
rather
than
just
having
it
always
up
to
date.
G
G
F
F
The
consensus,
the
proof
of
work,
consensus,
layer
and
the
execution
layer
now
prove
state
consensus
does
is
significantly
different
and
it
does
have
withdrawals
and
deposits,
so
there
it
is
likely
to
have
more
changes
to
touch
both,
but
I
think
once
we're
done
with
this,
like
initial
thrust
of
merge
plus
post
merge
work,
I
suspect
we're
not
going
to
see
that
much
in
terms
of
changes
to
touch
both.
I
think
most
pages
will
touch
execution.
G
F
To
believe
that,
so
I
think
proposer
builder
can
actually
be
designed
one
layer
at
a
time.
I
don't
think
I
mean
I
haven't
been
following
it
closely.
So
maybe
I'm
wrong
on
this,
but
my
gut
tells
me
that
we
can.
We
don't
need
to
do
both
layers
simultaneously,
whereas
with
some
things
we
do
like
withdrawals,
for
example,.
A
F
F
So
I
think
it
depends
on
where
tim
and
I
land
in
this
epic,
seven
month
long
battle
over
what
to
do
with
specifications
versus
description
of
large
change
sets
if
we
end
up
like
in
the
end
that
I
want,
then
that
whole
meta
thing
is
just
like
someone
can
write
a
hackmd.
I
don't
care
like
it's,
it
doesn't
need.
I
don't
think
it
needs
to
be
as
official.
If
we
end
up
with
tim
once
then
I
I
think
you're
right,
we
will
need.
F
F
So
I
think
he
has,
I
think
his
number
system
is
based
off
of
the
pr
number,
but
he'd
be
a
better
person
to
answer
that.
H
H
F
F
The
for
the
sake
of
discussion-
let's
see
we
can
just
say
that
again
I
don't
know
what
sam
has
planned,
but
we
can
just
say
it's
yeah,
el
2075
or
whatever.
F
F
In
no
more
core
eaps
in
my
hypothetical
future,
I
suspect
we
may
end
up
with
something
that's
a
blend
between
tim's
and
mine.
So
I'm
using
the
extremes
just
for
for
discussion
here,
but
yes,
and
in
my
ideal
future
there
would
be
no
more
core
eips.
There
would
be
execution
layer,
spec
changes
and
there
would
be
concentration
of
changes.
H
I
just
feel
like
there's
not
a
way
that
we
can
get
around
getting
rid
of
using
eips
to
refer
to
core
changes,
because
it's
like
such
a
core
historical
part
of
referring
to
ethereum
changes.
And
I
think
it's
like
more
likely
that
we
have
an
eips
that
refer
to
execution,
layer
and
consensus
layer
and
there's
like
a
system
for.
A
F
I
think
that
the
strongest
argument
that
you've
made
is
that
humans
suck
and
they
don't
like
change,
and
I
mean
it's
certainly
possible
that
we
will
not
be
able
to
convince
all
those
humans
to
to
change
to
a
new
system
that
does
not
unfold
vips.
A
A
Maybe
if
one
of
you
can
like
summarize
it
for
the
note
taker
from
where
to
take
it
from
in
the
next
conversation,
all
right,
at
least,
we
can.
A
So
can
we
say
for
like
coming
back
to
agenda
item
number
two
splitting
out
eip
repo
and
into
like
eips
and
erc?
We
are
putting
it
on
hold
right.
A
F
H
G
A
Would
agree
yeah?
I
have
seen
this
in
most
of
the
cases
and
coming
back
to
lightline's
point
I
was
wondering
this
is
a
very
strong
argument,
but
I
would
have
been
more
more
convinced
if
this
is
coming
up
from
an
erc
developer.
I
understand
like
erc
people,
they
come,
they
push
their
standard
and
once
it
is
done
and
implemented
into
a
few
projects,
they
are
gone.
They
never
demanded
for
any
kind
of
governance
or
maybe
their
involvement,
deep
involvement.
F
I
think
the
I
think
there
have
been
a
couple
of
people
that
have
shown
up
and
said
they
are
interested,
but
then
they
disappeared.
So
I
I
think
the
reason
usually
they
disappear.
Is
they
realize
that
it's
a
time-consuming
thing
and
they
don't
have
the
time
for
it?
I
don't
so.
I
do
think
there
are
people
that
want
this.
What
we're
describing,
I
don't
know
if
there
are
people
who
want
it
and
have
the
time
to
do
it.
F
If
we
could
somehow
fund
it,
then
we
might
be
able
to
find
someone
who
wants
it
and
is
willing
to
work
if
they're
like
funded
separately.
I
think
that
if,
if
what
you
guys
say
is
true-
and
there
are
literally
no
no
application
developers
who
actually
care
about
a
standardization
process,
then
maybe
we
just
don't
need
a
standardization
process
for
application
level.
Stuff.
H
F
Sure
I
mean
the
the
anarchist
way
to
deal
with.
This
is
everybody's,
build
their
tokens
and
they
kind
of
can
consolidate
on
a
standard
similar
and
how
and
usually
it
means
following
the
most
popular
thing
and
so
metamask.
The
most
popular
thing
for
wallets,
there's
no
place
place
to
do
wallet,
standards
right
now,
and
so
everybody
just
copies
metamasks
api
and
so
metamask
gets
to
find
whatever
api
they
want
and
at
some
point
in
the
future.
F
When
someone
is
more
popular
in
metamask,
then
they
get
to
define
the
api
and
that's
the
government,
the
anarchist
governance
system
for
standardization-
and
I
mean
the
reason
I
mention
this
is
just
that,
like
the
world
will
not
end
if
we
end
up
in
that
universe,
perhaps
it's
not
great,
but
it's
like
things,
won't
totally
break.
B
H
Like
right
now,
I
feel
like
there
are
people
who
want
to
standardize
things
and
they
want
to
like
work
on
improving
application
standards
and
like
their
own
niche,
but
there's
no
person
who,
like
does
the
role
that
you
do
like
you,
do
a
lot
of
other
things
other
than
just
like
drive
certain
things,
but
just
having
that
person
who's.
Like
always
connecting
always.
You
know.
H
H
Right,
like
I
don't
know,
I
think,
there's
we're
starting
to
see
some
of
these
things
emerge
like
the
wallet
devs
are
wanting
to,
like.
I
don't
know
we're
basically
coercing
them
into
like
communicating
amongst
each
other,
and
then
I
think
nft
people
would
really
like
to
have
some
more
work
on
figuring
out.
What
in
a
teacher
look
like
in
the
future,
but
I
don't
know
there
doesn't
really
seem,
like
you
know,
a
higher
level
of
that
to
like
push
those
groups
forward.
It's
just
like
yeah.
H
Yep
so
anyways,
that's
probably
enough
to
talk
about
that.
I
did
want
to
just
say
one
other
thing
on
that
working
group
topic.
H
If
anybody
has
a
recommendation
for
who
can
help
sort
of
lead,
a
standard
on
urls
related
to
ethereum
and
maybe
blockchains
in
general,
because
there's
about
three
eeps
in
flight
right
now
regarding
this
hasn't.
H
A
A
A
Yeah,
maybe
we
can
share
this
information
out
and
check
if
anyone
from
community
is
willing
to
take
a
lead
on
this.
You
are
a
standard
for
change.
I
may
be
reaching
out
to
the
nfd
group.
I
know
one
group
is
active
there.
Maybe
if
someone
from
that
group
working
on
a
different
application
layer,
standard.
H
A
A
Cool,
I
know
we
had
good
discussion
today,
but
in
the
interest
of
time
I
think
we
should
move
forward.
We
have
still
more
items
to
check
on,
but
before
we
move
what
would
be
the
like
general
consensus
on
this
particular
item?
Is
it
fair
to
say
that
we
are
letting
it
rest
as
it
and
no
more
progress,
because
I
know
kilian
is
here
to
maybe
help
out
if
there
is
any
interest
in
splitting
the
repo.
F
So
I
think
we
are
definitely
not
at
a
point
we're
ready
to
start
working
on
the
technical
side
of
like
actually
splitting
the
repo
we're
still
deep
in
discussion
of
whether
we
should
split
the
repo
and
we're
supposed
to
etc,
and
it
sounds
like
killians
was
looking
to
help
out
on
the
technical
side.
So
I
don't
think
we're
there.
Yet.
C
A
Thank
you
well,
thank
you.
Let's
move
on
to
the
next
item,
though
I
don't
see
sam
on
the
call.
Next
item
is
related
to
him.
Getting
some
permission.
A
Sam
wilson
has
been
active,
actively
engaged
in
eip,
editing
and
yesterday
in
the
internship
meeting
he
mentioned
about
having
some
permission
to
maybe
override
what
I
know.
This
permission
is
limited
right
now,
but
I
was
wondering
if
there
are
any
thoughts
on
getting
more
people
involved
into
it
or
what's
the
current.
F
My
general
feeling
from
a
security
standpoint
is
you
generally.
The
security
best
practice
is
to
limit
who
has
access
to
things,
and
so
currently
my
preference
is
to
keep
the
number
of
people
with
override
power
low,
and
so,
if
we
are
going
to
add
sam,
I
would
like
to
remove
someone
else.
That
could
be
me,
I'm
fine
with
that.
F
Yes,
yeah,
that's
fine,
like
I
think
keeping
it
down
to
three
is
reasonable.
I'd
be
okay
with
that
at
some
point,
we'll
probably
have
to
remove
one
of
the
three
of
us.
If
we
get
a
full-time
bot
author
who
needs
to
make
edits,
but
we
can
do
cross
that
bridge
when
we
get
there
and
I
volunteer
to
be
removed.
A
All
right,
I'm
assuming
like
having
sam
added,
is
it
something
that
can
be
done
by
either
of
you.
A
A
Okay,
cool
item
number
four
is
eip's
bot
related
discussion,
updates
agreement
on
merging
prs
and
closing.
So
we
are
trying
to
bring
out
the
pull
requests
which
are
already
existing
matt.
I
know
the
the
eipv
repository
you
know.
A
Most
of
the
quotes
were
added
by
you,
so
if
you
can
maybe
look
into
the
pull
request
added
over
there,
it
seems
like
they
are
there
for
for
some
time
and
let
the
proposer
know
if
that
can
be
moved
further
or
if
there
is
anything
that
can
be
improved
to
push
it
forward.
Similarly,
for
eip
bot,
I
don't
know
jose
is
on
the
call
yeah.
If
you
have
anything
to
begin
with,
and
then
probably
we
can
look
into
pull
requests
which
are
open.
D
Hi
well,
basically,
yeah.
There
are
five
issues
that
has
been
already
coded
into
the
pull
request,
but
mikka
and
all
and
all
the
guys
are
aware
of
that.
I
mean
there
has
been
a
very
active
discussion
and
there
are
already
eight
more
issues
that
we,
I
would
say
I
will
take
the
risk.
We
basically
agreed.
So
I'm
gonna
start
to
to
code
those
during
this
week.
A
Awesome,
I
think
we
are
getting
quite
a
few
discussion
in
the
eap
bot
issue
issues
and
pull
requests,
but
eipv
is
not
getting
that
kind
of
attention.
I
know.
Mika
has
showed
his
limited
interest
on
that
because
of
his,
like
maybe
technical
expertise
with
ruby.
But
sorry
was
it
ruby?
No,
it
wasn't
yeah.
A
A
I
think
in
the
last
meeting
we
had
mario
on
the
call
who
I
suppose
will
be
helping
out
with
the
eipv.
A
So
let's
have
one
on
one
like
if
you
can
maybe
take
care
of
the
ap
part
issues
or
and
let
mario
be
looking
into
eipv.
I
just
wanted
to
bring
it
up
to
this
discussion,
because
I
see
that
there
are
already
a
couple
of
pull
requests
which
may
need
attention.
A
D
D
That
yeah,
that
that's
okay,
I
will,
let's
see
how
how
mario's
keep
keep
moving
forward
good
agree.
A
A
Yeah,
that's
on
it.
If
there
is
no
further
updates
on
that,
maybe
we
can
move
on
to
item
number
five.
The
number
five
is
merge,
aetidium
cathedrals
into
ethereum
organization.
A
This
was
proposed
by
panda
pip
one
and
we
discussed
in
the
last
meeting,
and
our
suggestion
was
if
we
can
get
more
information
from
him
on.
Why
does
he
want
to
do
that?
I
have
added
the
link
here
which
suggests
that
he
has
added
some
of
his
comments
saying
like
why
he
thinks
if
this
can
be
added
to
the
repository.
A
A
So
you
suggest
that
adding
this
will
maybe
increase
the
discoverability
of
ech
programs.
Sorry
I
mean
four
five
items
are
there.
You
have
mentioned.
F
I
thought
I
already
commented
on
this
one,
but
I
don't
see
it
my
general
feeling
is
I
like
the
cat
herders
having
autonomy
and
not
being
governed
by
and
constrained
by,
ethereum
foundation,
rules
and
administration
and
whatnot,
and
so
I'm
weakly
against
integration.
I
don't
feel
super
strongly.
I
just
I
generally
feel
like
there
should
be
a
very
strong
reason
to
merge
two
distinct
organizations,
and
I
just
don't
see
the
strong
reason
here.
I
see
some
weak
reasons
like
the
reasons
you
mentioned.
F
I
think
they're
not
reasonable,
not
unreasonable,
but
I
don't
think
they're
strong
enough
to
warrant
taking
away
that
autonomy.
A
A
They
are
working
in
association
with
community
to
maybe
help
out
in
whatever
way
possible.
So
unless
we
have
like
very
strong
needs
and
to
put
it
under
the
head
of
ethereum
foundation
or
ethereum
repository
sounds
fair.
Anyone
who
is
strongly
in
support
of
the
proposal
that
cat
header
should
be
merged
into
ethereum.
A
Yeah
daniel
see
your
hand
raised.
I
Yeah,
I
don't
have
an
opinion
about
this
specific
point,
but
one
of
the
things
that
I
felt
as
I
was
trying
and
I'm
still
trying
to
understand
the
ecosystem
is
you
know,
cat
herders,
vip
editors,
ethereum
magicians,
it's
just
it's
a
lot
of
names,
a
lot
of
different
platforms.
I
I
don't
know
if
merging
into
ethereum-
I
don't
know
if
merging
into
the
ethereum
organization
would
solve
any
of
those
issues,
but
this
discussion
and
I
think
the
reasons
behind
this.
I
The
comment
relate
to
kind
of
the
lack
of
clarity
there,
or
at
least
the
perceived
lack
of
clarity.
A
Yeah,
I
see
a
very
good
suggestion
from
tim
about
having
a
page
on
ethereum.org,
explain
how
all
these
things
work.
I
know
there
is
a
community
page
on
ethereum.org
that
points
to
what
ethereum
cathode
is,
but
maybe
having
more
information
on
how
all
of
these
are
connected
and
how
the
process
actually
works
here
may
be
helpful.
A
All
right
moving
on
to
the
next
item
here
that
is
eip's
insight.
A
A
A
A
Next
item
is
eap
editors,
apprenticeship
meeting,
so
this
meeting
happens
every
two
weeks
one
was
completed
yesterday
I
have
added
link
to
agenda
and
the
video
is
already
out
people
who
are
interested
in
learning
about
eip
editing
process
are
invited
to
participate
in
this
meeting
and
share
their
questions
with
eap
editors,
so
they
be
able
to
become
a
reviewer
in
long
term
and
maybe
become
an
eap
editor
if
they
want
to
pursue
that
line
for
contributing
ethereums
as
from
the
perspective
of
a
reviewer.
A
A
A
Async
communication
is
going
on
and
discussion
is
on.
If
our
individual
channel
action
item
number
two
is
collect
more
info
on
panda
peeps
comment:
we
did
discuss
about
it.
A
Item
number
three:
jose
will
create
pull
requests
in
eap
box
github
and
he
shared
some
of
the
pull
requests
that
he
created
since
the
last
meeting.