►
From YouTube: Status Devs Meeting - Monday November 4, 2019
Description
Topics Discussed:
- Allow for smooth sending and receiving of SNT while maintaining privacy
Notes: https://notes.status.im/cW_ng1skT2SkxpVRQ3nkxA?both
B
B
B
The
trouble
we
until
later
after
v1,
so
we
came
up
with
this
request
flow
request
and
sent
flow.
So
there
is
a
center
and
a
request
as
before,
and
but
the
difference
now
is
that
it
includes
potentially
a
back
and
forth
to
to
get
the
other
users
address.
So
I
made
additional
propositions
regarding
the
format
of
these
commands.
B
C
B
I
switched
to
Wi-Fi,
is
it
better
or
it's
still
plenty,
it's
actually
better?
Okay,
so
maybe
I
give
it
another
try,
but
interrupt
me
sooner
if
it's
bad
and
we
just
give
up
so
I
try
to
go
to
the
specific
part
that
is
not
completely
written,
so
Ricardo
suggested
to
use
the
EIP
681,
which
is
a
form
of
you,
arrive
for
payments,
which
is
already
mostly
implemented
in
status,
react.
B
So
the
way
it
goes
is
that
it's
it's
similar
to
what
we
had
for
QR
codes
for
for
making
requests
right,
and
so
the
idea
would
be
that
instead
of
the
current
weird
commands
format,
we
have
in
messages.
We
send
regular
messages,
and
it's
just
that,
instead
of
containing
text,
they
contain
this
kind
of
URI
so
that
you
can
send
them
from
it's.
B
A
B
B
So
the
way
the
flow
would
go
is
that
Bob
would
send
a
request
comment.
So
he
taps
on
request,
comment
so
right
now
it's
/
San
/
request,
and
then
he
selects.
So
now
we
need
to
ask
for
his
wallet
as
well.
He
also
asked
for
we
says
which
asset
which
amounts,
and
then
it
sends
this
e
is
six
hundred
eighty
one.
You
arrived
for
payment
requests
in
a
text
message
from
Alice
point
of
view:
status
shows
that
a
simple
URI
message
as
a
request
message
and
she
taps
on
it.
B
It's
something
like
pay
or
matches
doing
the
design,
so
she
taps
on
it
and
it
opens
it
invites
her
to
sign
the
transaction
and
then
once
she
signed,
she
sends
the
transaction
hash
to
Bob.
So
my
proposal
for
Ricardo
propose
that
we
also
use
a
IEP.
So
a
p680
one
is
a
subset
of
years.
The
IP
831,
which
is
these
aetherium,
you
arise,
and
for
payment
request.
B
You
you
put
the
page
effect
prefix,
and
here
we
would
put
the
TX
prefix
and
then
ash
of
the
transaction,
and
that
would
be
like
a
URI
for
Jana,
theorem,
transaction
or
I
mean
that's
something
we
can.
We
can
discuss
further.
Actually,
we
could
also
add
a
few
details
like
the
chain,
but
basically
the
idea
would
be
that,
instead
of
having
these
complex
messages
with
a
specific
format,
we
use
an
ear,
an
ear,
vip-only
theorem
standard
for
these
comments.
B
When
then,
the
tricky
part
is
when
Bob
uses
the
sentiment,
because
he
doesn't
know
a
lease
wallet,
so
the
idea
would
be
that
Bob
sends
transaction.
We
send
a
send
request
so
still
using
years
years,
VIP
831.
We
would
use
the
request
prefix
and
model
it's
the
same
way
as
the
pay
URI,
so
that
at
least
when
I
just
received
that
it's
invite
it's
in
an
invitation
to
the
action
would
be
to
choose
a
wallet.
So
she
she
tap
on
the
message.
B
A
B
So
I
would
like
back
on
the
idea
of
using
VIP,
681
and
ie
830
31,
so
if
people
of
suggestion
of
what
could
be
missing
so
basically
the
idea
of
using
the
GIPS
instead
of
using
specific
messages,
so
that
would
be
regular
messages
that
you
can
send
even
from
this
corridor
for
from
a
bridge
or
whatever.
There
is
no,
it's
just
a
string
of
characters,
basically
so
yeah
there
is
that
and
then
the
other
is
more
general
feedback
about
the
flow
itself
and
someone
else
like
a
strong
opinion
on
whether
it's.
A
B
Well
you
you
for,
for
this
first
version,
I
would
say
yes
in
most
cases
like
you
can,
for
instance,
we,
if
you,
if
you're
doing
it
multiple
times
in
a
short
amount
of
time,
request
and
change,
simply
change
the.
So
you
tap
pay
and
you
just
change
the
amount
or
or
the
assets
that
could
be
a
trick
or
you
orange
the
users
as
ENS
name.
This
flow
doesn't
apply
entirely
because
if
he
has
a
ENS
name,
it
has
a
public
address.
So
you
can
send
to
this
address
directly
without
questioning
anything.
B
So
that's
the
two
options
and
of
course,
after
we
won,
the
intention
is
to
figure
out
the
proper
way
to
store
user
addresses.
So,
but
we
don't
want
to
include
it
in
this
cup
of
this
air
FC,
because
it's
much
more
work
in
terms
of
contact
management
and
the
synchronization
of
the
contact
data
between
devices
against.
B
We're
not
going
to
add
to
advertise
a
default
address,
we're
just
going
to
well.
Yes,
we
might
do
that
for
assessing
the
contact
requests
or
we
might
simply
after
the
first
time
we
request
we
might
store
the
yet
known
addresses
of
the
contact
first,
every
time
I
make
a
request
for
for
sending
and
you
answer
with
the
district
different
address.
You
might
store
these
addresses,
but
there
is
a
bunch
of
UX
problems
that
we
have
to
solve.
B
First,
so
first,
when
do
you
invalidate
an
address,
because
maybe
the
other
person
doesn't
want
to
use
it
anymore
and
like
all
that
kind
of
Christian
questions
we
want
to
avoid
them
from
now.
So
now
the
idea
is
that
either
you
have
ENS
name
so
because
the
thing
is
with
the
NS
name,
you
have
a
public
address.
You
cannot
avoid
it.
You
pay
with
you
own,
the
name
with
the
particular
address,
so
so
that
that's
an
address
that
you
you
need
to.
B
Yes,
but
so
all
the
parameters
are
optional
in
the
IP
681,
but
you
can
indeed
decide
to
already
tell
the
user
listener.
I
want
to
send
you
100's
entry,
so
the
message
would
like
it
would
show
and
Bob's
device
as
a
Bob
Alice
is
trying
to
send
you
20
s
and
G
choose
an
address
and
you
choose
your
address,
but
it
can
also
be
incomplete.
Like
Alice
wants
to
send
you
forms.
What
is
your
address,
so
we
could
I
am
so
for
that
I
guess
I
will
leave
it
to
you
or
techniques.
B
A
B
I'm
sure
just
a
precision,
the
thing
is
that
you
don't
provide
the
amount
and
do
I
set
that
you
want
to
send.
Then,
when
the
user
sends
you
a
request
back,
this
is
not
prefilled.
So,
instead
of
having
a
transaction
flow,
where
you
just
have
to
press
the
pay
button,
and
then
it
opens
the
transaction
sign
in
flow,
you
still
have
to
fill
in
the
amount
and
the
message.
So
that's
not
a
big
deal.
It's
already
feasible
in
this
drawer
I
as
I
know.
A
B
A
B
No,
the
first
iteration
they
don't
need
to
do
it
for
the
actual
signing.
But
but
the
thing
is
that
yeah,
it's
a
bit
weird
because
Roman
rightfully
no
distance,
we
don't
save
the
address
right
now
because
we
don't
want
to
deal
with
that.
It's
it's
a
bit
weird
to
ask
without
saying
without
saying
what
you're
going
to
say
because
you're,
it's
only
for
once.
C
But
as
soon
as
that,
you
didn't
like
the
request
on
urgent
a
transaction
I
mean
given
that,
if
it's
already
a
bit
more
of
a
heavy
flow,
that
said
I
think
it
does
make
sense
to
allow
for
the
optional
sent
with
said
request
without
amounts.
Even
though
that's
kind
of
it's
a
bit
weird
to
ask
someone
hey
address.
B
One
thing
is
that
one
thing
is
that
in
the
flow
I
proposed,
I
didn't
think
that's
so
potentially
I.
My
intention
was
to
use
the
regular
send
command.
Except
now
you
choose
also
the
wallet
you're
you
are
using
to
send,
and
for
that
reason
this
comment
doesn't
allow
you
to
send
until
you've
provided
a
valid
amount
and
a
valid
asset,
but
but
it
can
be
changed,
of
course,
but
the
thing
is
that
my
idea
was
that,
though
the
flow
is
a
tiny
bit
more
complex
from
the
implantation
implementation
point
of
view.
B
It's
for
the
user,
it's
just
taking
him
through
the
steps,
because
you
want
to
send
so
you
start
sending
you.
You
feel
your
your
your
amount,
your
asset
and
just
you're.
Just
you're
just
told:
ok,
you
don't
have.
We
don't
know
bub
address
because
it
doesn't
have
a
ENS
name,
for
instance,
so
we're
gonna
ask
him
first
to
send
you
an
address
and
then
you
can
make
the
actual
sending.
B
C
Requests
and
that's
a
solution
which
is
I
would
stick
to
that.
I
do
see
a
use
case
where
I'm
sending
requests
without
entering
amounts
in
the
case
of
SMT
reactions
later
on,
where
you
sent
the
request
just
because
it
because
you
want
to
enable
that
feature
not
because
you
already
have
something
that
you
want,
especially.
B
Since
right
now,
you're
not
enabling
the
the
send
feature,
because
you
you
you're,
not
saving
the
address
so
well,
it
would
be
that
you,
basically
you
can
send.
You-
can
put
some
random
amounts,
and
then
you
go
back
to
that
message
and
you
reuse
the
message
to
that
Bob
sweet
flies,
which
is
which
will
be
a
request
and
you
change
the
amount
every
time
that
should
be
the
hack
between
v1
point
one.
If
you
want
to
somehow
persist
Bob's
address,
it
will
be
in
the
request
message
that
he
sends
back
to
you.
C
B
Yeah
for
the
use
case
about
the
marketing
stuff:
it's
this
flow
is
is
quite
efficient,
so
it's
either
the
users.
Can
we
request
marketing
or
marketing
wills
because
it
it's
almost
as
good
as
if
you
could
send
directly,
because
from
the
user
perspective
they
will
see
if
hey
you're,
like
marketing,
wants
to
send
you
100
SMG,
send
your
wallet.
Okay,
yeah
sounds
like
spam,
but
that's
if
it's
if
it
looks
legit
enough
in
in
chatted.
D
B
Yeah-
and
this
is
really
like
putting
our
first
stone
on
this
future
and
then
there
is
tons
of
improvement
we
can
think
of
so
Francis.
You
can
imagine
that
for
when
you
receive
these
requests
for
giving
your
wallet,
if
you
don't
trust
the
person,
you
click
person
to
be
able
to
creator
wallet
on
the
spot
and
give
that
wallet
and
only
if
you
receive
forms,
you
transfer
them
to
your
regular
wallet.
And
that
way
you
don't
give
your
wallet
away
to
random
people
until
you
you're
sure
they
are
actually
sending
from.
B
So
yeah,
regarding
shoot
back
now
and
mostly
in
about
everyone's
opinion
on
the
idea
of
using
VZ
IPs
and
making
our
own
prefixes
for
the
transactions,
and
so
transactions
could
actually
be
an
EIP.
Eventually,
though
I
and
and
then
there
is
the
the
request
itself,
I,
don't
as
I
explained
in
the
arrestee
I.
Don't
think
it's
that
much
of
a
use
case,
except
for
this
scenario,
but.
D
Now
it's
a
it's
a
real
use
case.
It's
important
this
because
now
we
don't
know
the
people
addresses
and
about
the
transaction.
The
hash
I
think
that
this
is
a
way.
For
example,
do
we
have
another
issue
of
uncurling
URLs?
For
example,
if
you
pay
zakat
hub
URL,
it
will
show
a
preview,
the
same
thing
we
can
do
here,
but
then
we
can
select
if
it's
a
terse
current,
that
we
will
prove
it
or
if
it's
other
block,
Explorer
yeah.
B
But
what
I'm
saying
is
that
like,
if
we
want
it
to
be
a
general
use
case,
what
I
mean
by
a
use
case
is
outside
of
status?
It's
it's
like.
Could
you
what?
What
would
you
do
if
you
scan
a
QR
code
this
with
this
request,
which
translates
to
this
request
you're
right?
What
would
it
mean
for
you
it?
It
would
be
like
a
pay
payment
request,
except
that
it's
it's
a
it's
like
an
intention
to
pay
you
so.
D
D
Yeah
yeah,
you
you
you
break
in
and
then
I
will
smoke
it,
but
I
told
that
that
you
need
to
put
the
contact
the
contact
ID
of
the
payment
request.
So
the
when
you
scan
this
QR
code,
for
example
it's
in
a
mouth.
If
you
scan
disk
error
code,
you're
going
to
get
us
some
money
and
then
it's
a
dis,
dis
payment
request.
So
it
will
send
the
message:
it
show
you
an
improperly
include
payment,
the
the
contact
of
the
payment,
requester
and
also
the
payments
identifier
for
this
clear
coat.
A
A
D
I
said
the
payment
request
you,
whoever
is
creating
this
payment
request-
probably
needs
to
give
the
contact
ID
inside
of
the
payment
request,
be
contacted
back
if
it's
inside
I
start
with
a
message,
of
course,
is
the
message
sender.
But
if
it's
a
QR
code
printed
in
the
in
a
burner
or
something
else,
then.
A
D
B
Can
you
hear
me
yeah,
so
it's
good
I
think
we
I'm
not
asking
for
the
feedbacks
right
now.
I
think
you
can
can
just
join
the
discussion
like
read,
we
read
the
EIP,
the
RFC
and
the
proposition,
and
and
and
talk
there
because
I
think
it's
too
hard
to
give
it
back
on
the
fly
like
this
and
it's
an
important
matter.
B
So
we're
talking
mostly
about
replacing
command
messages,
which
are
a
specific
type
of
message
with
with
a
specific
content
in
in
transit
by
is
something
much
more
simple,
just
the
URI
based
off
some
aetherium
standards.
So
that's
that's
the
the
main
proposal
here
that
I'm
making
on
top
of
the
heiress's
or
invite
people
to
want
to
to
talk
about
it.
To
comment
on
the
issue
in
the
status
crawl,
repo,
great.