►
From YouTube: EIPIP Meeting 75
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/213
A
Thank
you.
Everyone
for
joining
EAP,
IP
meeting
75
I
have
shared
agenda
in
the
chat.
We
are
going
to
discuss
open
issues
and
pull
requests.
We
will
continue
some
discussions
from
the
past
meeting,
followed
by
EIP
insight
and
EIP
editing
office
hour
updates,
but
before
we
get
into
the
agenda
item,
we
are
joined
by
one
new
EAP
editor,
who
has
recently
joined
the
team.
So
I
would
open
the
floor
for
him
to
provide
an
introduction.
If
that's
okay,.
B
So,
basically,
I
am
a
CL
that
I've
involved
with
load
star,
primarily
and
as
well
as
I.
Also
work
for
ethereum.js,
so
I
have
a
little
bit.
I
have
deeper
understanding
of
Cl
clients
and
I'm,
getting
a
little
bit
more
understanding
of
the
Year
client,
so
I'm
sort
of
able
to
see
a
little
bit
more
picture
of
the
entire
landscape,
and
hopefully
I
can
contribute.
A
Likewise,
all
right,
so
we
can
go
ahead
and
start
with
the
the
discussion
and
issues
listed
on
the
agenda.
We
have
collected
it
from
the
EAP
GitHub
repository
as
well
as
from
the
Discord
channel.
The
points
for
discussion
number
one
here
is
allow,
including
both
an
email
and
a
GitHub,
username
I
think
this
was
proposed
by
Panda
peep,
so
Panda.
If
you
would
like
to
explain-
and
we
can
collect
editors
feedback
on
this
one.
D
C
Yeah
just
a
little
bit
of
work
in
upw,
not
too
bad.
So
if
we
want
to
do
it,
we
can
so
what's
the
advantage
of
doing
it
just
makes
it
like
easier.
C
Right
I
mean
the
current
recommendation
is
just
to
repeat
from
your
example
here,
my
name
once
with
email
and
once
with
GitHub.
So
I
guess.
The
advantage
is
what
you
would
have
a
single
author
entry
with
both
as
opposed
to
two
yeah.
C
C
Yeah
and
so
the
meta
tags
and
well
I,
guess
just
the
meta
tags
and
RSS
could
benefit
from
it.
Being
one
author
item
correct,
okay,
yeah,
I,
guess
I'm
in
favor
of
this
we
can
make
that
change.
D
Seems
minor
enough
that
we
can
probably
merge
it
without
do
it
without
my
client
here
yeah.
C
Just
said
yes,
do
you
want
to
do
a
username,
then
email,
email,
then
username
or
both.
D
What
is
the
order?
The
eip1
has
it
in
right
now.
C
D
A
C
A
A
D
Oh
yeah
that,
basically,
in
order
to
get
listed
on
Google
Scholar,
you
need
to
have
a
proper
bibliography
and
I
think
what
what
we
can
do
pretty
easily
without
much
effort,
especially
now
that
we're
switching
to
the
new
build
system
or
hopefully,
we'll
end
up
switching
to
the
new
build
system.
We
we
can
then
have
a
new
entry
in
the
Preamble
that
basically
it's
like
requires.
In
fact,
it
could
literally
be
a
yaml
list
of
Erp
names,
but
that
also
accepts
external
Banks
such
as
dois,
etc,
etc,
etc.
D
And
then
it
would
generate
a
bibliography
at
the
bottom
before
the
before
right
after
the
or
perhaps
before
the
copyright
section.
C
Yes,
I
think
generating
a
bibliography
is
the
correct
thing
to
do.
I
mean
we
need
to
do
it
anyways
because
of
the
CSL
Jason
stuff.
My
only
complaint
here
is
I.
Don't
think
we
should
get
rid
of
requires
because
it's
like
90
of
references
are
going
to
be
to
other
eips
I'm.
E
C
Okay
and
then
for
like
dois
and
other
stuff,
it
would
be
like
a
full
Json
thing
and.
D
A
A
A
A
All
right,
I
thought
that
it
is
important
to
make
a
mention
in
this
meeting,
because
this
is
kind
of
you
know
a
public
awareness
as
well.
Also,
if
people
aren't
following
issues
diligently,
then
they
would
be
at
least
aware
of
it,
and
if
there
are
any
concern
they
can
definitely
go
back
and
add
their
thoughts
in
the
issue
that
we
are
discussing
here.
A
Okay,
moving
on
to
the
next
one
is
discus
policy
to
add
a
champion
or
co-authors
to
an
EIP.
So
this
item
has
been
added
from
ech
Discord,
so
latest
discussion
on
adding
Champion,
EIP
editors
and
others.
Other
users
have
already
shared
their
thought
and
we
do
have
some
text
added
in
eip1
defining
the
role
of
champion.
However,
it
will
be
a
good
idea
to
revisit
and
possibly
make
changes
if
needed
so
yeah.
D
A
A
A
Well
yeah,
if
you
want
to
pull
out
any
EIP
from
statement
status,
I'm
just
sharing
the
information
that
I
am
carrying
from
the
past.
The
idea
was,
it
should
include
author's
permission
to
keep
the
number.
If
they
are
willing
to
understand
it,
then
only
the
same
number
will
be
kept
on
the
proposal.
Otherwise,
if
author
decides
not
to
unstagnant
that
and
someone
else
decide
to
come
up
with
a
new
proposal
with
the
entire
like
a
copying
pasting,
the
entire
content,
the
EIP
number
would
not
be
the
same.
D
That's
what
I'm
suggesting
the
adoptable
field
would
literally
be
authors,
saying
basically
giving
their
approval
in
advance
of
its
stagnating,
like
we
give
our
approval
to
whoever
wants
to
pick
this
up.
It's
not
something
that's
by
default.
It
requires
an
authority
authors
to
give
approval,
but
it's
just
that
the
approval
is
given
at
the
beginning
of
the
process
when
the
authors
are
reachable,
rather
than
at
the
end
of
the
process
where
the
authors
will
are
clearly
unreachable.
Since
the
proposals
of
disagnant.
A
C
A
We
can
bend
it
I
wonder
if
anyone
else
has
any
thoughts
on
it.
So
definitely
We're
not
gonna
make
any
decision
in
absence
of
math,
so
we
can
at
least
collect
thoughts
if
people
have
any
different.
C
C
C
Oh
yeah
I
was
just
saying,
like
yeah
I
think
what
you're
doing
is
fine
I
I,
think
that
is
the
best
we
can
do
today
without
adoptable
and
I.
Don't
think
we
need
to,
but
I
don't
think
we
can
discuss
adoptable
without
Matt.
So.
E
A
A
Fair
enough
I'm
gonna
bring
this
in
the
next
meeting.
I
hope
Matt
joins
then
and
yeah.
Now
we
can
move
on
to
the
next
item,
which
is
kind
of
information.
It's
more
of
an
announcement
that
probably
invite
a
Viewpoint,
though
it
is
really
not
that
of
a
concern
of
community
at
large,
because
mainly
it
is
related
to
Dev
worker,
which
is
going
behind
the
scene
and
the
one
who
is
doing
most
of
the
thing
has
proposed
this.
A
So
it
is
about
moving
away
from
Jekyll,
as
many
of
us
know
that
the
present
EIP
tooling
requires
Ruby,
and
at
present
we
don't
have
much
contributors
of
Ruby
or
Ruby
expert
to
support
the
infrastructure,
so
Pana
Peep
and
EIP
editors,
who
are
mainly
maintaining
this,
has
a
suggestion
to
move
out
of
this
so
Panda.
If
you
would
like
to
give
more
background
to
this,
and
what
where
we
are
at
the
at
the
moment,.
D
D
So
this
is
using
the
entire
workflow,
so
the
GitHub,
the
GitHub
actions
thing
that
that
will
automatically
build
it
and
I
have
it
sending
it
to
this
website
right
now,
since
it's
on
my
Fork
of
the
repo,
so
the
things
that
would
need
to
be
happen
is
first,
the
pr
that
adds
this
need
needs
to
be
merged
and
then
secondly,
secondly,
in
the
settings
GitHub
Pages
needs
to
be
switched
to
the
action
based
workflow
instead
of
the
branch
based
works,
though,
and
then
this
and
then
the
and
then
the
URL
needs
to
be
set
to
vips.etherium.org.
D
D
It
has
all
the
features
of
the
previous
website,
plus
this
nice
little
search
feature
I
added
it's
in
JavaScript
script,
so
we
can
add
so
and
in
fact
the
actual
code
will
be
on
the
eip's
repository.
So
changes
to
the
website
can
be
even
managed
by
straight
up
using
the
EIP
review
bot
additionally,
actually
I
think
that's
it
well.
I
mean
obviously
it's
JavaScript
and
we
have
at
the
very
least
I
know.
Javascript
and
I
also
know.
Sam
knows
a
little
bit
of
JavaScript.
A
A
So
can
you
please
once
again,
like
summarize
what
is
needed
here?
Do
we
need
consensus
on
switching
from
all
the
editors
and.
A
C
Yeah,
no,
this
looks
amazing.
Besides
not
being
able
to
click
on
the
search
bar.
Oh
I
was
able
to
click
on
it
that
time.
It's
really
weird,
but
yeah
I
know
it's
great
like
good
job
on
this.
Thank.
D
A
A
Let's
move
on
to
the
next
item,
which
is
agenda,
request,
okay,
so
this
is
from
the
issue
that
was
added
on
eipip
GitHub
repository,
and
the
number
here
is
215.,
so
the
proposal
requested
this
issue
to
be
considered
for
this
call,
but
I
know
that
it
was
being
blocked
by
one
of
the
editor,
yeah
and
I
think
he
would
like
to
mention
Panda
why
you
think
it
should
be
blocked
at
the
present
state.
D
Four
percent,
the
only
thing
I
was
blocking,
was
that
I
would
like
to
have
seen
that
split
into
two
different
PRS
Additionally.
The
website
rewrite
just
does
all
of
that
already.
C
Maybe
the
the
correct
approach
here
is
to
ask
full
descent
to
take
a
look
at
your
rewrite
and
see
if
it
solves
the
same
problems
and
just
explicitly
ask
them
to
take
a
look
at
it.
That
would
probably
solve
any
kind
of
like
I.
Don't
know.
Frustration
with
the
process.
D
C
So
I
would
just
pick
him
and
be
like
hey.
You
know.
What
do
you
think,
like
we've
been
working
on
a
rewrite
over
here,
would
love
to
get
your
feedback
on
it,
see
if
it
solves
the
same
problems
and
we'll
just
see
what
happens
after
that
I
mean
I
can
even
do
that
if
you
want.
D
I
would
definitely
like
it's
like
you
to
at
least
review
the
website.
Yes,.
A
And
to
address
the
kind
of
frustration
that
can
bring
to
anyone
with
the
present
process
or
with
the
dynamic
process
that
we
are
trying
to
follow
here
is
we
have.
We
are
sharing
this
feedback
form
for
EIP
authors.
That
is
our
next
agenda
item.
So
far,
we
have
received
responses
from
only
ERC
category
authors,
so
please
core
interface,
networking,
informational
or
meta
authors.
If,
if
you
have
documented
a
proposal
for
ethereum
repository,
consider
responding
to
the
survey,
this
is
just
a
feedback
form
less
than
five
question.
A
I
believe
it
is
just
to
collect
your
present
thought
in
the
process
and
also,
if
you
have
any
suggestions
that
we
could
probably
bring
up
in
future
eipa
meeting
for
consideration
of
changes.
D
E
A
A
Yeah
mostly
because
that
is
neither
a
part
of
upgrade,
and
also
that
is
not
a
like
very
popular
ERC
category,
but
they
are
still
into
existence,
at
least
for
now.
A
But
yeah
we
do
have
common
authors:
authors
who
are
contributing
into
core
EIP
are
generally
authors
who
are
contributing
to
networking
and
interface
category
of
proposals,
and
apart
from
that,
we
do
have
a
lot
of
ERC
authors.
So
please
take
out
time
less
than
two
minutes.
It
would
take
and
respond
to
this.
Let
us
know
what
you
think
is
not
right
thing
for
you
and
you
would
like
that
to
be
changed.
A
Okay,
moving
on
to
item
number
two,
that
is,
discussion
continued
from
the
earlier
meetings.
The
first
one
here
is
adding
CL
devs
as
EAP
editor
and
a
new
ERC
editor.
We
met
our
new
core
EIP
editor.
We
are
recently
joined
by
another
ERC
editor,
who
is
Victor.
People
have
seen
him
raving
ERC
category
proposals
on
EIP
repository
for
over
six
months,
I
believe
now
so
yeah.
A
He
is
very
much
familiar
with
the
process,
but
unfortunately
he
is
not
here
today
had
some
power
issues
or
so,
but
we
hope
to
have
him
in
future
meeting.
Thank
you
both
of
you
for
joining
us
and
helping
out
with
the
EIP
process.
A
The
next
item
listed
here
is
thoughts
on
Asia
Pacific,
APAC
friendly
times
on
infrequent
recurring
period,
yeah
any
thoughts.
If
people
may
have
on
this
one.
C
A
I
mean
it
is
I
feel
like
it
is
useful
or
helpful
when
people
know
that
what
time
that
meeting
is
going
to
happen
so,
instead
of
having
having
it
at
different
time,
can
we
try
to
move
it
like
to
the
Asia,
Pacific,
obviously
friendly
time
zone,
which
is
not
that
bad
and
that
could
be
like
the
time
when
we
have
other
client
meetings?
Will
that
be
a
good
idea.
A
That
is
1400
UTC
I'm.
So
sorry.
A
The
same
day
just
the
time
at
1400
UTC,
so
you
know
most
of
the
CL
Dev
the
Elder
meeting.
Most
of
them
are
at
1400
UTC
and
we
know
that
we
have
participants
throughout
the
globe,
so
they
are
participating
at
that
time.
A
For
for
a
couple
of
weeks,
only
just
a
reminder
like
March
is
right:
there.
C
A
Rotation
is
something
that
I'm
a
little
carry
off,
but
I
don't
know
because
you
know
when
we,
when
we
go
out
and
spread
the
message
that
join
the
meeting,
we
generally
try
to
give
them
a
sense
of
time
like
when
we
are
doing
it
earlier.
It
was
1500
UTC.
Since
we
started,
then
we
moved
to
14.
Then
people
suggested
1600,
and
here
we
are
going
back
again
to
1400,
which
I
think
is
a
good
idea,
but
when
it
comes
to
rotation,
what
is
the
alternate
time
suggested
here.
E
A
Because
that
would
also
work
for
the
newly
joined
editor,
because
he
is
also
from
Asia
Pacific.
And
what.
A
A
E
A
E
B
E
A
D
So
I
think
the
issue
here
comes
down
to
what
building
meta
versus
information
will
mean,
because
I
interpret
meta
to
be
literally
basically,
definitions
like
because,
in
my
opinion,
you
can't
ignore
a
definition.
You
have
to
choose
one,
but
at
the
same
time
you're
not
beholden
to
any
specific
definition,
so
it
could
be
informational.
C
So
a
meta
EIP
would
be
something
like
in
this
specific
instance:
If
This,
Were,
A,
meta
EIP.
It
would
be
an
EIP
changing
the
process
to
not
allow
people
to
use
this
term
unless
it
conform
conforms
with
the
definition.
So
it's
a
meta
EIP
describing
the
EIP
process
informational
is
just
here-
is
a
definition
for
a
term
feel
free
to
use
it.
If.
D
C
D
A
I
think
the
another
Advantage
with
that
being
in
meta
right
now
could
be
like
you
know,
we
are
going
to
see
a
lot
of
changes
coming
up
with
respect
to
self-destruct.
This
is
just
an
announcement.
I
agree
that
it
looks
more
like
an
informational
at
this
point
of
time,
but
there
are
chances
that
it
could
serve
as
a
matter
of,
and
we
should
see
some.
You
know
some
more
proposals
coming
down
the
line
for
the
support
of
that.
C
C
D
C
Right
but
there's
no
definition.
For
a
token,
we
we
have
a
like
Eep
20
defines
a
standard
that
uses
the
word
token,
but
we
don't
have
a
separate
informational
EIP
that
just
defines
the
word
token.
Okay,
fair
enough,
like
I
I,
would
have
no
problem.
If
you
know
forget,
it
was
a
full
descent
that
was
doing
this.
One
I.
E
C
C
This
is
the
definition
of
fully
evm
equivalent
and
that
would
be
a
perfect
place
to
Define
it,
but
on
its
own,
without
some
kind
of
a
technical
system
that
it's
describing
it's
it's
pointless
to
standardize
the
term
because,
like
the
reason
they're
doing
this,
as
far
as
I
can
tell,
is
so
that
marketing
teams
can
point
to
it
and
be
like
hey.
My
evm
is
fully
evm
equivalent
according
to
this
particular
EIP
and
like
that's
just
going
to
turn
into
like
a
war
that
I
don't
want
to
touch
with
the
EIP
process.
C
C
A
And
maybe
just
to
I
think
if
I'm
getting
it
to
write
on
Sam's
Point,
even
I
would
be
more
happy
to
have
it
added
when
it
is
supported
by
one
of
the
or
technical
specification.
I
mean
not
a
technical
specification
in
general,
but
I
meant
by
like
proposal,
which
is
like
29.82
the
serenity
phase
zero.
When
it
went
into
the
informational
category,
it
was
blocked
in
the
beginning.
A
If
the
present
Proposal
with
a
6269,
the
full
evium
equivalence
contains
this
kind
of
element,
then
it
would
make
more
sense
to
have
it
added
it
in
the
ethereum
repository
rather
than
a
promotional
tool
for
any
other
project.
To
say
that
we
are
fully
evm
equivalent.
A
Okay,
so
we
do
have
this
item
added
in
the
pull
request,
form
that
is
6269
I,
think
we'll
try
to
say
if
we
get
any
consensus
on
the
pull
request
and
if
it
is
merged,
if
not,
then
we'll
bring
it
up
in
the
next
meeting.
A
D
A
D
A
E
A
Okay,
so
we
have
a
tie
here.
I
can
see
Victor
left
some
comment.
He
seems
to
be
in
favor
of
it
with
certain
options
and
Matt
is
unavailable
and
given
sensitive
in
favor.
So
what.
D
D
C
D
C
D
C
I
guess
if
this
is
going
to
keep
coming
up
over
and
over
again
on
the
eipip
meetings,
I
guess
I'd
be
okay
with
a
optional
privacy
consideration
section
at
the
same
level
as
security
considerations.
C
D
A
D
If
it's,
if
it's
clear
what
the
section
is
about,
I,
think
that
that
issue
can
be
mitigated,
maybe
like
maybe
it's
something
like
implementation
considerations.
C
I
feel
like
that's
what
it
used
to
be
called
a
long
time
ago,
but
I
might
be
wrong
or
at
least
that
this
discussions
come
up
before
our
privacy
considerations
really
implementation.
Well,
yeah
I
mean
there
might
be
considerations
that
aren't
necessarily
for
implementers.
They
might
be
on
the
user
side
or
or
something
like
that.
I
don't
know.
A
Okay,
I
think
here
are
two
things
we
are
trying
to
discuss
when
we
are
trying
to
move
an
EAP
into
like
you
know,
final
status,
we
are
trying
to
provide
a
standard
that
could
be
used
by
any
other
application,
developer
or
project
a
developer
to
have
it
implemented.
So
the
implementation
or
the
consideration
that
we
should
like
to
have
it
over
there
should
be
for
the
implementers
only
not
for
the
end
users
for
end
users.
The
project
could
be
providing
the
take
consideration
or
any
other
consideration
that
they
may
have
for
implementers.
A
If
there
are
any
consideration,
they
are
generally
provided
in
security
concentration
if
that
is
related
to
security,
otherwise,
like
privacy
concentration,
they
might
want
to
give
it
a.
You
know
thought
on
how
many
that
kind
of
proposals
do
we
receive,
and
do
we
really
need
to
have
privacy
consideration
a
room
in
the
EIP
Repository.
D
A
I'm
open
not
to
bring
it
up
again
because
we
have
brought
it
for
two
weeks.
I
mean
like
two
meetings
consecutively,
but
maybe
we
can
take
it
from
the
pull
request
and
try
to
collect
more
consensus
from
editors
and
people
over
there,
because
this
is
something
which
is
sounding
like
we
don't
have
a
consensus
and
we
do
have
to
do
additional
editors
missing
on
the
meeting
is
that
okay,
I.
A
Moving
on
to
the
next
sub
item,
which
is
a
change
requested
for
final
eibs,
though
we
know
that
we
do
not
encourage
making
any
changes
to
any
eaps
which
are
into
final
status,
the
way
are
still
getting
some
request.
I
have
added
two
pull
requests
here.
The
first
one
is
six
three
three
zero,
which
is
to
update
5192
and
the
other.
One
is
six
three
one,
four,
so
yeah.
Let's
talk
about
6330.
What
do
people
think.
D
C
This
isn't
a
soul-bound
nft
as
far
as
I'm,
like
my
understanding
of
soulbound,
goes
and
but
it's
also
finally
IP
so
I
I
personally
I
just
think
it's
it's
final.
It
doesn't
change.
We
move
on.
D
The
best
that's
fair
enough,
but
at
the
same
time,
I
as
as
previously
mentioned,
I
feel
like
final
status
altogether,
should
be
there
to
demonstrate
how
how
much
the
standard
can
change.
D
A
Yeah
had
it
been
some
sentences
that
is
changing
in
the
you
know,
documentation
could
have
been
fine,
but
changing
the
title
altogether
is
not
gonna
reflect
good
on
us.
As
my
heart
I
mean
like.
If
there
are
implementers
for
this
particular
eib,
there
could
be
one
or
two
or
a
d
Max
five
projects
implementing
this,
so
we
are
restricting
a
damage
for
five
projects
instead
of
like
re-announcing
to
the
world
that
this
is
something
that
is
possible
even
after
an
EIP
getting
into
final
status.
They
can
request
for
the
name
change
there.
A
Okay,
we
can
probably
discuss
about
the
next
PR,
which
is
PR
number
six
three
one
four
and
it
is
to
request
changes
to
one
of
the
most
popular
EIP
eib
1559,
and
it's
about
remove
empty
test
cases.
D
So
yeah
there
is
literally
a
test
cases
section
with
the
word
to
do
in
it
Capital
all
caps.
That's
literally
the
that's
literally
the
content
of
the
test
cases,
section
yeah,
one:
five,
five,
nine,
so
I
think
what
happened
is
that
Cascades
are
mandatory
for
core
eibs
and
they
just
forgot
to
do
them,
but
I
would
argue
that
it's
probably
worth
just
removing
them
just
because
it
looks
bad
to
have
to
do
written
on
it.
A
I
mean
we
cannot
deny
that
there
were
cases,
because
we
are
talking
about
eip1559.
However,
we
would
not
have
added
the
link
because
the
at
that
time
there
was
this
policy
of
not
adding
link
to
outside
the
repository,
so
yeah
I'm
kind
of
okay,
I,
don't
know
what
other
people
think
of
removing
this
to-do
section.
D
A
Okay,
so
do
we
need
any
author's
permission
here.
E
A
So
we
are
agreeing
to
merge
six
three
one,
four,
all
right.
We
have
five
minutes
more.
We
already
have
yeah.
Please
go
ahead.
I.
D
Guess
we
could
discuss
seven
four,
seven.
Twelve
final
change.
A
Oh
I'm,
sorry,
it
is
not
listed.
Can
you
please
help
us
with
the
number.
D
Let's
see
five
four
five,
seven,
this
thing,
so
this
was
one
where
I
think.
Oh,
and
it
said
this,
this
PR
is
update.
So
what
happened
was
that
712,
due
to
an
Erp
W
bug,
got
actually
merged
with
two
specification
sections
without
anyone
knowing
merged
as
final
with
no
with
two
specification
sections
that
are
mutually
incompatible.
A
So
what
is
the
proposal
here?
Are
we
suggesting
to
merge
it
because
I
heard
you're
mentioning
it's
out
of
date,
yeah.
D
We
just
simply
close
it
I'm,
just
gonna
I'm,
just
gonna,
actually
manually,
go
into
the
pr
and
fix
it
for
the
authors
of
this
PR.
If
I
can
find
where
the
second
specification
section
begins,.
D
Okay,
so
now
I
believe
it
is
up
to
date,
so
there
were
two
errors:
one.
There
were
two
specification
sections
the
that
should
not
have
been
that
there
were
there's
an
additional
specification
section
that
shouldn't
have
been
there
and
some
stuff
left
over
from
the
forking
of
the
original
ethereum
design
messages
at
uip.
D
C
I
don't
think
backwards.
Compatibility
is
the
gold
standard
for
this
like.
If
someone
were
to
write
e1559,
let's
say
and
completely
had
the
wrong
calculation
in
it
from
what
all
the
clients
made,
the
Eep
would
have
to
be
updated
to
match
what
the
clients
implemented.
C
C
Right-
and
that
was
five
four
five,
seven.
D
D
It
has
been
needing
author
approval
for
months
now.
I
think
it
is
safe
to
say
that
all
the
authors
have
gone
AWOL
all.
A
It's
it's
just
a
minute.
I
think
I
have
some
background
here.
There
was
one
cat
heard
us
William
Schwab,
who
has
been
working
with
ramco
for
some
time
to
push
this
proposal
towards
the
final
status.
I
think
we
can
probably
have
reached
out
to
him
to
reach
to
Remco
to
like
if
we
need
any
kind
of
permission
there,
because
I
think
this
proposal
was
in
stagnant
for
a
very
long
time,
I
mean
if
that's
okay.
D
Actually
I
from
the
looks
of
it,
it
looks
like
there's
even
some
more
stuff
that
needs
changing
yeah.
This
is
it's
hard
to
it's
hard
to
know,
what's
correct
here
and
what's
not
correct,
because
I'm,
seeing
some
I'm
still
seeing,
even
though
I
removed
the
duplicate
specification,
section
I'm
still
seeing
some
ethereum
signed
message
stuff,
which
should
not
be
in
there.
A
Okay,
we
are
at
times
so
I
think
this
could
be
like
left
here.
We
can
leave
this
conversation
and
we'll
try
to
look
into
this
pull
request.
Number
five,
four
five
seven.
Maybe
it
can
be
reviewed
again
and
see
if
we
get
response
from
authors
and
if
a
writers
are
confident
that
this
is
in
good
shape
to
be
merged,
we'll
take
it
from.
There
sounds
good.
A
Okay,
yep.
Thank
you
all
right.
We
are
at
a
time
I.
Just
quickly
wanted
to
share
about
the
month's
update
for
eips
inside
link
is
added
to
the
agenda.
We
have
vipsinsite.com
February
20023.
This
provides
us
the
information
with
all
the
proposals
which
we
have
moved
from
one
status
to
another
statuses
and
in
the
month
of
February,
we
have
received
three
final
eips
and
a
lot
more
changes
going
on
in
the
EAP
repositories.
A
You,
you
may
check
out
the
link
added
here
and
we
have
added
recording
to
EIP
editing
office
hour
people
who
are
interested
in
learning
about
EIP
documentation,
process
or
or
if
they
have
any
question
and
related
to
their
pull
requests.
They
are
always
invited
to
join
this,
so
they
can
have
a
conversation
directly
with
the
EAP
editor
and
we
will
try
to
help
more
proposal
towards
the
Final
Destination.