►
Description
The first NEAR Wallet Standards Working Group Meeting!
Today we reviewed the Developer Governance initiative and approved NEP-408 – Injected Wallet API.
Chapters:
00:25 Agenda
00:58 Developer Governance
04:23 Introductions
09:33 Discussion: Injected Wallet AP (NEP-408)
35:25 Q&A
41:42 Getting Involved
Learn about working groups and register for upcoming meetings:
👉https://neardevgov.org
NEP Process:
👉 https://github.com/near/NEPs/blob/master/neps/nep-0001.md
NEP 408
👉 https://github.com/near/NEPs/pull/408
Developer Governance Talk
👉 https://www.youtube.com/watch?v=Ggpw1yklsAs&t=11788s
Join NEAR's community:
Website: https://near.org/
Reddit: https://www.reddit.com/r/nearprotocol/
Discord: https://near.chat/
Medium: https://medium.com/nearprotocol
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near | https://github.com/nearprotocol
Dev Docs: https://docs.near.org/
Create a wallet: https://wallet.near.org/create
Apps on NEAR: https://awesomenear.com/
Learn to Build On NEAR: https://www.near.university/
Grants & Funding: https://near.org/grants/
#Blockchain #FutureisNEAR #NEAR #nearprotocol
A
A
Hi
everybody,
my
name
is
Ori
and
I'm.
A
technical
program
manager
from
Pagoda
and
I
want
to
welcome
all
of
you
to
our
first
wallet
standards
working
group
meeting,
which
we're
very
excited
to
kick
off
so
just
on
the
agenda
today.
First,
we
will
do
a
quick
overview
on
developer
governance,
which
includes
our
net
process
and
working
groups.
Next,
we'll
do
some
brief
introductions.
As
we
have
a
few
panelists
joining
us
today,
then
we
will
get
into
the
main
discussion
injected
wallet,
API
and
then
we'll
open
it
up
to
q
a.
A
We
that
I
gave
at
near
con
that
goes
into
more
detail
if
you,
if
you
want
to
learn
even
more
so,
let's
start
with
the
the
ideas.
So
we've
introduced
a
near
enhancement
proposal
next
as
a
way
to
enable
anyone
in
the
community
to
submit
proposals
for
improving
the
the
protocol
or
standards,
and
it's
been
super
exciting
to
see
net
submissions
come
in
from
the
community
and
we
hope
to
see
even
more
from
Community
groups
to
and
individual
contributors
and,
as
we've
been
getting
more
NEP
submissions.
A
We
we
wanted
to
make
sure
that
we
have
a
way
to
actually
move
them
forward,
to
review
them,
make
decisions
and
determine
the
next
steps
so
that
they're
not
just
sitting
indefinitely.
So
that
is
where
the
working
groups
and
the
voting
stage
comes
in,
and
the
working
groups
really
is
a
way
to
help
operationalize
the
review
of
the
naps
and
the
idea
is
to
have
multiple
working
groups,
each
focusing
on
a
different
ecosystem
need
and
to
have
subject
matter,
experts
in
each
group
who
can
help
create,
focus
and
enable
us
to
move
faster.
A
So
we've
already
kicked
off
some
working
groups
previously
the
protocol
working
group
and
the
contract
standards,
and
today,
as
I
mentioned,
we're
kicking
off
the
wallet
standards.
One
and
putting
these
groups
into
practice
is
a
gradual
approach.
It's
going
to
require
iteration
flexibility
as
we
learn
what
works,
what
doesn't,
but,
as
in
the
future,
we
hope
to
introduce
more
groups
and
to
empower
the
community
to
to
run
them.
A
So,
just
to
make
sure
everyone
is
clear
on
the
rules
that
are
involved.
There
are
four
key
ones.
We
have
author,
moderator,
reviewer
and
approver.
The
author
is
the
person
who
writes
The
Proposal
the
nap.
The
moderator
is
the
person
who
facilitates
the
process
and
helps
make
sure
that
maps
are
moving
forward.
The
reviewer
the
subject
matter.
A
Experts
is
the
person
who
ensures
the
technical
viability
of
the
net
kind
of
reviews
that
and
then
the
approver,
the
working
group
member,
the
one
are
the
ones
who
make
the
decision
and
the
process
itself,
as
outlined
in
nep001,
looks
like
this.
Basically,
there
are
three
stages:
draft
review
and
voting
and
two
outcomes
approved
and
rejected,
and
all
the
roles
that
I
just
mentioned,
help
move
the
net
through
this
stages
and
towards
the
outcome,
and
a
lot
of
this
happens
asynchronously
on
the
nip
itself.
A
If
you
go
to
the
nap,
you
will
see
many
comments
that
relate
to
this
process,
but
really
when
we
get
to
the
voting
stage,
we
have
a
working
group
meeting
like
the
one
today
where
we
come
to
discuss
the
nap
and
formalize
the
decision
for
voting,
and
that's
exactly
what's
happening
now.
We're
here
to
execute
this
process,
look
at
a
proposal
that
was
in
the
review
stage.
Then
we
want
to
move
to
the
to
the
voting
and
so
yeah.
A
Our
goal
is
to
have
the
the
champion
the
author
present
it
to
to
everybody
and
then
go
into
the
voting
decision
so
before
we
jump
in
I,
do
want
to
come
back
to
introductions
and
and
kind
of
give
a
little
bit
of
an
overview
of
everyone.
That's
here.
So,
let's
start
with
the
working
group
members
and
I'd
like
to
hand
it
over
to
Cameron.
B
Hey
everybody
how's
it
going.
My
name
is
Cameron.
Dennis
I
have
been
working
at
near
foundation
for
the
last
two
years,
or
so
primarily
onboarding
a
lot
of
infrastructure
projects
helping
run
the
Grant
Program,
essentially
whatever
needs
to
get
done,
was
pretty
much.
My
job
now
I'm
spinning
out
of
near
Foundation
to
start
something
new
called
The
Banyan
Collective,
to
build
that
more
bottom-up
approach
to
ecosystem
growth,
primarily
in
the
United
States.
So
what
this
means
is
we
run
these
Builder
groups.
B
So
if
you're
like
a
wallet
Builder,
you
can
connect
with
all
the
other
wallet
Builders
to
identify
what
naps
are
missing
because
we
do
not.
We
do
need
that
necessary
line
of
communication
between
the
ecosystem
and
the
standards
bodies,
so
uniting
these
groups
every
every
two
weeks
or
so
so
we
have
a
wallet,
onboarding
and
payments
group
subgroup,
custody
and
recovery
subgroup
and
mobile
Integrations.
B
So
if
you're,
a
wallet
Builder
an
nft,
Builder
dial
Builder
come
get
in
touch
with
me,
I'm
happy
to
connect
you
with
other
builders
in
the
space
to
identify
missing
standards.
We
also
organize
a
ton
of
meetups
hackathons,
essentially
anything
that
people
need
in
order
to
succeed.
If
you
need
audits,
let
me
know
if
you
need
a
VC
referral.
Let
me
know
if
you
need
legal
incorporation
support.
Let
me
know,
essentially
this
like
network
of
support
for
Builders
and
Founders
and
in
your
ecosystem.
So
thanks
for
having
me.
C
Hey
everybody,
I'm
Daryl,
Collins
I
was
hired
to
originally
to
work
on
the
near
wallet.
Actually,
wallet.near.org
wallet
worked
on
that
for
about
a
year
and
these
days,
I'm
broadening
scope
a
little
bit
across
the
entire
JavaScript
ecosystem.
So
I
was
involved
in
the
JavaScript
SDK
design
and
implementation
and
we're
in
the
midst
of
taking
over
and
kind
of,
transforming
the
near
API
of
GIS
ecosystem
into
a
more
modern
and
consistent
API.
D
A
E
F
Hey
folks,
I'm
Vlad
AKA
for
all,
and
you
can
see
me
in
many
of
the
posts
all
around
the
system-
I
joined
here,
originally
nearing
quite
early
on
and
been
involved
with
many
of
the
developer,
tooling
and
I
delighted
to
see
that
nap
process
is
getting
on
the
next
step
on
the
next
level
of
bringing
the
ecosystem,
aligned
and
yeah.
My
role
here
would
be
just
moderating
the
and
helping
the
wall.
A
C
Awesome
awesome
so
I've
already
introduced
myself.
Clearly,
I
can
talk
a
little
bit
about
Lewis
and
why
this
was
replaced
as
context.
Lewis
is
working
as
a
contractor
and
he
got
a
new
role.
So
while
he
did
a
great
job
on
getting
the
NEP
built
to
this
point,
there
was
a
few
changes
that
needed
to
be
made
and
it
was
made
in
a
fork
so
essentially
I've
taken
it
over,
so
that
we
could
maintain
it
in
the
main
repo,
but
the
Genesis
of
this.
C
Definitely
the
credit
goes
to
Lewis
for
doing
the
majority
of
the
hard
work
and
getting
all
of
the
text
on
the
page
we
just
kind
of
tweaked
it
according
to
indeed
silent
collapse.
We
tweaked
it
according
to
our
our
feedback
that
we
had
gotten
from
you
guys
in
the
community
and
at
this
point
it's
ready
to
really
get
rolled
cool.
So
I
guess,
let's
step
into
a
little
bit
of
an
explanation
about
what
this
is.
C
You
know
what
what
is
the
injected
wallet
API
and
why
is
it
important
so
there's
there's
two
major
things
that
we
kind
of
boil
down
to
at
a
very
high
level
that
are
critical
for
this.
This
NEP
one
is
that
we're
going
to
be
defining
a
set
of
interfaces
that
are
consistent
for
all
wallets
that
can
be
interacted
with
directly
from
the
d-app
context.
Using
direct
JavaScript
calls
like
there's
no
bridging
involved.
There's
no
messaging
protocols,
there's
no
browser
redirects.
C
C
In
the
wallet
selector
of
allowing
us
to
make
these
wallet
configurations
fully
declarative
without
any
kind
of
moving
parts
or
code,
so
that
we
can
have
the
list
of
wallets
be
dynamic
so
that
the
app
developers
don't
need
to
ship
an
update
to
wallet
selector
in
order
to
show
new
wallets.
So
this
is
kind
of
the
building
blocks
of
a
a
large
piece
of
work
moving
forward
and
also
is
going
to
get
some
immediate
benefits
for
everybody,
who's
implementing
into
wallet,
selector
or
building
new
wallets
there's.
C
Also,
one
of
the
critical
things
about
mep408
is
that
it
adds
a
new
concept
of
when
you
connect
to
a
wallet.
You
can
return
more
than
one
account,
and
this
is
something
that
we
had
some
discussion
about
in
the
NEP
pull
requests.
It's
it's
a
little
bit
different
than
the
current
wallet
implementation
for
near
your
wallet
or
nine
year.
Wallet
and
not
all
wallets
will
have
to
support
this
functionality.
They
can
just
return.
C
With
the
wallet
connect
standard,
the
bridge
wallet
standard
has
already
been
merged,
which
allows
people
to
use
wallet,
connect
to
link
their
wallets,
and
we
wanted
to
make
it
consistent
so
that,
regardless
as
to
whether
or
not
you're
connecting
to
an
extension
based
wallet
or
using
a
bridge-based
wallet
that
the
API
was
was
similar,
that
you
would
get
the
same
kind
of
data
type
back
from
either
one
an
array
of
accounts.
Instead
of
just
you
know
a
single
element
and
you
don't
have
to
do
any
type
checking
to
work
with
it.
C
So
at
a
high
level,
these
are
the
two
things
that
were
kind
of
critical
for
the
the
408
requirements
and
we've.
We
at
this
point
have
gone
through
some
feedback
on
the
on
the
pull
request.
So
we've
made
some
iterations.
There
are
actually
some
really
good
suggestions
made
from
the
community
that
we
incorporated
in
the
last
week,
or
so
so
we've
got
some.
We.
We
definitely
want
these
to
be
a
collaborative
process
and
I
really
have
to
give
props
to
everybody
from
the
community.
C
C
Please
sign
a
transaction,
and
then
we
added
at
Community
feedback,
we've
added
the
ability
to
detect
Network
support
on
a
wallet
as
part
of
this
NEP.
So
a
method
that
will
allow
you
to
query
a
wallet
and
say:
do
you
support
this
wallet?
This
Network
can
I
switch
to
test
net?
Will
there
be
any
accounts,
or
will
this
Wallet
not
even
function
on
test
net?
For
example,
if
that's
the
case,
that's
the
the
basic
apis
that
we've
got
here.
C
The
one
other
thing
that
we've
added
to
this
that
was
also
brought
about
due
to
community
feedback,
was
the
ability
to
compose
partial
transactions
when
you're
requesting
from
the
wallet.
So
in
particular,
we've
allowed
the
account
ID
to
be
an
optional
parameter
which
actually
aligns
with
the
way
that
your
wallet
has
always
worked
in
your
wallet.
C
You
can
provide
an
account
ID,
but
actually,
when
you
land
in
the
wallet
we'd
like
to
choose
a
different
account
ID,
if
you
want
to
and
it
gets
signed
by,
whatever
account
the
the
near
wallet
allows-
allows
the
user
to
choose.
So
this
allows
open-ended
cases
allowing
the
this
API
to
to
create
basically
a
partially
composed
transaction
that
doesn't
have
an
account
associated
with
it
allows
for
this
basic
use
case
of
I'd
like
a
donate
button.
I
don't
want
somebody
to
log
in
I'm,
not
running
a
d
app,
they
don't
need
a
function.
C
Call
access
key,
but
I
do
want
somebody
to
be
able
to
donate
using
their
wallet
by
clicking
on
this
button,
and
in
those
cases
we
don't
know
what
account
somebody's
going
to
use,
there's
no
reason
to
add
a
very
a
thick
layer
of
near
API
JS
and
a
wallet
selector
and
a
connect
concept.
These
are
going
to
go
into
web
2,
apps,
usually
where
they
just
want
to
link.
So
that's
part
of
the
spec.
C
C
We
defined
a
basic
event:
spec
there's
only
one
event
right
now,
which
is
accounts
changed
this
synchronizes
with
the
wallet
connects
specification,
which
has
a
similar
event
that
is
emitted
across
the
wallet
connect
bridge
when
you
choose
in
in
a
wallet,
connect,
enabled
wallet
to
change
which
accounts
are
exposed
to
a
certain
d-app.
So
we've
added
that
event.
Now,
there's
only
one.
This
is
Forward
Thinking.
There
could
be
any
number
of
events
in
the
future.
C
If
anybody
has
any
ideas
around
more
events,
we
should
add
those
to
the
NEP
in
the
future,
but
that's
the
basic
scaffolding
that
408
adds
and
the
benefits
that
we're
going
to
get
out
of
them
all
right.
So
next
up,
we
have
basically
just
a
kind
of
an
overview.
I
wanted
to
just
make
sure
that
everybody
understood.
You
know
how
we
settled
on
this
functionality
and
how
the
journey
that
we
took
to
get
here.
C
So
there
was
some
good
feedback
and
discussions
both
on
the
original
pull
request,
370,
which
Lewis
had
created
and
also
then
on
408.
You
guys
followed
up
after
we
moved
it
into
a
new
pull
request
where
I
could
add
some
functionality,
so
I
just
wanted
to
kind
of
call
those
out
and
point
out
what
we
had
changed
and
and
the
whys
for
these
things.
C
So
one
of
the
the
first
thing
here
was
that
there
was
an
inversion
of
control
here,
decided
on
where
the
initial
implementation
of
this
WEP
was
that
or
NEP
was
that
the
network
selection
would
actually
be
driven
in
an
inverted
way.
The
wallet
the
the
wallet
would
choose
which
network
was
selected
to,
but
actually
the
D
app
also
has
a
concept
of
awareness
of
which
network
it
works
on,
and
it
was
very
awkward
to
have
to
synchronize
these
two
things.
C
There
was
no
way
for
a
d
app
to
signal
to
a
wallet
which
network
that
it
was
using
directly.
So
we've
added
a
network
ID
parameter
to
the
connect
API,
which
allows
the
app
to
connect
to
a
wallet
and
request.
A
specific
network
will
will
function
when
it
connects,
and
this
also
standardizes
or
it.
It
creates
a
consistent
deterministic
interface
that
somebody
can
use
to
connect
to
that
Network.
C
So
one
of
the
benefits
of
having
this
come
through
as
a
connect
method
is
I,
could
connect
to
the
wallet
twice
in
theory
or
I
could
connect
to
two
different
Wallets
on
two
different
networks.
This
opens
the
door
to
some
cool
things
like
a
split
screen
where
you
can
see
the
results
of
your
test
net
on
your
main
net
accounts
next
to
each
other
interact
with
both
deploy
to
both
those
types
of
use
cases,
and
it
simplifies
the
understanding
for
the
developer.
C
C
This
is
not
something
that,
with
an
injected
wallet
even
makes
sense
in
all
cases,
and
it
wasn't
very
forward
thinking,
because
one
of
the
important
things
that
we're
looking
to
implement
in
the
near
future
here
is
the
ability
to
verify
account
ownership
without
actually
creating
a
limited
access.
Key
on
the
near
account.
That's
signing
into
a
d-app,
so
imagine
a
case
where
you
want
to
run
a
forum.
You
want
people
to
log
in
with
their
near
accounts
as
an
identity,
but
you
don't
actually
want
to
pollute
their
account
with
a
full,
a
limited
access.
C
Key
that
they're
never
going
to
actually
use
on
chain
this.
This
concept,
this
new
concept
of
verifying
account
ownership,
may
happen
instead
of
the
sign
in
option
where
you
actually
actually
sign
in
using
a
limited
access
key.
So
by
separating
the
connect
action
and
the
signing
actions,
we've
future
proofed
the
API
so
that,
when
we
add
verify
ownership,
you
can
follow
a
different
path.
C
You
can
choose
to
connect
to
a
wallet
first
and
then
either
verify
ownership
or
sign
in,
and
this
also
has
a
benefit
of
simplifying
the
error,
failure
modes
of
the
of
the
different
methods.
So,
when
I
call
connect
to
a
wallet,
the
only
things
that
can
fail
are
connecting
to
the
wallet
and
getting
a
list
of
accounts.
A
transaction
on
the
blockchain
cannot
fail
because
there
is
no
transaction
for
connecting
to
a
wallet
whereas
signing
in
there's
a
transaction.
So
the
failure
modes
of
that
could
be
any
number
of
reasons
why
the
transaction
might
fail.
C
The
third
thing
is
the
the
lack
of
ability
to
actually
detect
whether
or
not
a
particular
network
ID
was
supported
by
a
wallet.
The
original
NEP
just
didn't
facilitate
this
at
all.
It
assumed
that
everybody,
every
wallet
would
support
all
networks.
It
alluded
to
this
earlier.
Actually,
in
the
discussion,
we've
added
a
supports
Network
method
to
the
spec
that
wallets
should
Implement,
you
give
it
a
network
ID.
The
wallet
returns
with
a
Boolean,
true
or
false.
Should
this
should
this
be
connected
to?
C
Can
this
be
connected
to
Via
this
wallet
and
we've
made
this
an
async
API?
It
returns
a
promise
just
in
case
somebody
on
the
wallet
side
needs
to
run
a
little
bit
of
async
code
before
they
decide
whether
or
not
they
support
that
network
so
trying
to
make
sure
that
we
don't
have
to
break
that
in
the
future.
For
any
reasons
such
as,
let
me
do
a
network
request
before
I
decide
whether
or
not
that
Network
supported
all
right.
C
We
already
spoke
about
the
connect
method,
returning
an
array
of
accounts
after
connecting
and
I
talked
earlier
about
this.
The
reason
the
main
reasoning
for
this
is
to
normalize
the
apis
so
that
the
bridge
standard,
connecting
to
a
bridge
wallet
and
connecting
to
an
injected
wallet
will
work
the
same
way
at
a
high
level.
You'll
get
the
same
kind
of
of
data
type
back
from
your
connect
calls,
regardless
as
to
whether
or
not
you're,
connecting
through
the
bridge
or
via
an
injected
wallet.
C
I
anticipate
that
we,
we
may
do
some
if
we
can
get
these
close
enough.
These
two
specs
that
we
actually
could
pull
some
of
this
definition
up
into
a
third
NEP,
that's
shared
by
both
of
these.
If
we
can
keep
these
interfaces
as
close
together
as
possible,
then
it's
going
to
make
it
easier
for
everybody
who's
implementing
these
in
their
wallets.
C
So
the
the
main
goal
here
with
the
connect
returning
an
array
of
counts,
is
to
make
sure
that
you
we
do
support
the
ability
to
connect
to
more
than
one
account
at
the
API
level.
There's
not
a
requirement
that
every
wallet
make
wallet
Builder
go
out
and
build
an
interface
that
lets
you
select
any
number
of
accounts.
You
can
still
have
your
connect.
Ui
in
your
wallet
only
allow
the
user
to
select
a
single
account.
C
The
important
thing
is
just
that:
programmatically
we're
returning
that
account
in
an
array,
so
the
data
type
is
normalized
and
consistent,
and
the
last
thing
that
I
wanted
to
bring
up.
There
was
some
discussion
about
this.
This
is
ongoing
discussion
actually,
which
is,
where
does
a
key
pair,
live
for
sign-in
requests
and
to
give
some
context
here.
C
We
facilitate
interrupt
Interruption,
free
usage
so
like,
if
you're
playing
a
game,
for
example,
where,
when
you
buy
new
equipment,
it
has
to
be
written
to
the
blockchain
estate
when
you
click
on
I
want
this,
this
equipment
associated
with
my
character
that
transaction
that
updates
the
state
Could
Happen
entirely
in
the
bot.
In
the
background
you
wouldn't
have
to
have
the
wallet,
pop-up
or
a
ledger
prompt
on
your
machine
going.
Oh,
let
me
approve
this
transaction
with
a
ledger
16
times,
because
I
just
moved
16
pieces
of
equipment.
C
You
know
it's
definitely
not
a
scalable
solution.
So
the
idea
around
these
key
pairs
for
limited
access
function
call
Access
Keys
existing
in
the
d-app
context
is
specifically
to
facilitate
these
kind
of
interruption-free
interactions.
Now
some
wallets
have
chosen
another
route,
so
they've
actually
made
the
sign
in
request.
Keep
that
key
locally
inside
of
the
wallet
storage.
C
This
is
something
that
we
generally
would
recommend
against,
because
it
goes
against
the
basic
concept
of
being
able
to
submit
transactions
directly
from
the
D
app.
However,
if
a
wallet
does
implement
this
type
of
interaction,
we
have
added
to
this
NEP
that
we
recommend
that
interactions
using
that
limited
access
key
are
confirmation,
free
or
at
least
limited
confirmation,
because
the
whole
idea
around
this
limited
access
key
is
that
it
shouldn't
interrupt
the
user's
interaction
with
the
with
the
blockchain.
So
in
a
perfect
world,
these
Keys
should
just
exist
in
the
D
app.
C
This
is
how
it
works.
Normally
is
the
d-app
actually
generates
this
key,
and
then
they
request
that
the
key
is
added
by
the
wallet
and
they
own
that
key,
so
they
can
keep
using
it.
But
if,
if
a
wallet
does
keep
these
limited
access
Keys
internally,
there
is
a
nice
benefit,
which
is
you
go
to
your
wallet
and
the
key
is
there,
even
if
you
added
it,
maybe
on
another
machine
depending
on
how
your
wallet
is
built,
it's
possible
that
that
key
might
be
available
for
more
in
more
cases.
C
C
However,
we've
added
guidance
for
a
case
where,
if
you
choose
to
own
these
keys
in
the
wallet
side
of
things,
please
make
sure
that
you
don't
interrupt
the
user's
experience,
because
if
you
require,
if
you
apply,
require
a
confirmation
for
every
transaction
that
comes
through
then
essentially
we've
kind
of
eliminated.
The
benefit
of
this
limited
access
key.
The
whole
purpose
of
it
is
to
reduce
the
amount
of
blockers
that
users
encounter
while
they're
interacting
with
the
D
app
that
uses
transactions
on
chain.
A
Thank
you
so
much
Daryl
for
for
that
comprehensive
summary
and,
and
really
also
thank
you
to
everyone
that
has
voiced
their
their
concern
and
thoughts.
You
know.
Obviously
it
is
evident
that
that
you
have
taken
the
time
to
really
look
through
them
and
everyone,
and
that's
great
so
before
we
move
on
to
the
next
voting
stage.
A
B
Yeah
to
me
this
is
pretty
straightforward.
There's
a
lot
more
wallets
building
an
injective
ball
standard
is,
is
really
just
almost
a
prerequisite
to
help
ensure
the
security
across
every
injected
wallet
on
here,
and
it
just
seems
like
a
pretty
important
like
beginning
piece
of
this
growing
ecosystem,
so
also
I
mean
it
tremendously
helps
I
use.
B
Many
wallets
I
would
benefit
from
this
directly
I've
been
prompted
many
times
to
open
up
accounts
or
log
into
accounts
with
wallets
that,
if
I'm
already
logged
into
account
it's
it's
just
not
a
clear
user
experience.
So
hopefully
this
will
streamline
that
and
it
also
just
kind
of
aligns
with
the
general
onboarding
experience
for
ethereum
users
with
you
know
that
being
prompted,
and
especially
with
many
different
types
of
Wallets,
on
your
being
browser
based
as
well,
it
just
seems
to
be
a
pretty
pretty
straightforward.
B
You
know
thing
for
the
ecosystem,
so
yeah,
it's
a
it's
an
approval
and
by
me,
I've
talked
to
a
lot
of
wallet
builders
on
near
this
will
make
their
lives
much
easier,
get
them
to
focus
on
the
things
that
actually
make
them
different
from
one
another
and
yeah
I
mean
I.
I
haven't
really
seen
many
many
big
issues
with
this
proposal.
So
it's
it's
an
overwhelming.
Yes
for
me,.
D
Yeah
I
think
we
had
like
a
lot
of
discussion
on
the
pr
itself.
There
was
some
stuff
with
the
interface
as
well.
That
was
really
good
about
like
signing
transactions
and
stuff
So
like
like
not
constru,
not
having
the
dabs
have
to
construct
the
whole
transaction
on
their
side
and
instead,
just
providing
like
a
list
of
actions
or
an
optional
signer
ID
was
also
a
really
like
partially
constructing
the
transaction.
A
Very
cool,
okay,
well,
I
think
that
leads
us
pretty
smoothly
into
the
voting
stage.
You
know
we
need
two-thirds
majority
to
move
forward
and
I
already
heard
this
verbally
that
that
we're
living
in
that
case,
but
I'd,
like
maybe
an
official
working
group
member
to
maybe
present
the
decision
just
so
that
we
have
that
so
maybe
Daryl
do
you
wanna.
C
Yeah,
so
my
vote
also
would
be
to
definitely
merge
this,
as
everybody
can
probably
tell
since
I
took
this
over
and
kind
of
shepherded
it,
the
last
The
Last
Mile,
so
to
speak,
so
we've
got
a
yes
from
Austin
and
we've
all
studied
yes
from
Cameron.
This
is
definitely
going
to
improve
things
and
give
some
clarity
for
folks
that
are
building.
C
You
know
a
lot
of
folks
that
are
building
the
wallet,
sadly,
are
looking
at
existing
other
wallets
and
trying
to
kind
of
stumble
their
way
through
how
these
apis
should
work,
so
I
think
having
a
centralized
document
for
this.
You
know
this
is
one
of
these
cases
where
centralization
is
really
helpful.
I
know
one
place
to
go
to
find
out
how
all
of
this
stuff
should
work.
So
at
this
point
we've
got
kind
of
a
quorum
here.
Everybody
is,
everybody
is
happy
to
get
this
merged.
I
think
this
one's
going
to
go
into
approved.
C
A
Awesome
cool
well
yeah.
We
will
definitely
formalize
the
decision
on
the
net
itself
right
after
this
meeting
and
we'll
also
post
share
it
out
in
you
know
our
social
channels
and
the
developer
governance
website,
just
so
that
others
can
learn
about
it,
but
yeah,
that's
pretty
exciting,
so
I
think
also
just
to
talk
about
next
steps
and
implementation
considerations.
I
do
want
to
move
over
to
to
the
next
slide
over
here
and
yeah
Daryl.
Were
you
going
to
speak
to
this
one
as
well?
Yep.
C
Absolutely
okay,
so
so
until
this
week
the
implementation
for
this
was
relatively
done.
Actually,
there
was
already
kind
of
code
inside
wallet
selector
that
would
Implement
these
apis,
but
now
that
we've
added
a
couple
of
things,
there's
definitely
some
implementation
to
be
done.
Wallet
selector
currently
is
kind
of
this.
The
the
entry
point
for
all
the
app
development
in
the
near
ecosystem
because
of
the
fact
that
it
connects
to
any
number
of
wallets,
so
we're
going
to
go
and
add
top
level
accessors
for
the
new
features
like
is
supported.
C
Network,
for
example,
should
have
a
method
that
is
passed
through
via
the
wallet
selector
interface
that
returns
that
result
for
the
wallet.
That's
currently
connected
those
types
of
things
and
we
have
Sprint
planning
on
Monday
morning
so
right
now,
it's
Friday
just
for
anybody
who's
watching
this
later
so
we're
talking
about
three
days
from
now.
C
We
have
a
Sprint
planning
where
I
think
that
we're
going
to
have
resources
who
can
step
into
wallet,
selector
and
add
those
accessors,
so
that
if
anybody
does
implement
these
apis,
the
new
ones
that
we
just
decided
on
earlier
this
week,
wallet
selector
will
expose
those
upstream
and
if
a
wallet
has
not
implemented
those
apis,
we'll
decide
on
some.
What
that
behavior
should
be
and
wallet
selector
should
throw
an
error.
Just
return.
C
False,
we'll
we'll
put
that
up
in
a
PR
and
I
will
actually
Loop
the
folks
in
who
had
added
some
comments
on
the
pull
requests
for
408
and
for
370,
so
that
we
can
just
make
sure
that
everybody
agrees
on
on
the
behaviors
there
inside
the
wallet
selector,
since
that's
kind
of
the
the
gateway
to
the
wallets
of
the
ecosystem.
Right
now,
we
want
to
make
sure
that
everybody
agrees
about
how
those
cases
should
end
should
be
handled
for
a
wallet
that
hasn't
implemented.
That
part
of
the
the
NP.
A
C
And
then,
now
that
this
is
merged,
also
we
I'll
do
some
reaching
out
for
anybody.
Who's
already
got
a
wallet
so
now
that
we
have
a
standard
API
for
this,
such
as
like
request,
sorry
side
and
send
transaction
or
sign
transaction.
These
names
of
these
methods
have
been
normalized.
I
know
that
some
of
the
existing
wallet
code
that
we
use
in
wallet
selector
has
shims
to
call
different
methods
on
wallets.
C
So
there
will
also
be
simple
requests
coming
from
wallet
Builders
to
conform
to
this
API
that
will
update
their
plugins,
there's
a
plug-in
for
each
wallet,
essentially
in
the
wallet
selector.
So
those
are
also
PR's
that
we'll
need
to
land.
These
are
kind
of
community
PR's
from
the
wallet
Builders
themselves.
Once
you
got.
If
you
have
any
methods
that
don't
exactly
match
up,
I
think
I
saw
in
one
of
the
wallet
plugins.
There
was
a
method
called
request:
sign
transaction
instead
of
just
sign
transaction.
So
this
is
an
obvious
one.
C
Where
now
that
there's
an
NEP
that
wallet
Builder
will
update
their
wallet.
So
the
name
of
this
method
is
find
transaction
instead
of
request,
sign
transaction,
and
then
they
will
need
to
open
a
PR
to
wallet
selector.
That
then
updates
our
usage
inside
of
that
plugin,
and
this
is
actually
really
important
because,
as
I
alluded
to
earlier
on,
our
long-term
goals
here
is
to
have
Dynamic
wallet
the
list
of
wallets
that
you
can
choose
from
to
be
dynamic
without
forcing
the
app
authors
to
constantly
update
the
wallet
selector
package
and
by
conforming
to
these
apis.
C
You
are
future
proofing,
your
wallet
so
that
when
we
move
to
Dynamic
wallet
selection,
it
will
still
show
up.
It
can
still
be
interacted
with
because
you've
conformed
of
these
apis.
So
if,
if
I
have
any
advice
for
anybody
who's,
a
wallet
Builder
here,
it's
definitely
don't
let
this
one
fall
behind
or
you
might
be
surprised
when
we
go
to
migrate
to
Dynamic
wallet
selection.
We
have
hey
now
we
can
show
up
to
you,
know
60
wallets
or
something
like
that
dynamically.
C
Without
the
d-app
author
having
to
publish
out
new
code,
we
don't
want
your
wallet
to
be
left
behind
and
you
right
now
have
all
the
context
for
what
needs
to
happen.
So
the
the
minimal
amount
of
effort
is
to
do
it,
while
it's
fresh
in
your
mind,
you're,
not
looking
at
reviewing
all
this
stuff
like
three
months
down
the
road
or
whenever
we
get
to
this.
This
Dynamic
wallet,
selection.
A
C
C
Poc
was
actually
built
by
the
same
fellow
who
opened
this
PR,
the
original
PR
for
this
NEP
370,
and
there
actually
is
a
bridge
standard
that
was
already
published
in
the
NEP
repo
that
was
actually
built
for
that
purpose,
to
Define
compatibility
with
wallet,
connect
and
apis
that
follow
the
wallet
connect
standard.
So
you
can
see
that
standard
in
the
neps
I'll
just
put
a
link.
C
Actually
it's
in
it's
in
standards
in
the
Naps
repo
I'll
put
a
link
in
the
chat
right
now
that
just
goes
to
that
wallet,
documentation,
here's
the
actual
Bridge
wallet
this
was
brought
about
before
we
had
these
working
groups.
So
if
you
have
any
yeah,
if
you
have
any
feedback
on
this
standard
feel
free
to
bring
these
up,
you
know:
there's
nothing
is
set
in
stone.
I,
don't
think
that
anybody
has
fully
implemented
a
wallet,
connect,
compatible
wallet,
yet
I,
don't
think.
C
There's
one
live
yet
so
by
all
means,
if
you
want
to
use
wallet,
connect,
try
it
Implement,
go
forth
and
build,
and
if
you
have
any
problems,
just
let
us
know
the
wallet
selector
code
base
is
where
the
plug-in
all
exists,
and
that
is
of
course
right
here.
I'll
put
that
in
the
chat
as
well,
and
you
can
see
right
inside
of
that
directory
that
I
linked
to
you
there's
a
wallet
connect
folder
that
has
the
wallet,
connect
proof
of
concept.
C
So
that
is
definitely
something
that
we
want
to
support.
I
know
that
at
least
one
wallet
is
working
on
building
something
that
uses
that
API
and
I
haven't
heard
from
them.
They
haven't,
they
haven't
reported
any
major
issues
with
it,
but
I
do
want
to
give
you
just
a
you
know
a
little
bit
of
a
disclaimer
there
that,
because
I
as
far
as
I
know,
nobody
is
end
to
end
implemented
this.
Yet
you
might,
you
might
have
feedback
on
it
and
should
be
totally
reasonable.
If
you
do,
let
us
know.
A
C
I
believe
that
in
the
long
term,
in
my
mind
at
least
the
perfect
solution
for
this
would
be
a
Dao
where
actually
the
wallets
that
are
able
to
be
displayed.
The
list
of
wallets
exists
on
chain
and
is
query
by
wallet.
Selector
using
a
view,
function
call
against
the
blockchain,
and
then
it
pulls
back
some
Json
that
describes
how
that
wallet
works
and
that's
it
we're
done,
and
now,
when
a
new
wallet
Builder
comes
in,
you
know,
right
now
we
got
a
bit
of
a
clunky
process
for
these
reviews.
C
We're
opening
pull
requests
for
each
wallet
that
we
add.
It
would
be
great
if
there
was
not
a
pull
request
for
each
wallet
and
instead
people
voted
on
a
dow
using
an
app
that
we
built
that
allows
you
to
vote
and
when
a
wallet
has
been
voted
to
be
supported
it
by
the
list
of
wallet
selector
wallets,
then
it
just
gets
added
to
the
response
that
you
get
when
you
call
that
view
function.
C
It
will
absolutely
include
something
like
icons.
I
was
actually
just
talking
to
Jane
earlier
this
week.
Actually
about
hey,
could
we
include
an
icon
set
and
allow
people
to
just
give
us
a
string,
which
is
what
icon
name?
Would
it
be,
and
we
could
we
could
have
that
be
part
of
the
dynamic
information
and.
A
C
So
this
NEP
is
different
than
the
bridge
wallet,
so
there
is
a
bridge
wallet
standard
that
has
already
been
landed
and
I
linked
that
in
the
chat,
maybe
maybe
I,
linked
it
before
you
even
sent
this
message.
I'll
put
it
in
there
again
just
to
make
sure
that
it's
at
the
top,
so
the
bridge
wallet
standard
does
describe
the
the
interface
for
something
that
uses
wallet,
connect
and
then
the
implementation
that
you've
linked
to
here.
So
the
wallet
selector
yeah
that
that
implementation
for
the
the
near
methods.
C
That
is
absolutely
that
is
what
we've
decided
on
for
our
custom
near
interfaces.
So
wallet,
connect
2.0
supports
the
definition
of
blockchain
specific
methods,
so
you
can
Define
your
own
methods
for
each
chain
at
sports,
while
at
connect,
1.0
was
all
ethereum.
Specific
2.0
allows
us
to
Define
these
methods.
So
the
link
that
you
just
gave
me
there.
Leon
is
indeed
the
near
specific
methods
that
we've
added
that
we've
defined
for
the
wallet
can
extended.
A
Cat
on
Sandy,
so
I
think
we're
gonna
move
on,
so
the
last
thing
I
just
wanted
to
cover
is
how
to
get
involved.
Well,
first
of
all,
thank
you
all
for
being
here.
That's
a
great
way
to
get
involved,
just
to
kind
of
be
part
of
the
working
groups
see
what's
going
on,
but
there
have
been
more
ways
to
get
involved
that
I
wanted
to
highlight.
A
So
if
you,
if
you
already
have
a
specific
idea
in
mind
for
something
that
you
want,
you
know
to
to
propose,
we
highly
encourage
you
to
to
author
a
nap
and
submit
one
or
to
join.
Existing
working
group
calls
like
the
one
we
have
today.
If
you
don't
know
what
you
want
to
build,
another
great
way
to
get
involved
is
to
join
other
community
groups,
which
are
basically
groups
of
people
from
the
community
that
that
meet
on
a
shared
topic
of
interest.
A
You
know
from
a
specific
idea
to
a
concern
or
a
passion.
Cameron
has
been
involved
with
like
three
different
Community
groups
for
for
wallet,
so
if
you're,
if
you're
not
aware
of
them,
please
check
them
out
on
the
near
governance,
Forum
website
and
I'm
sure
Cameron
can
show
some
links
as
well
or
if
it
wants
to
speak
to
it,
he
can
yep.
B
A
plan
of
attack
like
how
do
we
actually
prioritize,
which
neps
to
go,
go
forward
with
keep
in
mind
that
there
are
many
verticals
in
this
industry
and
so
wallets
are
are
one
of
them,
but
by
far
one
of
the
most
important,
so
I
dropped
the
calendar
in
the
chat
here.
So
if
you
want
to
sign
up
for
that,
you
will
be
able
just
to
see
every
time
that
we
meet
next
Tuesday
we're
having
our
general
wallet
Builder
meeting.
That's
sorry!
That's
next!
Wednesday
at
11
30
a.m.
B
B
So
yep
that's
going
to
be
the
meeting
where
we
keep
everyone
update,
and
we
also
have
a
very
active
telegram
where
you
can
join
and
ask
questions
around
about
pending
neps
as
well
as
just
like
what
Fiat
on
ramps
you
are
native
to
near
what
kind
of
custody
Solutions
are
available.
Essentially,
anything
well
related
can
go
into
that
chat
so
feel.
Please
get
involved
we're
here,
for
you.
A
So
yeah
and
you
can
also
start
your
own
Community
groups
and
all
the
information
is
available
on
neo.org
developer
governance
and,
as
Max
mentioned,
also,
if
you're
interested
in
implementation,
we
do
have
a
form
on
that
website
that
you
can
fill
out
and
let
us
know-
and
we
will
also
post
the
recording
from
today
on
that
website,
as
well
as
future
meetings
as
well.
So
I
just
want
to
give
one
more.
A
Thank
you
to
everyone
that
has
been
involved,
especially
the
the
author,
the
original
author
Lewis,
who
spent
a
lot
of
time
thinking
about
this,
this
snap
and,
of
course,
to
Daryl
who
helped
kind
of
champion
and
take
it
over
the
Finish
Line.
The
working
group
members
Cameron
Daryl
Osman,
the
moderators
and
everyone
from
the
community
who
has
participated
so
really
excited
to
to
have
this
first
wallet
standards,
nip
approved
and
excited
to
decentralize
the
development
of
near
together
in
more
working
group
meetings
soon.
So
cool
well
I,
think
that
covers
it
for
today.