►
From YouTube: All Wallet Devs #7
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
A
A
All
right
so
welcome
to
all
wallet.
Devs
number
seven
I
expect
this
to
be
an
incredibly
late
today,
because
it's
basically
in
the
middle
of
the
holidays,
I
think
we
have
some
new
people
showing
up
today.
So
if
you
guys
want
to
introduce
yourselves
and
what
wallet
you're
from-
and
you
know
what
you
want
to
get
out
of
this
and
what
you
work
on
that'd
be
great.
C
Hey
my
name
is
Brendan
and
I'm
here
from
coinbase
wallet
I'm
here
with
my
colleague,
Adam
and
yeah
I.
Think
we
just
want
to
do
a
better
job
of
working
with
the
community
in
terms
of
collaborate
on
which
dips
the
community
wants
to
unify
around
for,
for
account
abstraction
and
smart
contract
wallets
in
the
lake
of
that
in
2023.
D
Yep
this
one,
this
is
Adam
from
coinbase.
We
work
with
Brendan
on
coinbase
wallet,
we're
just
trying
to
get
more
in
touch
with
the
community,
we're
pretty
interested
in
eip4337
and
what
that
means
for
the
future
of
coinbase
wallet.
B
A
Cool
thanks
guys,
so
the
only
thing
on
the
agenda
for
today
is
any
cool
new
wallet
features
you
want
to
demo,
since
it's
coinbases
I
think,
first
time
here,
I
don't
expect
you
to
have
anything
to
demo,
but
maybe
for
for
January.
If
you
have
anything
you
want
to
show
off.
A
If
you
take
a
look
at
the
4337
Channel,
there
is
a
link
to
a
different
Discord.
That's
more
focused
on
4337,
so
feel
free
to
join.
That
too
you'll
have
is
the
person
to
talk
to
about
that
yeah.
So
I
think
that's
all
the
formal
business
we
have
for
today.
If
anybody
wants
to
chat
about
anything,
feel
free,
otherwise,
yeah,
happy
holidays.
E
Is
anyone
else
following
along
with
my
debate
on
which
isn't
Forum
regarding
window
dot,
ethereum
versus
window.books
message.
E
E
E
This
was
basically
just
me
and
abh
nuke,
arguing
over
whether
he
wants
to
do
so
see.
The
problem
that
he
wants
to
solve
specifically
is
multiple
wallets.
The
user
has
multiple
wallets
installed
and
when
right
now,
if
they
have
multiple
extension
wallets
installed,
they
just
fight
with
each
other
and
the
other
techniques.
Each
one
can
use
to
try
to
overwrite
the
other
one,
but
ultimately
only
one
of
them
gets
installed.
So
he
wants
to
switch
from
window.etherium
injection
to
window.edm
Providers
injection,
which
I
think
digital
proposal
is
an
array.
F
E
A
Basically
the
same
thing
as
Corbin's
extension
registry,
just
a
little
bit
different,
not
familiar
with
that
one.
That's
the
one
that
started
the
whole
discussion.
It
was,
you
would
read
the
value
of
window.othereum.
If
it's
set,
you
would
add
it
to
an
array
and
then
replace
window.otherium
with
a
proxy
that
calls
like
the
array,
picks
a
wallet
from
the
array,
rather.
E
Right
so
I'm
saying
that
why
that's
what
he
wants?
What
I'm
arguing
is
that,
if
we're
going
to
do
a
major
breaking
change
like
moving
window.etherium,
meaning
every
single
app
needs
to
change
where
it
looks
in
every
Library
Etc,
then
I
feel
like.
We
should
make
a
more
useful
change
that
solves
more
problems
than
just
one,
very,
very
narrow
one.
E
The
reason
for
this
is
that
breaking
changes
are
very
expensive
and
we
have
limited
capital
capital
to
actually
do
them,
and
so,
if
we're
going
to
go
through
that,
we
should
make
the
most
of
it
and
so
I
I'm,
suggesting
that
we
do
something
like
window.post
message
or
something.
So
that
way
we
not
only
solve
the
multiple
wallets
the
injected
thing,
but
you
also
can
support
iframe
wallets
so
gnosis
and
whatnot,
which
can
only
work
with
the
iPhone
modes
currently
and.
E
Yes,
that's
the
other
big
one
for
me.
Is
I,
really
don't
like
the
fact
that,
in
order
for
an
exit
browser
extension
wallet
to
work,
you
have
to
give
it
full
access
to
everything
you
look
at
on
the
internet
now
to
be
fair.
I
did
file
a
bug
with
Google
Chrome
like
years
ago,
and
they
finally
fixed
it,
and
so
you
can
actually
connect
to
extensions
Now
in
Chrome,
I
think
in
Firefox,
as
well
Maybe
without
having
to
get
permission
to
access
every
single
website
on
the
internet.
E
No,
no,
so
it's
externally
connectable,
it
has
to
do
with
it's
going
into
manifest.
V3
I
think.
C
I,
it's
been
a
while,
but
around
five
or
six
months
ago
we
were
in
talks
with
the
Chrome
team,
where
we
were
just
giving
feedback,
and
our
request
was
that
Chrome
just
actually
have
like
a
built-in
UI
for
wallet
requests
so
that
it
stands
out
as
a
special
as
a
special
thing,
but
I
forget
when
we
last
had
contact
with
them.
It
didn't
seem
like
something
that
would
be
top
of
their
priority
list.
If.
A
You
are
talking
to
Chrome
what
like
my
proposal
for
this
is
to
use
a
custom
scheme
Handler
so
like
web
plus
like
evm,
or
something
like
that.
Colon
slash,
slash
and
Firefox
already
has
a
UI
for
choosing
between
implementations,
if
you're
talking
to
Chrome
get
them
to
make
that
little
dialog
box
and
then
it'll
work
for
wallets
it'll
be
perfect.
A
E
Similar
to
how
on
mobile
devices,
if
some
mobile
device
says
Hey
I
want
some
app
to
handle
Bitcoin
colon
slash,
it
will
announce
to
the
OS.
Hey
I
have
a
Bitcoin,
please
let
these
are
choose
and
then
the
user
can
either
have
a
single
Handler
for
that
that
just
it
automatically
is
opened
or
the
OS
has
a
little
pop-up
that
says:
hey
we've
noticed
you've
got
three
different
things
that
can
handle
Bitcoin
so
which
one
do
you
want
to
use?
E
G
G
F
G
E
If
you
want
an
extension
that
interacts
with
in
any
web
website
and
the
extension
needs
to
be
registered
with
Likens,
manifest
I
need
to
say,
I
need
access
to
https
colon,
slash
star,
and
that's
why
the
extension
then
prompts
saying
hey.
This
is
going
to
have
read
and
write
access
to
every
single
one
of
your
web
pages.
There
is
a
a
mechanism
for
making
it
so
now
mechanism
and
chrome,
at
least
that
an
extension
can
say.
C
B
E
So,
theoretically,
we
could
use
externally.
Let's
do
it
this
externally,
connectable
thing
instead,
I
still
like
I,
still
prefer
window.post
message
over
externally
collectible,
because
it's
Sports
iframes
and
not
just
extensions,
whereas
I
think
the
externally
connectable
stuff
is,
would
purely
be
extension,
support
and
I'd
like
to
get
away
from
coupling
so
strongly.
With
extension,.
E
It
works
Marine
passion
to
create
a
a
new
like
the
entire
communication
protocol
over
something
new
which
includes
enveloping
and
whatnot.
E
G
It
would
be
interesting,
I
mean
it's
a
discussion
between
like
between
you
and
this
kiwi
KB.
Whatever
his
name
is
I
mean
the
one
who
is
like
also
the
major
injector
is
to
meet
a
master.
It
would
be
interested
how
they
are
willing.
They
would
be
to
pull
along
with
switching
to
like
something
like
positive
messages,
and
it's
always
a
tricky
part
right.
It
is
some
wallet
that
is
the
biggest
one
that
is
injecting
still
and
it
would
break
them
the
most.
C
Foreign
I'm
not
really
super
prepped
for
for
this
conversation,
but
the
the
corniest
wallet
injects
as
well,
and
we
there
was
a
point
where
users
who
had
both
metamask
and
coinbase
wallet
installed
at
the
same
time
was
a
problem
and
if
I
remember
correctly,
we
now
detect
this
and
show
a
pop-up
to
the
user.
Ask
him
to
pick
I.
C
Our
end,
but
in
terms
of
injection
and
safety
in
general
internally,
it
was
very
difficult
to
get
coinbase
wallet
extension
approved
for
on
our
on
our
corporate
Chrome
instances,
just
because
of
the
permissioning
problems.
I
think
we
would
generally
like
to
move
away
from
injection.
But
don't
quote
me
on
that.
E
I'm
not
like
that's
important,
so
I
I.
The
impression
I've
gotten
from
metamask
in
the
past
is
that
they
would
not
be
opposed
to
this
I
think
the
biggest
hurdle
is
just
getting
rid
of
Mass
to
make
a
significant
code
change
I,
don't
think
they
would
resist
it
like
I,
don't
think
they're,
gonna
fight
it
I,
don't
think
they're
gonna
say
no.
This
is
a
terrible
idea,
but
I
also
don't
think
they're
going
to
lead
the
charge
at
all,
and
it
may
require
some
third
party
as
many
PRS,
potentially
in
the
worst
case.
E
A
E
E
E
This
is
a
security
issue,
because
you're
basically
backing
extended
developers
into
a
corner
where
they
now
have
to
ask
for
much
more
broad
permissions
in
order
to
do
what
they
need
to
do.
Whereas,
if
you
just
allow
us
to
put
a
wild
card
in
there,
then
we
don't
need
that
so
I
don't
know
if
Firefox
allows
for
full
domain
wild
cards
or
not,
or
only
some
domain
web
card.
D
F
E
A
E
I
would
do
it
the
other
way,
so
I
would
say
the
page
loads,
the
page
posts,
a
message
saying:
hey
I'm
looking
for
wallets
and
then
one
or
more
wallets
could
then
respond,
and
the
reason
for
that
is
because
a
we
want
the
page
to
have
loaded
enough
that
they're
actually
listening
before
we
start
posting
and
so
from
a
timing
standpoint.
The
page
is
the
thing
is
going
to
most
likely
load
last
and
so
and
also
from
a
privacy
standpoint.
E
E
Having
the
page
ask
first
and
say:
hey
I'm,
looking
for
a
wallet,
it
means
that
the
the
wallet
can
now
reasonably
prompt
the
user,
whereas
if
it
was
the
other
way
around,
then
you
would
need
a
prompt
user
for
literally
every
single
page
on
the
internet.
When
only
you
know
point
one
percent
of
them
actually
care,
and
so
the
idea
is
have
the
page
broadcast
saying
looking
for
wallets
any
wallet.
E
That's
interested
can
either
ask
the
user
or
just
automatically
respond,
and
then
once
the
page
has
received
those
responses,
it
can
Now
list
them,
and
so
part
of
that
response
would
include
like
your
icon,
your
friendly
name,
your
like
some
sort
of
ID,
or
something
like
that,
and
maybe
a
public
key
for
encryption.
And
so
then
the
page
can
now
has
a
list
of
wallets
that
are
available.
E
H
G
G
Note
says
also
said:
the
post
message
approach
is
being
used
as
Mica
Central
by
the
safe
in
a
similar
purpose
and
let's
actually
that's
a
way
to
communicate
between
like
their
app
and
the
iPhone
or
like
that
app,
which
is
nice.
It
would
be
nice
to
standardize
this
because
right
now
lecture
does
it
differently.
Then
we
had
the
safety
into
it
and
it's
all
a
little
bit
different
than
injection
Works,
which
you
know
it's.
E
I
I
do
agree
with
Sam
that
I
think
the
scheme
Handler
if
we
can
somehow
get
Chrome
to
present
a
a
list.
The
scheme
Handler
is
strictly
better
out
of
curiosity.
If
we
ignore
the
multi-wallow
scenario
does
escape
Handler
work
today.
Yes,
so
the
only
issue
is
that
if
a
user
has
multiple
wallets,
only
one
of
them
can
respond
to
the
page
when
it
requests
for
scheme
Handler,
Handler,
yeah.
A
F
G
Can
you
link
it?
Can
you
link
into
the
settings
in
Chrome
I
mean
on
Android.
This
is
always
a
proposed
way
right.
If
some
of
the
settings
in
the
Android
system
don't
fulfill
the
purpose
of
the
app,
then
Android,
developer,
docs,
say
link
into
the
settings
where
the
users
can
change
it,
I'm,
not
sure
if
you
can
use
the
same
on
Chrome.
E
I
think
the
other
thing
so
alternative
to
actually
go
and
give
this
implementing
curl.
If
we
can,
just
maybe
this
is
just
as
hard,
but
if
we
get
like
positive
feedback
from
the
Chrome
team
indicating
yes,
we
think
this
is
a
good
idea.
I
feel
like
we
could
potentially
move
forward
and
just
say
you
know
we
don't
have
multiple
support
in
Chrome
yet,
but
Firefox
does,
and
so,
if
you're
doing
multiple
wallets,
which
is
the
uncommon
case,
then
use
Firefox
until
Chrome
implements
it.
E
Probably
would
I
agree.
G
Approach,
it
probably
makes
sense
to
talk
to
people
from
electronic
because
he
also
said
he
played
around
and
tried
to
evaluate
like
what
is
the
best
approach
to
end.
This
is
with
the
schemes
when
they
were
doing
foreign.
G
Yeah
because
we
said
before
in
iOS,
it's
like
they
wouldn't
have
multi-volved
support
right.
It
is
similar
how
it
is
in
Chrome
in
the
sense
of
on
iOS.
You
would
have
to
choose
your
wallet
that
should
happen.
This
right,
like
the
user,
can
actively
choose
this
themselves
also
somewhere
in
their
settings
again,
probably
simulated
this
in
Chrome.
G
G
E
I
wonder
if
we
could
I
just
brainstorming
here.
Is
there
anything
we
could
do
with
multiple
scheme
handlers
where
Maybe
one
could
imagine
if
metamask
registers
as
game
Handler
a
and
when
baseball
registers,
game,
Handler
B,
and
then
you
have
some
orchestrator
wallet
that
registers
as
the
general
scheme
Handler.
And
then
it
knows
about
the
other
two
scheme,
handlers
that
you
have
installed
and
they
can
then
distribute
for
something.
E
F
A
Yes
or
somehow
so
the
link-
that's
rhyme,
just
posted.
It
includes
the
details
of
how
they
do
that
in
iOS,
which
looks
exactly
like
that.
G
At
this
point,
wanted
connect
heads
basically
their
own
registry,
where
everybody
has
to
register
so
in
a
if
we
want
to
go
like
this
is
probably
not
the
nicest
way
right.
Like
I
mean
we
already
have
a
couple
lists
and
registry
where
these
could
probably
then
be
registered,
but
it's
always
a
pain
to
say,
hey,
you
have
a
registry,
and
if
especially,
if
this
is
then
shipped
or
bundled
with
your
app
no
matter
what
platform,
if
a
new
wallet
comes
up,
it's
first
of
all
not
supported.
This.
Is
the
iOS
like
it's
new.
G
F
A
So
with
with
the
like
approach
with
the
custom
scheme,
Handler
beads
just
standardized
like
let's
say
the
wallet,
connect
format,
and
then
everybody
just
supports
that
we
want
to
make
a
new
a
new
standard
for
doing
these
kind
of
links.
E
G
G
G
Is
it
you
know
that
yeah
that's
a
specific
scheme,
they
don't
have
a
like.
It's
I
meant.
This
is
in
the
all
the
connect
context.
It's
a
generous
key
right,
like
it's
a
general
compared
to
all
the
wallet
specific
ones,
but,
yes,
wallet
specific.
It's
wallet
connect
specific,
while
the.
G
G
The
thing
is
that
they
say
for
and
for
the.
F
G
A
So
I
guess:
what
do
we
need
to
have
before
wallets
are
willing
to
move
forward
on
a
new
way
of
connecting
like
this
like?
Do
we
need
a
full
standard?
Do
we
need
like
a
prototype?
What
what
do
we
need
to
get
people
to
accept
a
new
Communication
channel.
G
Related
question
right
like
since
this
would
be
a
UI
I,
can
remember
that
in
the
past
there
was
an
EIP
that
specified
how
such
an
UI
should
look
like
for
a
certain
transactions
like
payments
and
so
on
kind
of
a
steep
linking
which
would
potentially
be
relevant
for
this
one
too,
because
you
have
a
Handler
right
leg
and
you
click
on
it
and
it
should.
These
are
Force.
The
transaction
or
connect
back
I'm,
not
sure
how
this
then
necessarily
works,
because
you
would
have
to
post
all
the
actions
towards
the
Handler.
A
So
to
keep
it
the
most
General
like,
so
it
also
works
with
external
applications.
I
think
we'd
want
to
do
it
so
that
you
click
on
the
link.
The
link
contains
a
webrtc
like
endpoint
that
the
adap
listens
on,
and
then
the
wallet
connects
back
to
the
dapp
through
that
webrtc
channel.
F
G
E
Are
we
confident
that
webrtc
isn't
gonna
sweep
I?
Think
for
me,
the
thing
that
I
would
want
to
see
is
a
proof
of
concept
that
this
webrtc
thing
can
actually
work,
meaning
an
application
running
a
user's
browser
can
open
up
a
listening
Port.
E
A
E
Yeah
I
think
if
you
can
show
a
demo,
a
webrtc
working
in
those
four
scenarios
just
being
able
to
get
that
connection
open
without
having
to,
like
you
know,
run
a
server
on
your
your
host
or
open
firewall
ports
or
anything
like
that.
Yeah.
A
E
I
so
so
my
preference
would
be
that
we
design
and
build
under
the
assumption
that
the
mobile
device
or
the
signer
device
or
whatever
is
on
the
same
network
as
the
well.
E
G
G
E
G
H
E
That'll
be
fun.
The
full
set
would
be
desktop
out.
A
second
tab,
a
second
browser
so
I'm
guessing
it's
basically
the
same
as
desktop
app,
maybe
an
extension
and
then
the
the
Golden
Goose
would
be
able
another
device
on
the
same
network.
A
E
E
E
You
know
who
who
communicates
first,
what
is
the
what
these
Uris
look
like
stuff
like
that
and
then
once
we
settle
on
that,
then
we
I
guess
start
building
a
proof
of
concept,
wallet
and
app
that
actually
uses
all
of
it
and
an
SDK
or
something
where
we
here
means
other
people,
of
course,.
A
I
guess
if
there's
no
other,
like
thoughts
on
this
particular
topic,
I'd
like
to
move
a
little
bit
more
informally
on
to
how
do
we
get
more
wallet
devs
to
come
to
this
call
more
regularly
because
that's
kind
of
a
problem
we
have.
E
A
C
Whatever
it's
worth
from,
my
ux
standpoint
is
most
of
at
least
coinbase
is
most
of
our
means
are
through
Google
me.
C
So,
like
there's,
two
folks
from
Columbia's
wallet
that
I
thought
might
have
more
thoughts
of
time
in
here,
but
you
have
to
go
through
like
a
Discord
invite
process
right
before
they
can
actually
hop
in
this
room.
So
there's
a
way
where
we
could
just
send
them
a
link
and
they
can
meetly
hop
in
that
make
it
easier
to
Wrangle
the
right
folks.
C
While
that's
another
good
point
too,
is
like
my
my
schedule:
I
I,
completely
run
out
of
your
calendar,
so
I
can
guarantee
you
that
we'll
have
a
bunch
of
coinbase
people
here.
If
we
just
have
a
Google
Calendar
recurring
link
that
we
can
just
add
people
on
to.
B
B
G
G
That
even
like
I
have
so
many
Discord
servers
that
just
is
covering
it.
Where
this
course
was
super
tricky
like
it
was
by
accident,
because
this
car
is
also
something
like
you
open
the
page
and
if
you
haven't
opened
it
for
like
two
days
and
pop
gives
you
Pops
UPS,
left
and
right
that
you
want
to
discover
new
features
and
that
you
have
certain
things
that
are
in
your
wallet,
because
you
have
rewards
from
some
Services.
C
Yeah
plus
one
I,
just
added
that
Google
account
blanket.
It
does
show
up
as
private
and
I'll
also.
C
Plus
one
on
the
Discord
someone
who's,
not
on
Discord
communities,
it's
it's
a
bit
tricky
to
get
into
the
room
today.
D
Comment
on
discoverability
of
this
group
like
I,
don't
even
remember
how
I
came
across
it,
I
think
just
like
scrolling
through
crypto
Twitter.
We
randomly
saw
a
mention
about
this
working
group
and
I
was
like
oh
I'm,
a
wallet
Dev
like
when
I
Googled
all
while
it
does
like
nothing,
came
up.
There's
no
like
home
page,
there's,
no
anything
and
so
I,
just
kind
of
like
scrolled
around
through
Sam.
Your
tweets
and
saw
one
of
them
said
DM
me
for
an
invite.
D
So
that's
what
I
did
just
it
feels
like
it's
kind
of
like
hidden
or
Secret.
So,
okay.
A
H
Yeah
I,
I
I
think
there's
a
lot
of
what
it
does
in
the
Discord
already,
maybe
they're
not
like
aware
not
reminded
so
maybe
you
can
think
them
using
their
the
ad
everyone
or
at
here
when
you
post
your
reminders,
Sam
I,
don't
think
it's
intrusive
at
all,
I
think
it's
just
I
I
think
it's
a
good
reminder
if
you
use
the
the
Ping
in
the
Discord.
Okay.
A
For
Sam
I
mean
adding
at
here
is
not
not
that
bad,
we'll.
E
A
C
Yeah
I
think,
like
the
last
time
there
were
a
lot
of
wallet
devs
on
call
was
that
I
remember
being
involved
with
was
for
15.59,
so
I
think
like
next
year,
like
I,
we're
going
to
do
our
best
to
be
here
consistently,
but
I
think
it
makes
sense
that
next
year,
with
with
work
around
account
abstraction
that
there'll
be
a
natural
incentive
for
for
Waltz
to
show
up
just
so
we
don't
end
up
creating
work
for
ourselves
by
doing
different
things.
A
One
hand
Michael
wants
ossification
and
on
the
other
he
wants
account
extraction.
E
E
A
So
I
am
once
again
going
to
take
this
opportunity
to
plug
e5139
still
looking
for
feedback
from
wallet
devs.
If
anybody's
thinking
about
implementing
it
and
yeah
go
check
it
out.
C
E
C
E
G
F
E
E
Is
to
not
support
multiple
chains,
because
everything.
F
E
B
E
C
Yeah
so
sorry,
dumb,
dumb
question,
I
just
read
into
the
EIP
for
the
first
time,
I
assumed
that
this
was
actually
going
to
be
a
way
for
for
Waltz
to
identify
what
our
PC
methods
I
support.
But
it
looks
like
this
is
a
way
for
adapt
to
say
hey
when
riding
this
chain.
These
are
the
RPC
calls
that
we
want
to
use,
and
then
the
wallet
will
store
those
and
and
validate
that
that
chain
only
uses.
Those
methods
is
that
right.
A
It's
more
so
that,
like
let's
say
your
metamask
or
Corn
based
wall
or
whatever,
and
you
you
by
default,
support
like
mainnet
go
early
and
sepolia
right.
But
then
your
user
goes
to
a
a
polygon
app
and
it's
basically
equivalent
to
ethereum,
but
just
with
a
different
RPC
provider
and
the
wallet
underscore
ad
RPC
provider.
Api
is
kind
of
like
sketchy,
because
RPC
providers
get
like
secret
data
about
users,
essentially
like
what
transactions
they're
broadcasting
and
all
that.
So
you
don't
necessarily
want
the
DAP
itself
to
suggest
the
RPC
provider.
A
E
Interesting
they're
very
similar
to
are
you
familiar
tokenlist.org
yeah
same
thing
as
that,
basically,
but
for
rpcs.
So
anyone
can
publish
a
here's.
The
list
of
rpcs
that
I
trust
and
I
think
you
should
use,
and
it's
a
bunch
of
different
people
can
publish
similar
lists
and
users
can
then
just
import
a
whole
list
at
once
of
rpcs
into
their
wallet.
C
Okay,
so
I
get
the
I,
get
the
idea,
then
of
having
like
Community
list
of
rpcs
and
then
so.
Basically,
this
EIP,
then
it
will
change
it
would.
Would
it
modify
eip385.
C
E
So
it's
part
of
the
motivation
for
this
list
was
because
3085
is
very
dangerous
for
my
security
standpoint,
and
so
we
really
want.
E
Gecko
one
I
think
is
very
popular
and
we
don't
have
to
have
every
single
wallet.
You
know
maintaining
their
own
list
of
our
PCS.
C
Okay
and
I
would
the
I
guess:
how
would
the
list?
How
would
we
maintain
the
list
like
how?
How
would
that
work
s.
A
Oh
as
coinbase
you'd
have
a
list
with
probably
one
or
two
entries
for
the
chains
that
you
provide
rpcn
points
for
so
you
wouldn't
worry
about
maintaining
a
bigger
list,
but
the
community
would
have
a
larger
list.
Yeah.
C
So,
even
if,
like
a
gap
sends
as
a
385
request,
we
basically
ignore
our
PC
that
that
they
give
for,
like,
let's
say,
like
the
user,
wants
to
add,
like
Harmony
One
Network,
my
understanding,
the
CIP
would
look
at
some
source
of
lists,
but
look
at
some
source
that
would
give
like
Community
trusted
rpcs
for
harmony,
I'm,
just
wondering
like
how?
How
do
we
know
that
that
list
is
guts,
rpcs
that
are
safe
or
like
I'm
just
curious,
because
how
do
we
maintain?
How
does
that
list
get
maintained?.
E
So
the
way
uniswap
handled
this
back
when
before
they
went
all
evil,
was
they
by
default.
Your
token
list
was
a
token
list
that
they
provided.
That
was
pretty
short.
It
contained
a
handful
of
things,
and
that
was
it.
However,
they
also
included
links
to
a
bunch
of
other
lists
that
you
could
then
enable,
and
so
the
user,
when,
if
you
didn't
see
your
token
in
the
list,
they'd
have
a
little
button
at
the
bottom.
E
That
says,
manage
my
token
list
and
click
that
and
it
would
say,
hey
here's
some
token
lists
that
we
know
of
these
are
third-party
token
lists,
so
use
your
own
risk
and
here's
some
links
to
their
websites,
and
so
they
had
like
coin
geckos
and
they
had
the
Ave
token
list.
They
got
the
one-inch
token
list
and
the
user
could
say
you
know:
I
trust,
coindeck,
gecko,
so
I'm
going
to
go
ahead
and
use
their
list
as
well,
and
so
for
coinbase
wallet,
users
I
could
imagine
a
similar
workflow
or
by
default.
E
You
could
also
have
these
lists
of
rpcs
from
multiple
third-party
sources
and
use
when,
when
the
user
goes
to,
let's
say
a
new
network
when
adapt
tries
to
switch
to
a
new
network
that
you
don't
support,
you
can
say
hey
we.
We
don't
support
this,
but
here
are
some
third
parties
that
have
provided
list
of
rpcs.
If
there's
any
names
in
this
list
that
you
trust
you
can
go
ahead
and
use
one
of
those
or
the
user
could
of
course
add
their
own
list
of
rpcs.
E
Well,
we're
really
trying
to
get
away
from.
Is
we
really
don't
want
adapts
to
be
recommending
rpcs,
because
it's
very
dangerous
for
users
when
they
do
that.
C
And
then,
just
to
make
sure
I
fully
understand
the
danger
of
a
debt
providing
RPC.
So
one
concern
is
that
they
provide
a
node
that
that
would
do
something
like
sandwich,
attack
or
or
various
front
running.
E
I
mean
you
can
also
could
also
lie
to
them
in
responses,
so
the
node
can
tell
them.
Oh
here
is
the
state
like
this
is
the
going
rate
for
token
XYZ
and
when
really
the
going
rate
is
not
that
they
get
because
the
RPC
can
say
whatever
it
wants,
and
so
when
a
user
makes
queries
and
they
think
they're
using
uniswap
and
they
trust
uniswap.
But
the
RPC
is
backing.
Everything
is
lying
about
the
current
price
of
things.
Then
they
may
make
poor
decisions
or.
E
Respond
with
errors
that
contain
links
you
know
or
if
they
happen
to,
if
there's
a
website
that
doesn't
properly
sanitize
their
inputs,
maybe
they
have
a
mechanism
for
using
rpcs
a
means
to
getting.
E
And
stuff
like
that,
like
basically,
the
rpcs
really
are
supposed
to
we're
designed
to
be
trusted
from
the
beginning,
and
we
have
moved
to
a
world
where
people
are
kind
of
blindly
trusting
them
and
now
we're
kind
of
with
3085
we're
stepping
into
a
world
where
people
learn
we're.
Now.
Random
websites
and
internet
are
able
to
give
you
a
thing
that
then
all
your
apps
and
all
your
wallet
and
everything
blindly
trusts,
and
so
we
really
want
to
try
to
avoid
that.
Whole
class
of
attack.
A
Because
it's
not
like,
when
you
add
this
RPC
provider,
it's
not
just
limited
to
the
website
that
you
added
it
on
right.
It's
it's
for
anything
that
uses
the
same
chain
ID.
So
if
you
go
on
like
a
malicious
dap
and
they
add
a
polygon
chain
ID,
then
they
get
all
of
your
polygon
transactions
across
all
apps.
C
You
know:
that's
super
good
I.
We
we
display
right
now.
When
you
add
a
new
network,
we
display
a
very
scary
warning
about
trusting,
RPC
or
I'll,
provide
it
but
I'm
embarrassed
to
say,
I,
never
actually
thought
of
of
a
of
a
doubt
changing
you
know
what
what
the
the
true
get
balanced
calls
should
be,
or
what
the
true
exchange
rate
should
be,
so
that
helps
solidify.
Why
it's
scary
to
let
it
doubt,
provide
an
RPC
or
how
they'll
be
re
used
for
that
Network
across
many
depths,
but.
E
You
could
make
it
at
least
a
little
bit
more
secure
by
making
it.
So
if
a
particular
domain
recommends
an
RPC,
the
RPC
only
is
registered
for
that
domain
and
that
would
be
kind
of
following
3085
still,
but
at
least
secure
the
user
somewhat.
So
you
couldn't
do
these
cross
domain
attacks.
It's
still
not
great,
because
you
know
the
foreign.
E
Yeah
it's
like
in
in
the
wall
itself:
I!
Guess
it
would.
If
your
wallet
has
you
know,
exchange
or
whatever
yeah
or
pricing
or
something
balances
yeah,
so
yeah,
it's
not
great,
but
you
can
at
least
do
better.
So
so,
if,
if
you
do
want
to
support
3085,
my
recommendation
would
be
to
constrain
anytime.
Someone
adds
a
chain,
it's
constrained
to
The
Domain
at
least
or
ideally
make
this
up
debate.
E
C
Good
feedback
I'm
writing
that
down
I
like
that.
C
Yeah
I'm
thinking
like
there's
like
two
thoughts,
I'm
having
just
speaking
off
the
cuff
I
mean
one
is
generally
the
users
who
are
using
custom
networks
are
like
should
be,
or
we
would
think
of
as
our
most
advanced
users
there's
a
bit
of
an
element
of
like
giving
thanks
very
optimistic,
more
responsibility,
but
the
other
thought
I'm.
Having
is
we
do
have
we
have
a
team
internally,
that's
focused
completely
on
safety,
and
maybe
one
area
that
they
could
help
out
in
the
community
is
just
maintaining.
C
E
Yeah
and
that's
kind
of
exactly
what
we're
hoping
I
think
with
this
with
the
AP
5139,
is
that
a
few
trusted
players
within
the
ecosystem
will
show
up
and
create
some
really
thorough,
RPC
lists
and
then
kind
of
the
community
can
then
centralize
around
those,
and
so
maybe
metamask
will
add
coinbase's
list
as
one
of
their
secondary
sources,
and
so
they'll
still
have
their
own
built-in
list.
That
is
their
default,
but
they'll
provide
the
user
and
say
hey.
If
you
want
to
use
coinbase
lists,
they
have
more
kind
of
thing.
It.
C
Should
be
good
I'm,
just
saying
like
off
the
cuff,
the
tough
bit
would
be
like
I
mean
ideally
right.
We
if
the
thing
that
we
could
match
for
the
security
of
the
most
would
just
be
providing
a
node
for
that
chain.
Right,
yep
I'm
wondering
I'm
just
trying
to
imagine
if
what
it
would
take
for
us
to
vouch
for
a
node
provided
by
someone
else,
because
we
can
audit
it
and
then
they
can
change
the
behavior,
and
that
could
create
some
sort
of
liability
issue.
C
Definitely
and
then,
but
the
whole
reason,
though,
that
we
wouldn't
even
have
it
as
a
whitelist
to
change
that
the
chain
just
doesn't
have
enough
usage
yet
for
us
to
justify
the
the
cost
and
maintenance
of
running
a
node
for
that
chain.
Yeah
English
to
me.
So,
if
I'm
being
totally
honest
as
I
think
out
loud,
it
would
probably
be
the
the
feedback
on
stream.
385
requests
to
that
particular
doubt:
that's
something
that
we
we
might
we
could
act
on.
C
C
E
I
think
that
is
enough
and
then
one
can
imagine
like
inferior
will,
probably
publish
a
list
of
all
their
free
stuff
inferior
and
quick
node
and
Alchemy,
and
people
that
have
paid
rpcs
would
probably
one
could
imagine
them
like
on
your
personal
dashboard,
when
you
log
into
like
quicknote.com
or
whatever
on
your
dashboard,
you
could
say
download
my
RPC
list
for
all
the
nodes
that
I
have
and
some
users,
you
know,
have
several
nodes
through
quick
node
one
for
each
of
the
chains
they
use
and
they
can
just
get
one
list
and
then
paste
that
into
coinbase
wallet.
C
Oh
yeah
yeah,
so
all
right,
that's
a
good
Counterpoint,
I!
Guess
sorry,
I,
guess
yeah!
If
quick
node
had
a
public
node
for
a
chain,
that's
not
whitelisted,
then
that
would
be
something
that
we
could
fill
yeah
safe
and
using
right
as
opposed
to
just
some
random
in
the
provider
node.
So
yeah,
that's
a
fair
point.
My.
B
C
E
Yeah
go
ahead.
This
is
what
I
think
that's
like
quick
node.
Rather
so
so
they
might
have
their
list
of
public
notes,
but
they
would
also
provide
to
their
users
on
the
user's
dashboard
on
quicknote.com,
like
when
user
logs
into
quickdot.com.
They
go
to
their
dashboard
they've.
Perhaps
that
user
has
purchased
a
node
for
three
different
chains,
two
which
are
popular
one
of
which
no
one's
ever
heard
of
before
and
quick
node
could
just
have
a
single
URL.
That
user
can
copy.
E
That
is
a
URL
for
their
personalized
RPC
list,
and
they
would
just
paste
that
into
coinbase
wallet
and
now
they
have
all
of
the
nodes
they
purchased
are
now
available
and
as
RPC
providers
in
coinbase
wallet,
rather
than
the
user
having
to
manually
add
each
each
one
one
at
a
time
which
includes
you
know
the
name:
the
chain
IDs,
the
URL
one.
At
a
time
they
don't
have
to
do
that
they
can
just
copy
all
their
pick.
D
You
know
not
not:
every
RPC
provider
does
authentication
through
like
a
URL
path.
Key
like
infuri
does
so.
Do
you
need
to
add
some
sort
of
like
authentication
section
to
this?
This
question
yeah.
A
That
that
would
be
something
to
add
to
the
eib
like
I
mean
HTTP
basic
auth
and
query
parameters
are,
you
know,
obviously
already
supported,
but
what
else
would
we
need?
Let's.
C
Okay,
I
like
that
because,
like
generally
I
mean
the
I
mean
yeah
as
we're
having
the
conversation
I
think
is.
We
would
probably
modify
our
UI
to
have
a
more
heavy
warning
for
a
user
who
wants
to
add
a
node
to
or
RPC
list.
That's,
not
quick,
node
inferior,
Alchemy
or
a
vendor
that
we've
audit
it
and
we
generally
like
having
38.5,
because
it
gives
more
flexibility
for
the
community
to
decide
which
chain
is
the
one
that
that
that's
fitting
their
needs
best.
C
So
if
there's
a
way
to
make
it
easier
for
users
to
manage,
but
we
do
provide
like
in
in
our
UI
right
now,
we
provide
a
way
for
you
to
change
the
RPC
URL,
but
we
don't
I,
think
ad
ethereum
chain
and
switch
ethereum
chain.
It's
RPC.
Urls
is
an
array
right
now,
but
there
isn't
I.
Guess
a
nice
way
for,
like
saying
hey,
add
another
node
to
this
list,
but
it
should
be
trivial
for
us
to
support,
because
internally
we
we
store
chain
information
similar
to
the
3085
spec.
C
E
E
I
think
the
CIP
does
not
specify
a
specific
communication
protocol
for
transferring
these
lists
around
the
assumption
is
it's
just
a
link
and
user
can
copy
and
paste
it.
A
Although
it
does
also
provide
a
way
to
have
like
an
extension
list,
so
it
would
be
like
the
format
yeah
so
like
you
can
have
a
list
that
extends
from
another
list.
So
you
could
say
like
did
you
have
the
coinbase
list
as
your
default
list
and
then
you
extend
it
with
another
list
that
adds
stuff
to
it,
so
you
could
represent
it
in
this
format.
E
C
I
guess
I
wouldn't
imagine
when
I'm
thinking,
dab
and
I
mean
the
use
case.
That
makes
the
most
sense
to
me
would
be
a
user
wants
to
pay
for
for
their
own
node
instance
or
or
access
to
a
node
instance
through
a
trusted
vendor.
C
C
E
I
think
it's
just
more
a
standard
for
representing
a
list
of
rpcs
like
that's
all
really.
The
this
EIP
is
not
trying
to
make
assertions
about
who
to
trust,
or
anything
like
that.
It's
just
saying
here
is
a
standardized
way
to
represent
an
array
of
rpcs
with
all
the
necessary
information
metadata
about
them,
Etc
versioning
as
well
I'm.
Sorry,
you
can
automatically
update.
E
A
E
E
While
it's
a
good
wallet
that
wants
to
be
pro-user
could
allow
the
user
to
export
with
their
rpcs.
So
let's
say
a
user
is
using
ethereum
for
a
long
time.
They've
built
up
their
collection
of
rpcs,
they
use
AWOL
it
may
you
know,
allow
a
user
to
go
through
a
data
export
if
they
want
to
migrate
to
a
new
wallet
and
so
allowing
user
to
download
all
my
rpcs,
and
then
this
would
be
a
standardized
format
for
that
for
another
potential
use
case.
C
Yeah
I'm,
just
zooming
out
I,
mean
I
think
like
in
general,
for
like
the
it's
a
terrible
thing,
but
like
in
general
right
the
ideal,
the
the
if
you're
thinking
about
user
safety,
the
best
thing
would
be
to
make
it
easy
for
a
user
to
run
their
own
light
node
and
connect
their
wallet
to
that
light.
Node.
That's
like
the
gold.
E
C
And
then
to
me
like
the
way
I'm
thinking
about
it
as
a
user
would
be
like
I,
don't
really
want
to
have
like
a
a
big
list
of
I.
Guess:
okay,
if
I
in
a
in
in
some
like
dream
world,
maybe
my
list
would
include
if
each
of
you
guys,
if
I
trust
each
of
you
guys
or
you
guys,
are
all
good
friends,
I,
say:
okay!
Well,
you
all
have
your
nodes,
I
trust,
your
notes,
right.
C
That
might
be
the
use
case
for
a
list,
but
where
we
are
today,
it's
more
like
there's
random
URLs
that
people
see
and
those
are
not
trustworthy.
There's
the
nodes
provided
by
the
chain
itself,
those
you
could
usually
think
of
as
trustworthy
and
then
there's
paid
nodes
and
and
I
would
say
that
those
are
as
trustworthy
as
as
your
your
evaluation,
the
team
behind
those
vendors.
E
C
Yeah
I
guess
in
that
world,
like
the
thing
that
I
could
see
that
we
could
do
better
as
a
wallet
is
just
show
a
different
UI
for
trusted
vendors.
Like
quick
node,
then
we
do
for
a
node
that
we
don't
recognize
I.
Think
today,
if
you
try
to
add
like
a
quick
node
URL
be
a
3085.
Will
we'll
still
show
you
a
big
scary
warning,
but
perhaps
we
shouldn't
do
that.
E
E
E
Yeah
I
think
I.
Think
it's
reasonable
too
I
mean
as
your
position
as
the
the
wallet
vendor
is
the
user
implicitly
trusting
you
can
use
and
whatnot
and
so
it'd
be
nice.
If
you
could
extend
that
trust.
To
saying
hey
here
are
some
other
parties,
We
Trust
as
well
like
you
described
or
if
you're,
Alchemy
or
whatever,
whoever
it
is.
C
See
yeah,
that's
good
feedback
I've
taken
out
a
lot
of
notes:
I'm
15
minutes
over
from
what
I
had
on
my
calendar,
so
I
think
I
need
to
hop
soon.
But
thanks
for
throwing
this
meeting
together,
lots
of
good
notes
and
yeah
we're
happy
to
participate.