►
From YouTube: All Wallet Devs Meeting 15
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
There
all
right
so
welcome
to
all
wallet,
devs
number
15.,
sorry,
I
missed
the
last
one.
Today
we're
going
to
be
talking
about
some
updates
from
wallet
test
framework,
and
we
have
a
presentation
about
the
injected
wallet
registry
proposal
and
then
we'll
have
time
for
whatever
else
afterwards.
A
So
first
up
is
an
update
from
wallet
testing
framework.
If
you
haven't
been
following
along
and
if
you
haven't
shame
on
you,
it's
a
testing
framework
for
wallets
designed
to
do
n10
testing
from
the
perspective
of
a
Dap.
We
have
about
62
tests
right
now
and
we
just
finished
our
first
round
of
trying
it
out
with
different
wallets,
so
I'm
going
to
share
those
results
and
talk
a
little
bit
about
them.
A
I
want
to
make
it
very
clear
that
this
isn't
like
you
know
me
criticizing
your
wallet,
it's
equally
likely
that
the
test
is
broken,
and
similarly
it's
not
me
endorsing
a
wallet
because
I
have
no
idea
what
I'm
doing
so
without
further
discussion.
Let
me
show
you
what
the
results
are.
A
Yeah
once
I
find
the
button
there,
it
is
all
right.
So
this
is
a
very
manual
process,
so
we
went
through
and
tested
these
wallets
here,
so
we
have
Brave
Tahoe
frame,
encrypt
coinbase,
metamask,
okx,
token
pocket
and
a
bunch
of
ones
that
couldn't
connect
yeah.
So
on
the
top
we
have
Bray
wallet
and
taleho
or
Tahoe
I.
Guess
they
changed
their
name.
A
You
guys
passed
every
test.
We
have
so
good
job
again,
not
really
endorsing
you.
It's
just
cool
that
we
weren't
even
using
you
until
a
few
weeks
ago,
and
everything
passed
we
have
been
developing
with
frame
and
they
have
everything.
Working
except
sign.
Transaction
encrypt
also
has
a
really
decent
score,
but
has
some
problems
with
not
displaying
enough
information
to
fill
in
the
the
boxes
that
the
tests
require.
So
that's
in
the
notes,
so
coinbase
also
did
exceptionally
well
just
a
few
problems
with
hex
prefixes
missing.
A
So
no
zero,
X's,
tiny,
tiny
little
bug,
metamask
surprisingly
just
didn't
work
in
a
lot
of
places.
I
haven't
really
looked
into.
Why?
But
you
know,
if
anybody
knows
anybody
from
metamask
that'd
be
willing
to
work
with
me
on
debugging.
Let
me
know
that
goes
for
everybody
okx
and
token
pocket
both
died
in
the
same
place.
So
somewhere
around
the
get
filter,
changes
tests.
A
They
just
stopped
responding
to
requests
and
I'm,
not
sure
if
that's
a
problem
with
our
tests
or
with
the
wallet,
but
we're
going
to
be
looking
into
that,
and
then
we
have
a
bunch
that
didn't
even
connect
and
some
of
that's
because
I
don't
know
what
I'm
doing
and
I
think
orange
x
is
a
great
example
of
that.
Some
of
them.
A
We
can't
support
because,
like
sequence
and
exodus,
because
they
don't
support
custom,
RPC,
endpoints
so
yeah,
we
can't
test
them
and
then
bit
keep
failed
because
of
a
system
error
and
they
don't
provide
any
more
information
than
that.
So
I
have
no
idea
what's
going
on
there,
but
look
for
look
forward
to
more
of
these
kind
of
reports
as
we
build
more
tests
and
try
more
wallets,
you
can
follow
along
at
wtf.allwallet.dev
and
if
you
want
to
work
with
us
to,
you
know,
help
improve
your
score
or
fix
tests.
A
Reach
out
to
me,
I'm
on
Twitter
here
on
Discord
I'd
appreciate
it
it's
about
it.
For
me,.
A
Foreign,
so
anybody
have
any
questions
about
wallet
test
framework.
A
Oh
sure,
Shane,
I'll
I'll
reach
out
to
you.
After
what's
your
Discord
username.
B
B
I
figured
we'd
be
one
of
the
people
who
were
breaking
some
of
the
test
of
times,
because
we're
used
to
running
into
wallet
compatibility
issues
along
the
way,
so
very
awesome
work
at
this
and
I'm
looking
forward
to
using
this
kind
of
as
a
as
a
tool
that
we
can
grow
with
as
a
community
together,
so
that
we
can
make
sure
that
we're
hitting
compatibility
and
making
needs
here
on
dapps
going
forward.
So
thanks
for
doing
all
the
the
hard
leg
work
on
this.
C
Awesome
yeah
if
I
may,
of
course,
yeah.
Thank
you
so
much
for
putting
your
time
in.
It's
really
great
to
see
this
get
started.
C
I
was
wondering
about
running
these
tests
in
CI
and,
if
you
guys
have
any
tentative
plans
around,
you
know
facilitating
these
tests
being
run
against
various
wallets
various
branches
or
yeah.
Any
kind
of
strategy
for
for
running
this
automatically.
A
Yes,
we
do
actually
so
the
whole
goal
of
this
is
to
build
an
automated
testing
framework.
We
don't
want
to
have
to
be
clicking
on
buttons
all
the
time.
So,
if
you'd
like
to
you
know,
meet
with
us
and
figure
out
the
right
way
to
integrate
this
with
your
CI,
please
let
me
know,
because
I
need
to
do
that,
to
get
more
funding.
So
yeah
hit
me
up
on
Discord
and
we
can
talk.
B
I'm
definitely
interested
in
doing
that
on
on
our
side,
but
ours
are
probably
going
to
be
a
bit
different
because
we
would
probably
write
these
as
browser
tests
or
take
a
look
at
that
which
is
like
a
great
chromium,
specific
thing
in
order
to
to
fit
it
in
with
our
the
way
that
ours
work.
But
our
our
end
goal
is
to
see
this
work
very
similar
to
how,
like
the
web
platform,
tests,
work
and
I
know.
B
You
are
familiar
with
that
Sam,
but
I
don't
know
if
other
people
are
it's
basically
wpt.live.
B
B
So
my
goal
is
to
see
that
basically
the
same
thing
for
the
for
the
wallets
and
create
what
I
like
to
call
like
a
web
3
platform,
so
I'm,
hoping
that
we
can
kind
of
move
in
that
direction
because
effectively
what
I
see
coming
from
this
is
the
ability
for
us
to
start
iterating
on
new
apis
with
kind
of
an
opt-in
model
where
it's
like.
Some
people
may
support
them.
B
Some
may
not,
and
then
we
can
start
to
see
like
new
apis
coming
about
from
this,
which
allows
for
greater
functionality
within
wallets,
hopefully
higher
level
apis
for
things
like
signing,
so
that
we
can
get
some
better
ux's
as
well
and
kind
of
move
in
from
there.
A
Yeah
I
think
one
of
them.
The
motivating
like
use
cases
for
this
framework
is
to
Define
tests
up
front
that
then
wallets
can
Implement
like
later
on,
as
opposed
to
you
know,
one
wallet
doing
it
and
everybody
else
having
to
copy
them.
So
hopefully
we
can
be
a
little
bit
more.
You
know
integrated
and
interop
better.
A
I'm
glad
we're
aligned
so
bumblefudge
in
the
chat
has
asked
for
an
overview
of
the
architecture.
So
I
can
give
a
very,
very
brief
description
of
how
it
works.
And
then,
if
you
want
more
information,
there's
an
architecture
post
on
wtf.allwallet.dev.
A
And
that
goes
into
a
little
bit
more
depth
but
yeah
at
its
core.
It's
kind
of
like
there's
a
Dap
and
it
connects
using
window.etherium
in
the
completely
normal
and
average
way,
and
it
will
run
through
a
series
of
tests
and
those
tests
call
wallet
apis
and
then
the
wallet
does
whatever
it
has
to
do,
and
then
they
check
it
against
the
expected
output.
So
that's
all
normal.
It's
a
regular
testing
framework,
the
kind
of
magic
that
this
adds
is
there's
this
concept
of
glue.
A
So
right
now,
there's
only
one
glue
and
that's
the
manual
glue,
and
so,
if
you've
ever
been
to
actually
I'll
just
show
you
I
can
share
my
screen.
A
All
right,
so
this
is
wallow
test
framework.
Hopefully
you've
seen
it
see.
If
my
metamask
is
unlocked
here,
it
is
so
right.
Now
the
the
tests
are
connected
to
my
wallet
every
time
the
wallet
displays
a
message.
You
have
to
tell
the
testing
framework
that
something
is
going
on
so
in
this
case
we're
adding
an
ethereum
chain.
So
this
is
where
you
input
the
information
from
your
wallet,
so
you
copy
over
your
chain
name,
your
network,
URL.
A
There
we
go
and
it's
giving
me
so
I,
don't
know
if
you
can
see
my
metamask,
if
not
it's
fine,
but
so
it
gives
me
an
instruction
here.
So
now
it's
saying
your
wallet
should
be
showing
an
ad
chain.
Dialog
approve
this
request.
Okay,
I
will
approve
this
request
and
then
you
hit
complete
and
now
the
tests
start
running,
and
so
this
these
instructions
and
these
events
panels
here
they're
the
manual
glue,
there's
also
a
way
to
attach
using
websockets.
So
you
don't
need
to
actually
click
buttons
in
the
web
page.
A
You
can
just
send
messages
over
over
websockets
and
that's
how
I
would
imagine
most
of
the
automation
would
work
yeah.
This
is
the
output
from
the
test.
This
is
kind
of
what
it
looks
like
I
wasn't
really
planning
on
giving
a
demo,
so
I
don't
have
a
lot
prepared
here
but
yeah.
Basically,
the
architecture
is
while
it
pops
up
a
message.
A
Then
whatever's
driving
the
tests
has
to
click
one
of
these
buttons
or
send
a
websocket
message,
and
then
the
test
will
tell
the
driver
what
to
do
with
that
wallet
pop-up.
So
if
you're
familiar
with,
say,
selenium
or
Webdriver
tests,
it's
going
to
be
very
similar
to
that
kind
of
an
architecture.
B
Very
similar,
the
since
most
of
what
it's
testing
is
API,
driven
the
way
that
they
do,
it
is
basically
just
firing
them
into
API
calls
I'm,
not
sure
what
the
architecture
is
for
WPT
live,
but
the
effective
output
is
the
same.
So
I
don't
really
care
much.
It
doesn't
have
to
be
the
same
as
like.
What's
happening
in
WPT
live.
B
Yeah
the
the
whole
goal
that
I
see
behind
this
is
basically
so
that,
rather
than
us
having
to
copy
each
other's
implementations
for
interoperability,
we
can
instead
copy
the
test
framework
and
just
make
sure
that
we're
passing
the
test
framework
and
then,
if
we
notice
that
there's
still
differences,
then
that
leads
to
us
adding
new
tests
and
so
over
time.
This
becomes
kind
of
like
the
central
point
of
interop,
rather
than
any
particular
wallet.
That's
implemented
some
feature.
First,
foreign.
A
A
Hoping
for
so,
if
you're
ever
planning
on
adding
a
new
API
call
come
see
us
first
and
maybe
we
can
help
write
some
tests.
Yes,.
B
That
would
be
awesome
on
the
topic
of.
B
Sorry
I'm
forgetting
my
question.
It'll
come
back
to
me
in
a
second.
A
So,
to
put
a
link
in
the
chat
to
a
blog
post,
with
a
little
bit
more
detail
on
our
architecture
and
some
very
rough
diagrams.
So
if
you
want
to
share
it
around,
that's
the
place
to
do
it
or
the
thing
to
share
next
up.
We
have
our
presentation
on
eBay
6963,
assuming
we're
done
with
you
know.
The
wallet
test
framework
so
I'll
hand
it
over
to
Kyle
to
to
talk
about
that.
B
I
see
Shane
just
asked
a
question
and
my
question
actually
just
came
back
to
me
Shane.
Do
you
want
to
answer
or
ask
that
first.
B
A
So
we
use
mocha,
it
was
the
easiest
to
set
up
in
the
the
system
that
we
use
so
I
guess
a
little
bit
more
about
the
architecture.
There's
like
we
use
ganache
and
to
implement
a
fake
blockchain
that
the
wallet
connects
to
over
websockets
or
over
HTTP
rather,
and
so
we
run
mocha
and
ganache
in
a
in
the
browser
instance
and
then
or
in
the
in
the
web.
Page
itself,
I
looked
at
just
as
well.
Mocha
was
just
the
one
that
seemed
to
be
the
easiest
to
set
up.
B
And
you
mentioned
Argent
is
not.
You
haven't
figured
out
how
to
connect
it.
Yet,
how
do
you
envision,
like
account
abstraction,
while
it's
connecting
with
us.
A
So
right
now
we
support
just
window.otherium
because
that's
like
the
lowest
common
denominator,
I
think,
but
we
do
plan
to
add
support
for
other
connection
methods
as
long
as
there's
an
e.
What
is
it
1153
or
63,
whatever
the
the
one
that
defines
the
interface
provider,
we
should
be
able
to
support
it
eventually,
but
right
now
it's
just
window.etherium.
B
Okay,
awesome:
does
anybody
know
if,
like
account,
abstraction
wallets
are
following
that
I
think
it's
eleven
nine,
three
or
five
three
or
whatever.
D
I
was,
like
you
mean
by
a
kind
of
expression:
do
you
mean
like
safe
and
Urgent,
or
do
you
mean
like
the
next
gen
ones
that
are
using
the
four
or
four
like
the
new
kind,
because
I
I
know
1193
is
good
for
all
of
the
major
smart
contract
wallets
like
already
out
now.
B
Okay,
that's
good
to
hear
because
it
was
essentially
both
because
what
I'm
figuring
is
that
our
next
big
interop
problems
that
we'll
face
is
like
a
wallet
developers
is
going
to
be
what's
happening,
with
account
abstraction
how
eoa
wallets
fit
in
with
account
extraction
wallets
and
do
they
line
up
properly,
because
we've
already
seen
that
like
for
signing,
for
example,
I-
think
it's
they
need
to
I.
Don't
even
know
the
Erp,
but
it's
like
basically
is
signed
contract
method
in
order
to
actually
sign
some
of
these
things.
B
A
So
I'd
love
to
include
some
4337
style
wallets
in
in
our
testing.
So
if
you
know
of
any
I,
think
BLS
wallet
might
be
one
of
them.
Let
me
know
and
I'll
add
it
to
our
our
manual
tests.
B
B
I
personally,
don't
the
only
contact
I've
had
was
with
people
at
Argent.
Previously,
when
I
was
at
wallet,
wall
conference
hosted
by
wall
connect.
E
B
Okay,
so
I
didn't
actually
create
a
presentation
per
se,
but
I
can
do
a
demo
from
EIP
five
six.
What
is
it?
I'm?
Not
even
remembering
the
six
nine
six,
nine
six,
three
okay.
B
So
I'll
go
ahead
and
share
my
screen.
I've
done
some
original
testing
on
this
inside
of
Brave
nightly.
Can
everybody
see
that
properly.
B
Okay,
so,
in
order
to
test
this,
what
I
was
doing
just
going
to
erp6963
and
then
see
here,
I've
got
encrypting
zerion.
It
looks
like
they've
all
been
able
to
get
this
working
now,
so
just
creating
a
lot.
A
For
this
don't
remember,
6963
is
a
multi-wallet
discovery
protocol
so
that
you
can
have
multiple
installed,
wallets
and
choose
between
them.
B
Yes,
I
can
jump
over
to
the
actual
EIP
to
kind
of
explain
how
it
works
a
little
bit
after
so
I
created
that
wallet.
Let
me
make
sure
I've
got
one
here:
I
am
not
eligible.
Okay,
I
need
to
reach
out
to
those
you're
on
folks
about
that,
and
then
encrypt
is
working
fine,
so
effectively.
That's
what
we're
trying
to
work
around
here
is
the
ability
to
be
able
to
connect
multiple
wallets
at
the
same
time
and
for
the
DAP
to
be
able
to
distinguish
between
them.
B
So,
for
example,
in
this
wallet
here.
B
That'll
show
it
is
connected
now
looks
like
the
Gap
might
be
in
a
weird
State.
Let
me
see
if
that
might
be
yeah.
So
this
looks
like
this
is
a
warning
that
would
have
popped
up
based
upon
some
changes
that
happened
recently.
So
essentially,
this
will
be
a
perfect
Target
for
writing
some
tests
and
actually
I'm
I'm
planning
to
work
with
Sam
in
order
to
get
that
done.
I
just
haven't
gotten
around
to
it.
B
Yet,
basically,
I
wouldn't
focus
on
the
spec
was
the
the
original
intention,
and
then
we
can
write
some
some
tests
once
it's
near
in
completion.
So
we
feel
like
the
spec
is
getting
to
that
point,
which
is
why
we've
asked
people
to
start
implementing
within
the
group
and
that's
kind
of
one
of
the
things
that
we
want
to
talk
about
is.
Can
we
get
to
you
know,
maybe
maybe
five
or
ten
within
the
next
month
or
two?
B
It's
actually
a
very
simple
thing
to
implement
you're
just
using
events
where
you
wrap
around
your.
What
is
it?
B
You
wrap
around
your
window
down
an
ethereum
injection
with
a
few
different
objects,
and
it
makes
it
work
pretty
easy,
so
not
very
complicated,
but,
as
you
can
see,
I'm
able
to
inject
different
addresses
to
the
actual
wallet
itself
or
to
the
DAP
itself
from
different
wallets
and
it's
able
to
to
connect
to
them
independently,
there's
also
some
stuff
that
I've
been
working
on
internally
at
Brave
about
how
we
can
go
about
doing
a
private
mode.
B
So
there
is
some
definitions
in
there,
but
this
is
kind
of
an
idea
I
had
when
I
was
working
on
the
spec
and
I
just
kind
of
dropped
it
in
there.
So
I'm,
not
sure
if
other
people
have
noticed
how
this
would
work
yet
in
a
backwards
compatible
way
but
effectively.
What
you
saw
me
do
there
is
how
I
would
kick
this
off
is
in
this
very
similar
way.
B
So
the
idea
that
I've
been
playing
with
for
us
is
that
for
legacy,
dapps,
for
example,
which
I
should
be
able
to
initiate
I,
can
initiate
it
on
this
one.
So
this
is
a
stable
that
I'm
on
right
here.
You
can
see
that
it's
Legacy,
so
the
idea
behind
this
is
in
order
to
make
this
private
mode.
B
So
what
this
means
here
is
that,
at
the
point,
when
the
user
interacts
with
the
connectflow
through
the
wallet,
that's
when
we
can
initiate
injection
is
after
they've
selected
the
address,
which
then
means
that
we
can
actually
prevent
fingerprinting
as
well,
so
I'll
likely
do
that
internally
for
us,
but
then
I'll
show
kind
of
how
it
works
so
that
other
people
can
kind
of
copy
that
Paradigm
in
hopes
that
we
can
start
to
eliminate
some
fingerprinting
issues
that
we
have
as
well
and
add
some
privacy
preserving
features.
B
So
that's
kind
of
the
demo
of
it.
I
will
jump
over
to
the
actual
EIP
itself
and
drop
a
link
here
to
kind
of
walk
through
how
this
works
so
effectively.
B
What
it
is
like
I
said,
is
we're
passing
some
properties
in,
and
this
is
basically
just
metadata
about
your
provider
and
there's
details
about
what
they
actually
do
and
stuff
like
that,
and
this
was
where
a
lot
of
the
discussion
actually
landed
was
to
be
able
to
discuss
these
different
properties,
how
they
should
work,
what
sort
of
trust
model
they
should
have.
B
What
are
the
security
security
guarantees
and
things
of
that
nature,
and
then
you
take
that
metadata
and
you
supply
it
with
the
actual
provider
itself,
and
then
you
pass
it
over
an
event
and
that's
effectively
implementing
eip6963.
So
the
whole
point
of
this
is
basically
to
prevent
us
from
having
to
basically
prototype
pollute
window.otherium
to
try
and
compete
for
it
so
that
we
can
all
actually
get
all
of
our
wallets
working
together
and
kind
of
improve
that
user
experience
for
the
user.
B
So
that's
the
high
level
explanation
of
it
that
privacy
aspect
I
mentioned
is
kind
of
highlighted
down
in
here.
But
there's
no
like
specific
details
on
how
that
works.
We
could
even
write
that
as
a
secondary
extension
spec,
potentially
in
terms
of
like
the
ux.
That
would
come
with
it,
but
that
feels
very
implementation,
specific,
so
I'm
happy
to
just
engage
with
people
separately
on
that
as
well.
B
Is
there
anything
else
worth
mentioning
I,
don't
believe
so
we're
currently
in
peer
review
state
so
yeah,
if
you
guys
have
the
ability
to
be
able
to
get
this
on
your
backyard
as
an
Implement
and
then
let
me
know
the
plan
is
to
make
a
push
here
in
the
next
month
or
two
to
basically
start
promoting
this
and
then
taking
this
steps
and
saying
hey.
This
is
the
better
way
that
you
guys
should
should
be
approaching
this
going
forward.
So
that's
all
I've
got
on
the
topic.
B
B
B
So
if
we've
got
enough
wallets
supporting
this,
then
it
makes
it
much
easier
for
us
to
be
able
to
go
to
the
dapps
and
say
Hey.
You
know
that
cool
Library
you're,
using
like
web3
modal,
just
upgrade
the
version
and
you'll
be
able
to
pick
this
feature
up
real,
quick.
B
I'm
not
sure
how
to
pronounce
your
name
I.
Think
it's
kiosks.
Can
you
explain
that
a
little
bit
further.
F
Yeah
sure
I
I'm
just
wondering
if
we
should
just
implement
it
right
now.
It
looks
great,
but
it's
been
stale
for
a
few
months
and
still
in
the
review
stage,
if
I
remember
well,
yeah
and
yeah
I'm
just
worried
about
injecting
more
data
into
every
Page's
browser
load.
You
know
if
it's
worth
it
or
not,.
B
I
gotcha
yeah,
so
that's
kind
of
the
the
whole
goal
behind
the
privacy
mode
aspect
of
this
is
that
this,
because
of
the
event
to
a
model,
it's
actually
possible
for
us
to
do
this
without
injecting
any
data.
First,
you
can
do
this
by
basically
adding
an
event
and
then
or
adding
an
event
Lister
first,
because
the
page
fires
an
event
as
well
and
then
effectively
what
you
can
do
from
that
is
to
be
able
to
respond
first.
So
because
this
creates
this
event
Loop,
you
don't
actually
have
to
inject.
B
First,
you
can
just
choose
to
add
the
event
Lister
and
then
only
respond
when
the
page
responds
to
it.
That
would
break
backwards
compatibility,
but
that's
kind
of
where
that
backwards,
compatibility
backwards,
compatible,
Legacy
private
mode
comes
into
play,
which
is
to
start
changing
some
of
the
things
that
we're
already
doing
today,
but
people
don't
necessarily
have
to
do
that.
If
that
makes
sense,
does
that
answer
your
question.
B
Yes,
essentially
at
this
point,
my
impression
of
the
spec
having
worked
on
the
spec
is
that
we're
looking
for
implementer
feedback?
We
we
intend
to
basically
take
this
to
finalize
state
by
the
end
of
the
year,
we're
looking
for
that
feedback
during
the
review
state,
so
that
we
can
make
sure
that
any
sort
of
things
that
we
missed
when
we
were
writing
the
spec,
which
is
very
natural
to
happen,
make
them
into
the
spec
before
we
finalize
it.
B
So
the
idea
behind
this
is:
if
we
can
get
people
implementing
around
review
in
the
Final
Call
State,
we
can
figure
out
any
sort
of
things
we
missed.
Make
changes,
coordinate
those
changes
together
and
once
we've
coordinated
and
decided
yes,
this
is
correct.
We
can
finalize
the
spec
and
just
say
this
is
what
it
is
now,
that's
what
you
should
open
it.
B
Yep
thanks
for
the
question,
that's
a
great
question
because
for
people
who
weren't
following
the
spec
yeah,
it
may
be
confusing
kind
of
what
state
it's
at
and
where
it's
going,
especially
with
so
many
erps
that
kind
of
get
left
in
stale
States.
A
So
kind
of
on
a
general
note
about
eips,
like
review,
would
be
a
good
time
to
start
trying
to
implement
eips
and
then
maybe
having
like
preview
releases,
but
it's
definitely
not
ready
for
production
and
then
last
call
and
final
would
be
like
your
release.
Candidate
and
then
your
like
production
release
would
be
around
the
final
time.
B
B
To
tie
this
back
to
the
test
framework
discussion
that
we
had,
this
is
where
we
as
a
wallet,
Development
Group,
can
actually
say
any
wallet
related
eips
have
to
have
tests
written
before
we
go
to
Final
Call.
B
That
would
be
ideal
State.
That's
how
actually
w3c
does
it
as
well,
and
they
placed
additional
requirements
with
say
at
least
two
browsers
must
Implement
and
pass
the
tests
or
all
the
normative
required
tests
before
the
spec
itself
can
be
moved
to
finalize
State
I.
Don't
think
we'll
jump
to
that
right
away,
but
I'm
curious
to
hear
your
opinion
on
that.
Sam.
A
We're
trying
to
work
on
a
better
governance
system
and
I've
shared
it
with
I
think
at
least
one
of
you,
probably
Kyle
yeah,
so
anyways
just
wait
a
bit
we're
going
to
sort
some
stuff
out
and
then
we'll
be
able
to
do
things
like
that.
If
we
want
to
have
like
a
wallet
working
group
for
eips,
that'll,
probably
be
possible
in
the
next
month
or
so.
D
I
think
this
testability
requirement
is
that
Kyle
mentioned
from
w3c.
Precedent
makes
a
lot
of
sense
for
the
interfaces.
D
Well,
it's
the
wallets
have
to
be
I,
mean
I.
Think,
ideally,
any
EIP
about
like
a
wallet
interface,
should
already
have
a
test
in
the
CI
of
the
wallets
that
want
to
support
it.
What
it
gets
to
final,
because
otherwise
it's
just
like
kind
of
a
precarious
under
tested
thing,
but
I
do
think
that,
if
interface
requirements,
specifically
wallet,
interfaces
wanted
to
sort
of
like
have
their
own
version
of
this
process,
it
doesn't
have
to
be
imposed
by
EIP.
It
could
just
be
like
all
wallet.
D
D
B
Yeah
one
of
the
things
that
I
think
we're
going
to
need
to
figure
out
with
the
core
devs
is
when
they
expose
new
RPC
calls
for
the
nodes.
How
do
we
go
about
exposing
that
and
making
sure
that
works
within
the
wallets,
but
that's
something
we
can
kind
of
figure
out
along
the
way.
A
Yeah,
that's
that's.
Definitely
an
interesting
point
like
especially
with
like
get
proof
and
get
Max
priority
for
you
for
gas.
It's
like
recent
examples,
I
think
so.
A
B
Yeah,
luckily,
it
seems
like
they're
open
to
these
types
of
things
in
the
discussions.
I
was
having
with
Dan
on
these
types
of
stuff,
so
they
want
to
stay
connected.
B
A
Cool
so,
on
a
similar
note,
I
put
a
link
to
my
sort
of
competing
proposal
for
this
in
the
agenda.
It's
a
much
longer
timeline,
as
in
nobody's
even
started
implementing
it.
This
is
EIP
7039,
just
throwing
it
out
there
take
a
look
at
it
comment
on
it.
Tell
me
why
it
won't
work.
B
B
I
haven't
read
through
it.
Can
somebody
summarize
it
thank.
C
B
C
Was
just
looking
through
the
the
EAP
and
the
only
thing
that
kind
of
stuck
out
at
first
was
the
rdns
field
and
I,
so
I
guess
I
was
just
kind
of
raising
a
point
of
like
I'd
intuitively.
Imagine
that
to
be
like
say,
URI
with
the
you
know,
non-reversed
one
though
I
understand
you
know,
pardon
me
for
not
knowing
your
proper
name,
I'll
call.
C
You
Bumble
I,
raise
a
point
there
around
the
usefulness
of
having
It
reversed
and
in
a
large
set,
though
yeah
just
wondering
they're
like
if
that's
like
a
set
in
stone
thing.
If
there's
any
alternate,
you
know
preferences
or
if
anyone
else
has
kind
of
raised
anything
around
that.
D
D
D
I
was
actually
an
advocate
of
rdns,
just
by
analogy
to
manifests,
because
in
just
centralized,
like
I
think
that,
given
the
decentralized
nature
of
the
development
here,
you
want
people
to
be
able
to
declare
themselves
and
sort
of
like
vendor
their
own
vendor.
The
namespace
of
possible
strings
and
reverse
DNS
is
used
for
manifest.
D
For
that
reason,
sort
of
like
a
top
level
domain
is
something
that
most
commercial
or
non-commercial
organizations
get
early
and
stick
to
and
if
all
future
versions
can
be
sort
of
subdomains
of
that,
then
it
creates
this
sort
of
like
self-sorting
self-organizing
namespace.
It's
sort
of
like
an
ietf
tradition
that
comes
from
Java
or
whatever,
but
to
your
point
about
using
normal
URLs
or
some
other
URI
scheme
or
having
constraints
that
make
rdns
more
functional.
D
The
pr
I
linked
in
the
chat
is
one
of
the
active,
reviewing
wallet
developers
proposal
to
make
it
more
explicit,
both
the
rationale
for
it
and
what
you
can
assume
about
it
and
what
you
can't
so
I
I.
Do
think
like
I
think
it
should
be
a
DNS
under
the
control
of
the
maker
of
the
wallet,
even
if
everyone's
and
on
even
if
it's
a
non-profit,
like
I
I,
want
to
leave
open
the
design
space
for
wallets
that
are
not
products
in
the
commercial
Capital
sense.
But
I
do
think.
D
It's
left
open
for
future
eips
to
extend
this
to
have
a
HTTP
based
verification
method
like
you
could
use
a
key
record
on
DNS
or
a
did
well
known,
or
some
other
way
to
put
key
material
at
a
URL,
so
that
people
could
use
an
rdns
that
is
associated
with
the
key
that
signs
the
packages
and
package
managers
or
App
Stores
or
some
other
sort
of
bi-directional
verification.
D
But
I
think
it
also.
The
the
consensus
was
that,
while
that
would
make
sense
as
an
extension
spec,
some
people
would
rather
just
use
them
as
arbitrary
strings
and
on
both
sides.
While
the
sides
on
dev
sides,
it
might
not
make
sense
to
sort
of
like
make
the
onus
of
verification
or
reason
to
not
support
this.
The
standard,
since
it's
sort
of
like
urgent
to
get
just
more
secure
basic
connection.
D
While
the
depth
connection,
sorry,
that
was
kind
of
a
brain
dump
instead
of
an
answer,
if,
if
you
have
follow-up
questions
or
anyone
else
has
questions,
I
could
maybe
be
more
useful.
C
C
Their
the
intended
use
of
that
is
is
primarily
around
future
desire
to
verify,
potentially
not
in
all
cases.
Of
course,
as
you
mentioned,
some
people
won't
actually
have
the
domain
that
they
put
there,
but,
but
generally
that,
like
it's
not
trying
to
replace
the
value
of
like
uuid
there
right
like
uid,
is
right.
The
ultimate
identifier
of
a
given
wallet
right.
D
So
if
you
generate
that
uuid
at
build
time
or
at
installation,
then
you
have
a
uuid
for
each
individual
wallet
out
there
in
the
world.
But
if
you
wanted
to
know
that
that
was
you
know
like
a
an
official
release
of
metamask
or,
like
you
know,
actually
came
from
a
metamask
binary,
the
verification
would
be
useful
because
then
you
could
sort
of
like
have
some
two-way
verification
between
that
uuid
marked
individual
wallet
and
like
which
version
of
metamask
it's
claiming
to
be,
and
the
so
in
a
sense.
D
There's
like
the
the
identification
of
the
wallet
for
sort
of
local
purposes,
and
then
there's
the
like
is
metamask
flag,
that
this
is
replacing
in
the
basic
window.etherium
model.
So
like
it,
it's
sort
of
like
to
be
backwards
compatible
and
to
be
self-attested.
The
way
is
metamask.
Is
you
want
to
allow
people
to
make
an
unverifiable
or
unverified
Claim
about
what
kind
of
software
it's
running
and
in
those
subset
of
use
cases
where
it
matters
that
it's
actually
an
official
build,
or
you
know
an
original
unmodified
binary
or
whatever?
A
B
Yeah
I
was
just
going
to
add
a
little
bit
of
flavor
to
that
in
the
sense
of
like
one
of
the
key
things
that
the
DAP
developers
and
the
DAP
Library
developers
that
have
been
involved
in
this
development
inspect
so
far
have
brought
up
is
that
they
want
the
ability
to
be
able
to
create
ux's
on
the
the
DAP
page
that
load
very
quickly.
B
So,
for
example,
they
can
cache
the
images
in
a
way
that
would
allow
them
to
basically
be
able
to
load
it
before
the
actual
wallet
initiates
its
injection
or,
like
basically,
fires
its
event,
and
so
there's
some
different,
like
rehydration
schemes
and
a
few
other
features
that
they've
mentioned
that
this
would
allow
them
to
do
to
be
able
to
maintain
persistence
between
a
wallet
that
basically
changes,
perversion
or
changes
per
session
effectively
is
kind
of
the
idea.
B
So
that's
what
this
identifier
is
really
about
is
being
able
to
replace
that
and
and
formalize
effectively.
That
is
metamask.
That
is
brave
wallet
that
is
coinbase
wallet
convention
that
we
kind
of
all
just
picked
up,
but
never
actually
wrote
down,
and
that
was
kind
of
what
they
had
said
is
hey.
We
want
that
actually
written
down.
This
seems
like
a
good
place
for
it.
B
Can
you
put
it
in
and
originally
I
was
very
much
against
this,
because
the
identifier
wasn't
verified
it
could
be
tampered
with,
but
eventually
I
think
their
arguments
were
pretty
sound
in
terms
of
kind
of
the
benefits
that
come
from
this.
We
just
have
to
be
careful
with
it
very
similar
to
user
agent
strings.
If
you
put
too
much
information
in
those
huge
user
agent
strings
in
a
browser,
you
can
actually
cause
a
lot
of
compatibility
issues.
B
So
that's
kind
of
where
a
lot
of
the
bike
shedding
on
this
topic
went
was
how
much
information.
What
do
we
do?
How
do
we
secure
it
that
type
of
stuff?
So
this
is
a
great
question.
Actually,
foreign.
F
B
Okay,
I
figured
that
might
be
the
case.
I
see
a
lot
of
people
popping
up,
go
ahead
and
speak.
B
B
So,
for
reference,
this
is
just
kind
of
where
a
lot
of
the
discussion
has
happened,
because
Pedro
was
the
lead,
instigator
and
being
able
to
get
a
bunch
of
people
into
the
conversation
going
forward.
Personally,
I
wasn't
a
big
fan
of
using
telegram
I'd
love
to
be
able
to
move
discussions
like
we
had
about
rzns
directly
onto
GitHub
and
have
it
during
an
issue,
but
that's
something
that
we
can
kind
of
figure
out
going
going
forward
and
stuff
like
that
about.
How
do
we
actually
want
to
engage?
Do
we
want
Discord?
A
All
right:
well,
thanks
for
coming
out
and
talking
about
it,
giving
us
an
update,
I,
really
appreciate
it
yeah.
If
we
want,
we
can
just
hang
out
and
talk
some
more
feel
free
to
take
off.
I
think
this
is
the
end
of
the
official
meeting.
B
B
This
is
wallet
uncon,
we're
currently
looking
for
proposals
effectively
for
people
to
bring
forth
to
this
unconference.
So
I,
don't
know
if
you
guys
have
been
done
conferences
before,
but
we
tried
to
highlight
it
here:
we'd
love
to
get
a
lot
of
wallet
developers
there
so
that
we
can
start
to
have
more
discussions
about.
B
You
know
things
that
we
want
to
build
together,
how
we
want
to
improve
the
world
ecosystem,
how
we
want
to
improve
wallet,
ux
and
stuff,
so
if
you
guys
are
in
or
around
Istanbul
at
that
time,
it
would
be
amazing
to
have
you
guys
come
reach
out
to
me
or
bumblefudge
who
are
both
helping
to
organize
this
and
we're
currently
in
Communications,
with
the
ethereum
foundation,
who's
actually
helping
to
fund
this
basically
one
day
event.
D
So
we
can't
plan
for
all
the
workshops
in
advance,
but
we
can
plan
a
few
to
sort
of
like
seed
the
the
schedule
with
a
few
fixed
proposals
in
defense,
but
yeah
definitely
lightning
talks,
particularly
if
people
want
to
demo
interface,
eips
or
or
design
patterns,
or
anything
that
that
wants
a
lot
of
horizontal
review
from
other
wallets.
Those
are
be
the
ideal,
lightning,
lightning
talks.