►
From YouTube: Wallet+ SDK Proposal Explained by Aaron Cox
Description
Wallet+ PDF : https://bit.ly/wallet-plus-english
I. Abstract
The next generation of internet technologies are being created today and bring new approach-
es for cross-platform applications, games, the internet of things, peer-to-peer architectures,
and a more decentralized web ecosystem.
The proliferation of EOSIO systems throughout these new technologies will depend in part on
the quality and completeness of the client-side Software Development Kits (SDKs). The easier
these tools are for developers to utilize and the more features they offer, the more likely devel-
opers are to integrate EOSIO. The ease of use will allow them to focus on their product devel-
opment, marketing strategies, and other more critical business needs.
Our goal is to take the first steps towards creating a capable and modern EOSIO family of
SDKs for all major platforms and programming languages.
The first few steps being:
1. Establishing a series of core EOSIO client protocols.
2. Creating a suite of open-source EOSIO web client SDKs.
Additional steps can be taken in the future to develop non-web clients SDKs (mobile apps,
games, etc) which can take advantage of the knowledge gained during these first two steps.
This proposal aims to create opportunities for developers, designers, and specialists to help
create the foundation for EOSIO to play its part in the decentralized web.
-----
Everything EOS is the official media channel of the EOS Network Foundation (ENF). The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://eosn.foundation
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosn.foundation
#EOS #EOSIO #ENF
A
We
don't
give
people
looking
to
build
applications
enough
tooling,
essentially
to
build
what
they're
trying
to
do.
They
have
to
go,
build
their
own
tooling,
to
actually
build
the
app
that
they
want
to
build,
and
that
is
a
huge
roadblock,
and
it's
also
probably
the
reason
why
a
lot
of
people
build
other
ecosystems.
They
have
the
tools
they
need
and
these
other
ecosystems
just
handed
to
them
and
they
can
focus
on
their
app.
We
need
to
get
to
that
point
with
eosio.
A
So
that
way,
you
know
somebody
wants
to
build
an
nft
gallery
or
marketplace
or
something
where
they
can
just
take
this
tool
set
and
build
their
vision
without
actually
having
to
build
the
core
components
of
the
osio
themselves.
That's
the
general
premise
of
this
entire
proposal
to
start
with,
and
put
a
little
bit
of
context
on
it.
When
we're
talking
about
the
core
development,
there
are
three
major
components:
the
first
one
which
we
started
all
of
this
based
upon
is
the
core
software
itself.
A
It's
the
platform,
it's
nodeos,
it's
the
thing
that
we
all
run
for
black
producers
and
apis.
The
other
two
components
are
the
apis
themselves,
which
we
covered
a
decent
amount
and
the
api
plus
paper
and
in
the
wallet
paper,
the
other
one
is
software
development
kits.
So
just
to
put
that
in
perspective
of
why
this
is
being
brought
forth.
This
is
the
first
proposal.
That'll
probably
be
a
long
series
of
proposals
in
building
a
new
series
of
software
development
kits
for
client-side
technologies
for
eos
io
blockchains.
A
This
first
step
will
be
to
both
build
the
core
protocols
that
every
client
sdk
can
utilize
and
to
actually
build
the
first
full
sdk,
which
would
be
focused
on
web
technologies.
In
the
paper
itself,
it
outlines
it
a
little
bit
throughout
the
paper
that
everything
that
we
learn
while
doing
the
web
client
sdks.
We
can
then
apply
to
things
like
mobile,
apps
or
games
or
whatever
other
type
of
platform.
You
can
imagine
somebody
building
an
eos
io
application
on.
A
You
know
that
maybe
there's
like
metaverse
client,
sdks
and
whatever
new
thing
comes
out
in
the
next
couple
years
as
a
platform
to
target
for
these
technologies.
So
this
proposal
itself
focuses
on
that
web
segment
of
potential
apps
that
are
built
in
the
ecosystem.
The
recommendation
itself
is
what
we're
getting
to
here.
It
is
to
actually
build
a
full
product
suite
for
the
web
environment,
for
these
sdks
it'll
have
its
own
identity,
which
could
be
bound
to
the
new
identity
that
the
branding
and
efforts
are
going
through,
or
it
could
be
completely
standalone.
A
Examples
from
other
ecosystems
like
you,
do
have
some
that
are
branded
specifically
as
aetherium
or
whatever,
or
you
have
things
like
hard
hat
or
morales,
or
these
like
more
ambiguous
words
that
are
focused
on
specific
ecosystems,
but
this
product
suite
for
the
web
would
have
its
own
identity.
The
whole
suite
would
and
then
it
would
have
more
generic
specifications
and
standards
that
will
come
along
with
it.
That'll
be
applied
to
other
non-web
sdks.
A
The
suite
itself
is
a
stack.
This
tree
kind
of
goes
bottom
up
like
the
bottom
is
the
foundation
and
the
top
is
kind
of
the
entry
point
for
new
developers,
so
starting
at
the
top.
The
first
thing
new
developers
are
gonna
have
is
this
starter
kit?
It
is
a
templated
thing
that
consists
of
everything
below
it
and
could
be
modified
to
fit
a
specific
chain's
need
like
theo
or
wax
or
telos
or
any
of
these
chains.
If
they
have
something
specific
and
unique
about
their
chain,
they
could
embed
it.
A
In
this
starter
kit,
the
starter
kit
itself
is
going
to
be
made
up
of
all
the
other
components,
and
it's
recommended.
Here's
where
you
get
started.
The
client
library
is
what
we
would
today
consider
to
be
like
a
ual
or
something
along
those
lines.
This
is
the
integration
point
for
an
application
developer.
A
That
knows
what
they're
doing,
and
they
don't
need
a
starter
kit,
they'll
be
using
the
client
library
and
the
client
library
has
plugins
and
all
of
the
client
library
stuff
is
based
on
the
core
library
which
serves
as
the
foundation
for
any
web
library.
That's
built
upon
this
and
the
core
library
also
has
extensions.
A
Both
the
plugins
and
the
extensions
can
be
chain
specific
or
can
be
chain
agnostic.
It
offers
that
flexibility
that
I
think
we
can
eat
in
eos
io.
The
paper
makes
the
case
for
that.
I
don't
necessarily
have
to
pitch
it
to
you
guys.
This
project
itself
is
to
get
started
as
soon
as
possible.
It's
treating
this
as
core
development
and
creating
the
foundation
for
people
to
build
these
web
applications
on
any
of
these
chains.
A
As
someone
that's
been
working
myself
with
developers
across
all
chains
when
people
have
issues
integrating
anchor,
they
come
to
us
and
whether
that's
an
issue
with
esjs
or
ual,
or
the
swift
or
java
sdks,
how
that
plays
into
their
apps
and
all
these
other
things.
This
is
where
my
team
has
seen
so
many
struggles
in
the
ecosystem.
It
is
that
we
don't
give
people
looking
to
build
applications
enough
tooling,
essentially
to
build
what
they're
trying
to
do.
A
They
have
to
go,
build
their
own
tooling,
to
actually
build
the
app
that
they
want
to
build,
and
that
is
a
huge
roadblock,
and
it's
also
probably
the
reason
why
a
lot
of
people
build
in
other
ecosystems.
They
have
the
tools
they
need
and
these
other
ecosystems
just
handed
to
them
and
they
can
focus
on
their
app.
We
need
to
get
to
that
point
with
eosio.
A
So
that
way,
you
know
somebody
wants
to
build
an
nft
gallery
or
marketplace
or
something
where
they
can
just
take
this
tool
set
and
build
their
vision
without
actually
having
to
build
the
core
components
of
eosio
themselves.
That's
the
general
premise
of
this
entire
proposal
and
we
go
into
a
lot
of
detail
about
the
various
components,
and
we
give
some
examples
like
when
we're
talking
about
identity.
We
give
morales
the
graph
and
a
hard
hat
like
those
are
solid
brands
that
developers
know
of
and
places
where
they
can
go
and
get
started
with
these
technologies.
A
We
also
want
to
include
things
like
training
in
this
and
documentation
and
onboarding
of
developers,
and
really
just
improving
the
developer
experience,
so
they
can
focus
on
what
they
need
to
do.
The
effects
we
believe
just
run
through
those
really
quick
is
that
it's
going
to
improve
the
user
experience
as
well
as
standardize
it
across
eosio
chains,
making
it
easier
for
people
to
make
the
jump.
The
new
developer
experience
is
going
to
be
vastly
improved.
People
like
me,
don't
have
to
answer
people's
questions
with.
A
You
can't
do
that
right
now,
if
you
want
to
do
that,
you
have
to
build
it
yourself.
That's
always
a
big
turn
off
to
developers
from
what
I've
seen
the
existing
web
developers
in
the
space
seen
through
our
own
experiences
are
also
going
to
have
an
improved
experience.
We've
been
onboarding
people
into
what
we've
been
calling
eosio
core,
which
is
a
javascript
replacement
for
eos
js.
That
falls
under
the
umbrella
of
this
thing,
and
everyone
we've
talked
to
so
far.
A
That's
actually
switched
has
really
appreciated
the
move
and
the
shift
in
how
this
framework
allows
them
to
build
their
applications.
It
gives
them
access
to
all
the
deep
fundamental
tools
they
need
to
do
the
things
that
they
want
to
do
it's
a
lot.
Less
hand-holdy
and
developers
can
experiment
on
our
side
and,
on
other
wallet
developers
side.
It's
going
to
improve
that
experience
as
well.
This
is
a
point
for
wallets
to
hook
in
and
abstract
their
technologies
away.
So
that
way
applications
can
just
integrate
them.
A
The
core
developer
experience
on
that
list
is
to
build
a
client
library
on
top
of
the
core
library,
but
the
core
developers
would
also
be
able
to
build
other
client
libraries
to
do
other
specific
things.
So
these
core
developers
that
are
looking
to
build
technologies
for
maybe
specific
use
cases
that
we
haven't
imagined
will
be
much
improved
because
the
core
library
at
the
foundation
of
all
of
this
is
robust
enough
to
handle
that
we
don't
have
that
today
period.
A
We
do
in
the
stuff
that
my
team
has
released,
but
overall,
like
most
developers,
are
unaware
of
that,
and
the
final
kind
of
improvement
that
we
anticipate
this
offering
is
that
it's
going
to
reduce
the
dependency
on
api
operators,
we're
going
to
be
able
to
optimize
call
patterns,
we're
going
to
be
able
to
make
recommendations
for
new
calls
that
could
drastically
improve
the
efficiency
of
apis
and
we're
going
to
be
able
to
help
mold.
What
apis
look
like
going
forward.
A
I
know
I
would
be
excited
to
use
it
as
a
client
developer.
We
think
that
we
can
get
it
done
in
under
a
year,
obviously,
that
we
could
scale
up
the
costs
and
bring
more
people
in
and
that
time
frame
could
be
reduced.
Honestly,
finding
developers
that
are
capable
of
this
level
of
work
is
hard
and
the
ones
that
are
capable
of
it
are
off
doing
other
things,
so
we
crunched
numbers
on
our
side.
A
We
do
have
a
spreadsheet
that
kind
of
backs
these
numbers
and
breaks
down
a
little
bit
more,
but
these
are
the
estimates
we
came
up
with
also
came
up
with
a
breakdown
of
what
is
actually
required,
what
we're
recommending,
which
is
that
middle
column,
and
then,
if
you
want
absolutely
everything
which,
in
this
chart,
the
everything
just
adds
developer
training
it.
Let's
do
videos,
let's
maybe
sponsor
some
hackathons.
A
Let's
do
coursework
and
blogs
and
everything
you
can
imagine
to
just
get
new
developers
suited
to
this
code
that
can
always
come
after
the
fact
as
well.
So
that's
why
we
didn't
actually
include
it
in
the
recommended.
So
in
general,
that's
proposal,
four
of
the
wallet
plus
paper.
It
is
honestly
the
one
that
I
am
most
excited
about,
and
I
think
I
probably
spent
the
most
time
in
there
are
some
other
good
proposals
in
there.
A
If
this
one
is
not
suitable,
but
I
do
think
that
this
proposal,
based
on
my
experience,
working
on
all
of
v
chains,
I
think
it
would
benefit
each
and
every
one
of
them.
It
plays
off
the
core
fundamentals
that
all
these
chains
share,
like
as
an
example.
There
accounts
we
all
have
accounts
on
all
of
these
chains
and
there's
some
abstraction
in
the
sdks
that
could
really
benefit
developers
if
we
leveraged
it
so
right.
A
There
there's
one
example
of
some
core
fundamental
piece
that
would
benefit
them
all,
but
the
flexibility
of
the
system
chains
like
fio
with
all
of
their
chain
specific
api
calls
that
are
very
bespoke
to
that
network.
The
flexibility
of
this
sdk
will
allow
them
or
us
or
whoever's,
building
this
to
build
that
stuff
into
the
client.
So
the
developer
experience
that
way
as
people
are
building
applications
on
that
chain.
They'll
have
access
to
chain
specific
logic.
Essentially,
so
I
think
this
is
probably
one
of
the
strongest
proposals
that
fits
across
all
chains.
A
I
think
we
can
release
this
stuff
piecemeal
and
it
could
all
be
developed
in
the
open
and
very
engaged
in
the
whole
process.
If
we
were
the
team
that
were
taking
this,
on,
which
we're
very
excited
to
be
able
to
offer
to
be
able
to
do
that,
we
would
start,
for
example,
with
getting
eosio
core
in
a
place
that
library
as
to
where
it
is
documented,
and
we
can
start
getting
like
more
low-level
programmers
using
it
in
a
matter
of
like
weeks.
There
are
people
on
this
call.
I
know
that
are
already
using
it.
A
It's
just
there's
no
documentation
and
you
need
to
dig
into
it
like
the
deliveries.
It's
not
going
to
be
that
after
nine
months,
here's
the
whole
thing
it's
going
to
be.
There
will
be
little
drops
along
the
way
and
potentially
we
would
look
for
applications
that
want
to
grow
with
this
framework
and
get
started
with
it
as
soon
as
possible,
within
maybe
one
or
two
months.
We
would
want
them
to
be
the
beta
testers
of
this
application.
A
Our
team
took
that
approach
with
anchor
like
we
had
some
early
adopters
of
anchor,
and
we
really
worked
closely
with
them
to
make
sure
that
the
flows
back
and
forth
were
suitable,
and
I
imagine
we
could
do
something
similar
with
this.
We
can
definitely
do
incremental
releases
along
the
way
and
work
with
the
community
in
terms
of
other
proposals
in
the
paper.
I'm
sure
there
are.
I
don't
have
one
specifically
in
mind
that
I
could
just
pull
out
of
my
hat
right
now,
but
there
may
be.
A
I
I
want
to
say
maybe
the
application
registry,
which
is
one
of
the
other
proposals,
but
I
don't
know
that
benefits
all
chains,
because
not
all
chains
run
applications
like
ux
and
fio.
You
can't
deploy
smart
contracts
onto
so
there's,
not
really
a
need
for
the
registry
there,
but
that
might
be
a
huge
need
for
the
public
networks
where
anybody
can
deploy
their
own
contracts
and
to
go
back
all
the
way
to
the
start.
A
When
I
did
talked
about
this,
this
is
for
the
web
version
of
these
sdks,
and
that
is
really
just
the
first
step
as
we
begin
making
progress
and
like
we're
defining
standards
and
protocols
along
the
way,
once
we
hit
a
certain
point,
we
might
be
able
to
fire
up.
Okay,
let's
start
the
app
development
sdks
in
parallel.
Now
that
we
have
the
standards
and
then
we
have
a
team.
A
That's
working
on
like
here
is
the
implementation
in
swift,
so
ios
applications
can
be
built
easier
and
here's
a
kotlin
sdk
for
android
applications,
and
maybe
we
have
one
for
unity
and
one
for
unreal
and
all
these
other
platforms
that
we
know
people
want
to
build.
Applications
on
this
can
start
as
the
initial
step
in
this
long
process
of
building
out
potentially
dozens
of
sdks
over
the
course
of
the
next.