►
From YouTube: Core Dev Call 30 - May 18, 2020
Description
Bi-weekly Core Dev call to discuss technical details of proposals, specification and implementation of Core protocol and features. Latest agenda, as well as notes and recordings of previous calls, can be found in https://github.com/status-im/pm/
https://status.im/
A
There's
one
thing:
I
can
I
can
mention
I
guess,
which
is
we've
changed
a
bunch
of
names
of
make
file
targets
recently,
so
the
development
process
has
slightly
changed.
It
combined
a
bunch
of
the
start
dev
once
and
now.
It's
essentially
just
three
targets
that
do
everything.
It's
its
run.
Closure
run,
run
metro
and
run
Android
or
iOS,
and
that's
all
you
need
for
development
and
that's
documented
in
the
starting
guide
in
their
root
of
the
repo.
That's
a
simple
change
for
ere
all
developers.
A
A
B
B
This
for
the
first
time,
so,
let's
see
how
that
goes.
I'm
just
gonna
follow
the
agenda
that
we
have,
and
obviously
this
is
I
guess
also
a
little
bit
of
an
open
discussion
to
the
extent
that
everyone
can.
You
know,
throw
in
ideas
and
leave
their
opinions
and
thoughts,
and
with
that
in
mind,
I
would
say
we
just
go
ahead
with
the
review
of
the
previous
actions.
B
B
B
B
It
that
there
could
be
I'm,
not
Charlie,
sure
I
read
all
of
the
the
transit
from
the
last
meeting,
but
they
seem
to
be
related
to
that.
Yes,
so
there's
one
I
think
under
is
another
around
some,
so
we
can
leave
that
one
out.
Is
there
anything
about
the
process
of
obtaining
new
stickers
that
have
to
just
guess
what.
B
If
there's
no
no
thoughts
for
anyone
that
that's
fun,
we
can
just
continue
to
the
next
one.
I
guess
is
the
X
reviews
for
or
the
X
as
Esther
mentioned,
we
have
a
bit
more
structure
with
that.
Now
that
Oscar
I
guess
came
up
with,
and
we
have
for
for
that.
We
have
the
repository
with
a
bunch
of
open
issues
and
open
pore,
quests,
so
I
guess
I,
guess
one
thing
that
make
make
sense
now
being
able
to
to
go
over
the
open
for
requests.
B
First,
cuz
there's
some
of
them
are
pending
for
for
quite
a
while.
So
I
know
that
there
was
some
some
discussions
and
it's
some
of
these
poor
requests
that
you
know
still
need
some
some
action
to
get
those
merge,
or
maybe
there's
still
some
open
questions.
So
maybe
we
can.
We
can
start
with
those
and
and
talk
about,
what's
what's
left
to
do
to
get
these
these
specs
I
guess
analyzed.
B
B
B
C
D
D
D
D
B
C
D
Anyone
else
who
is
also
familiar
with
the
problem,
the
main
feel
free
to
review.
It
say,
for
example,
I
know
like
a
lot
of
people
are
getting
more
like
like
Pascal
and
all
the
others
like,
if
you
guys
want
to
review,
feel
free
to
go
ahead.
If
you
don't
have
permissions,
just
ping
me
and
I
love,
you.
E
E
You
know
it
basically
indexes
ipfs
data
so
that
you
can
quickly
look
it
up
rather
than
having
to
traverse
the
the
network
to
find
the
content
and
loaded
which
could
take.
Sometimes
it
could
take
some
time
for
for
for
that
data
to
look
here,
so
indexing
can
speed
that
up,
but
I'm
just
forming.
If
that
is
something
it's
outside
the
scope
of
this
year,
I.
C
D
B
B
B
B
B
B
B
B
B
E
One
big
thing:
actually
this
is
the
first
time
I'm
looking
at
this
PR,
but
another
scope.
Question
is
and
there's
been
discussions
in
the
past
of
allowing
gaps
to
access
some
some
of
the
chat
API,
for
example,
allowing
the
DAP
to
try
to
send
a
message
in
a
chat
room
or
you
know
other
chat
functionality.
Is
that
something
that's
planning
to
be
addressed
here,
or
is
that
also
something
out
of
scope?
And
it's
a
separate
something
separate.
E
E
E
Well,
it's
not
being
used
cuz,
it
doesn't
exist
right
now,
but
I
know
there's
been
talk
of
allowing
there's
there's
been
demand
for
it,
for
example,
allowing
adapts
that
would
like
to
be
able
to,
on
behalf
of
a
user,
send
the
message
into
a
chatroom
or
to
another
user
right
now
that
functionality
doesn't
exist.
So
is
this
just
a
matter
of
creating
expected
document
existing
functionality,
or
is
this
you
know
sort
of
the
ideal
spec
that
we'd
like
to
have
all
encompassing.
F
D
E
D
Yeah
exactly
so
one
way
of
moving
that
forward
will
be
to
have
a
corresponding
like
protein
issue,
with
sort
of
problem,
description
and
so
on,
and
then
take
it
up
and
then
I
guess
depends
on
who
would
develop
that
and
then
it
would
be
a
new
PR
and
we
can
discuss
it
from
there
in
terms
of
where
we'll
be
implemented
first
and
so.
On.
D
D
D
D
D
B
B
B
G
H
Yeah
so
I'm
currently
doing
the
auto
completion
and
I
will
finish
the
spec
afterward,
and
that
would
be
the
the
first
version
and
then
we
need
to
add.
One
status
quo
is
serving
notifications.
Probably
we
can
complete
mentions
with
with
that.
So
right
now,
I
think
I
will
leave
it
open
until
I'm
done
with
auto
completion
and
I
will
change.
The
part
about
things
left
to
do
so.
I
would
leave
it
as
a
draft
for
now.
D
D
D
H
D
H
C
F
H
Yeah
I
need
to
review
it,
but
because
basically
I
was
giving
too
much
information
about
the
specifics
of
what
status
is
doing
in
the
android
client,
so
I
will
clean
up
and
same.
It
will
be
a
draft
because
we
need
to
discuss
handling
of
notifications
by
status
Co.
So
right
now
there
is
a
the
the
android
client
is
reading
the
signals
from
status
quo,
and
we
want
to
change
that
so
that
studies
go
send
specific
message
signals
for
our
notifications.
H
It
will
be
simpler
for
clients
to
implement
notifications
and
it
will
be
more
stable
because,
right
now,
it's
reading
the
same
messages
that
studies
react
is
willing
to
show
messages
in
the
app
and
interpretating
them
to
build
notifications.
So
the
idea
is
to
have
specific
notification
signals
from
studies
go,
and
that
would
mean
that
we
can
have
user
settings
for
what
should
be
notified
and
and
so
on,
and
the
clients
that
implements
notification
would
then
only
have
to
listen
to
these
notification
signals
and
know
that
it
has
to
be
displayed
in
any
case.
B
Okay,
so
there
are
no
more
spots
on
that
or
any
additions,
then
we
can
can
move
on
to
the
next
point
in
our
agenda,
which
is
well,
these
are
just
the
open
PRS
there,
there's
still
a
bunch
of
issues
and
the
specs
for
posit
Ori
at
this
point.
Eighteen
and
a
lot
of
them
are,
or
plenty
of
them
are
quite
old
as
well.
So
it
seems
like
there's
specifically
to
need
more
discussion
at
this
point.
It's
a
change
from
a
tie,
yeah
PS
to
a
supported
and
the
removal
of
personal
pronounce
from
specs.
B
D
Yeah,
like
it's,
it's
a
bit
of
an
interesting
one,
because
the
origin
of
that
speculate
file.
Instead,
we
knew
that
we
had
a
bunch
of
yappy,
SNP,
apiece
and
so
on
that
were
supported
and
we
used,
and
it
would
be
useful
to
have
like
a
single
reference
breath
because
to
some
extent
they
should
all
be
in
line
in
other,
very
specs.
So
it's
unclear
to
me
to
what
extent
it's
like
a
double
thing
and
and
the
use
of
that
for
the
client
implementations
on,
but
I
can't
find
what
doesn't
renaming
it.
I
know.
G
Yeah
I
would
also
be
very
curious
as
to
know
what
other
members
of
the
team
think
about
doing
that
I.
Think
in
my
mind,
the
document
actually
serves
very
well
as
a
references
page.
She
would
only
find
an
academic
document
so
to
me,
if
it's
fact
that
is
referenced
twice,
the
fact
that
it's
in
a
compilation
to
nice
is
useful,
but
I
definitely
am
at
the
moment
that
it's
marked
as
discussion
so
we'll
open
to
anybody's
opinion.
At
this
stage,
I.
D
C
Yeah
I
have
to
get
back
to
your
that,
but
but
in
general,
respects
for
sure
the
help
like
the
specs
that
are
right
now
in
inspect
that
stairs
up.
I
am,
I
think,
those
were
are
very
well
done,
another
written
in
generally,
if
their
specs
is
better
than
reverse
engineering
codes
and
things
like
that
so
odd,
I
think
for
sure
good.
It's
helpful
I.
C
B
Okay,
so
next
up,
we
have
one
about
the
removal
of
personal
pronouns
from
Beck's
I
think
as
far
as
I
can
see
here,
I'm
sorry,
which
is
living
the
issue
to
the
115,
the
last
commentary
source
by
Oscar,
and
he
said
that
those
changes
could
be
made
as
per
request.
Some
sure
there's
anything
that
needs
to
be
discussed
here,
other
than
yeah
feel
free
to
propose
changes.
I,
don't
even
know.
G
Well,
I
think
you're
right
that
isn't
it's
an
issue
that
also
relates
to
back,
but
the
with
the
the
examples
in
this
particular
issue
are
directly
from
the
the
status
specs,
but
I
think
I
think
you
are
right.
That's
in
fact
is
the
same
issue.
Is
this
present,
so
I
don't
know
if
it's
a
matter
of
just
replicating
the
issue
also
in
back
I'd,
have
to
double-check,
though,
just
to
make
sure
that
there
is
a
heavy
usage
of
personal
pronouns
in
the
specs
there
as.
C
C
G
Ii
hear
so
in
the
actual
document:
I
referenced,
a
it's
just.
It's
actually
for
university
students
writing
academic
documents,
it's
just
in
the
references
section
of
on
the
issue,
but
it
gives
us
a
quite
a
neat,
consistent
sort
of
method
of
phrasing,
sort
of
technical
documents
or
academic
documents.
G
So
it
seems
like
so
on
on
the
proposal
I
had
it,
I
had
the
number
of
items,
one
of
which
was
decided
with
the
specifications
about
a
consistent
tone
and
mode
of
language.
So
at
the
moment
the
consensus
from
Dean
and
Oscar
is
yes,
it
should
and
the
tone,
ash
and
mode
of
language
should
probably
be
formal
and
then
the
which
also
actually
answers
at
the
moment.
Unless
there's
any
dissenting
opinion
item
number
two,
which
is
the
consistent
on,
is
required,
and
what
should
that
tone
be?
G
D
G
B
Okay,
then
we
can
go
on
to
the
next
one,
which
is
suits
with
a
bigger
topic,
sending
or
changes
that
need
to
be
made
to
send
images.
There
was
no
no,
no
particularly
issue
linked
in
the
original
agenda,
but
I
just
brought
through
the
list
issues
found
one
which
has
a
massive
history
of
comments.
Let
me
just
link
it
here
is
issue,
so
you
see
mine
what's
this,
that
is
with
that
one
obviously,
I
didn't
read
through
all
comments.
Kristy
is
from
December
2019,
but
anybody
want
to
chime
in
on
that
one.
F
I
can
do
it
yeah,
so
so,
basically,
we
kind
of
agreed
on
the
protocol
specs
changes
that
needs
to
be
made
to
send
images
and
they're
fairly
simple
I
mean
you
know,
I
could
just
send
it
a
mime
type
which
is
type
of
image,
and
you
send
the
payload
of
the
image
that
that's
kind
of
the
easy
part
we're
going
to
send
messages
through
whisper.
What
was
right
and
because
they
inspire
so
as
we
implemented
this.
F
What
we
discovered
is
that
the
current
proof
of
work
that
we
are
using
for
our
notes
is
set
way
too
high
for
us
to
send
images
of
even
reasonable
sides.
So,
even
from
my
desktop
machine,
sending
a
200
kilobytes
image
was
of
his
book
like
he
would
take
25
seconds,
let
alone.
Obviously,
a
mobile
device
he's
never
gonna
work,
and
so
the
only
way
for
us
to
make
it
work
is
to
dramatically
reduce
our
web
note
so
that
there
has
some.
F
You
know
the
main
drawback
of
death
is
that
you
know
it's
easier
for
people
to.
Basically,
you
know
if
we
just
teach
really
make
it
easier
for
people
to
send
messages,
and
so
what
we've
done?
We've
got
a
bit
of
investigation
of
what
the
impact
is,
and
so
what
turns
understandings
more
messages
like
many
it's
more
charged
messages
and
when
it
says
more
I
mean
I
mean
sighs.
So
you
know
500
characters,
which
is
already
probably
a
chunky
message.
It's
a
small
message
because
that's
a
bug,
advice
right,
and
so
it's
the
same.
F
It
doesn't
make
a
huge
difference.
So
basically
driving
time
is
actually
processing
the
message
rather
than
calculated
work.
So
there's
no
huge
difference,
selling
bigger
messages,
maybe
big
mixa,
mixa,
mixa,
mixa
difference
so,
like
obviously
like
now,
it's
possible
to
send
200,
kilobytes
messages
and
so
on
and
so
forth,
and
so
the
concern
is
Pam.
F
So
given
what's
happening,
there's
no
difference
for
a
user
to
storm
a
charge
with
many
mess
that
stance,
which
is
probably
like
what
we
put
his
monsters,
distract
destructive
to
most
users,
but
if
they
want
to
consume
more
of
our
bandwidth,
you
know
like
we
lower
the
field.
Did
it
work
is,
is
easier
to
you
know
there
are
emulate
some
already.
You
know
check
there
are
in
based
on
the
rate,
limiting
it
and
believe
that
they
are
enabled
and
check
the
conflict.
F
You
know,
Chaco
Canyon,
open
I
should
have
a
check
that
for
me
every
month,
but
I
think
we
already
leave
it
us
and
believe
it
by
the
message.
We
don't
limit
by
size
of
the
message,
but
it
should
be
okay,
and
so
it's
whether
we
want
to
go
ahead
up
here.
Better
specs
needs
to
be
made
with
the
lower
lower,
prefer.
F
F
Saturday
will
spare
me
the
question
is
differentiate
between
sender
of
chat
messages
and
sending
a
lot
of
messages
in
terms
of
size
so
consuming
over
bandwidth.
Those
are
two
distinct,
distinct
things
in
your
like
setting
more
chat
message
is
not
really
impacted
by
these
well
sending
you
know
consuming
more
of
our
users.
Bandwidth
is.
D
Two
questions
the
first
race
on
rate-limiting,
if
I
recall
correctly
quickly,
the
rate-limiting
allows
for
rate
limiting
on
multiple
dimensions.
So
is
it
the
case
that
the
current
policy
in
place
is
just
on
the
number
of
misses,
but
it
could
be
the
same
stores
to
take
into
account
the
size,
semesters,
I
believe.
D
F
D
G
The
only
remaining
question
I've
got
is
that
this
is
a
change
in
implementation,
for
the
proof
of
work
required
for
sending
messages.
So
I
know
from
the
code
itself.
It's
anything
that's
over,
but
five
thousand
bytes.
Sorry,
fifty
thousand
bytes.
It's
this
something
that
should
be
mirrored
in
the
specifications
as
well.
I.
F
Think
so
yeah,
you
know
we
need
to
you
I
think
we
should
be
updated,
yeah,
so
something
about
the
client,
because
we
can't
just
lower
lower
proof
of
work
for
every
single
message.
The
reason
being
is
that
other
plans
will
just
describe
those
messages.
So
what
we
do
is
if
a
message
is
higher
in
it's,
the
size
of
a
message
is
higher
than
X
amount
of
bias.
We
use
a
value
that
we
know
that,
like
normal
messages
are
no
higher
than
generally,
it
will
use
the
no
work
so
newer
clients
can
receive
the
message.
F
G
B
B
B
E
E
E
E
E
C
C
C
C
C
C
I
I
I
I
may
not
be
completely
up
to
date,
but
I
did
participate
in
a
short
discussion
a
few
weeks
ago
about
this
and
one
of
the
things
that
concerned
me
a
little
bit
was,
you
know.
Not
only
would
notifications
be
opt-in
on
iOS
but
effectively.
The
other
party,
if
you
were
chatting
with
someone
say
on
Android,
would
also-
or
maybe
even
if
it's
another
iOS
user
would
also
have
to
basically
agree
to
that
right.
So
it
would
be
on
a
lady
was
gonna,
be
on
a
case-by-case
basis.
I
I
think
and
the
reason
that
concerned
me
is,
it
seemed
it
would
allow
it
could
be
a
potential
vector
for
profiling.
You
know
you
could
potentially
differentiate
Android
from
iOS
users
and
if
someone
was
trying
to
figure
out
who
someone
was
that's
a
it's
a
natural
starting
point
so
I
again,
maybe
that's
not
relevant
anymore
or
maybe
I
misunderstood,
but.
C
H
That's
the
day,
it's
it's
relevant,
but
it's
not
even
the
the
only
issue.
The
other
issue
is
that
the
UX
would
be
pretty
bad,
because
users
would
wonder
why
they
don't
get
notification
for
one
shot
and
then
for
the
others.
So
yeah.
You
would
only
get
your
notification
in
the
chat
where
the
other
user
agree
to
send
notifications
and
yeah.
You
both
agreed
and
exchanged,
means
to
to
notify
each
other,
but
that's
the
the
case
where
devices
would
send
themselves.
But
we,
if
we
delegate
that
to
a
centralized
server,
then
it
reduces
a
bit
decision.
H
F
F
We
use
it
with
directly
changes,
exchanging
notification
tokens
so
basically
through
contact
request,
so
user
and
I
would
send
to
Esther
my
token
and
she
would
use
it
when
she,
which
is
there
no
mention
on
because
the
token
is
meant
to
be
a
secret,
and
so
you
know,
essentially,
we
model
using
words
date:
okay,
I
trust
that
user
as
send
it
with
token
and
so
on
and
so
forth,
but
you're
saying
want
to
reuse.
Do
you
always
have
the
same
talking
to
other
users?
So
you.
F
D
Gotcha
yeah
right
Soviet
and
the
secondary
question
is
I
know
this
was
investigated
like
when
I
was
looking
into
this
a
few
years
ago.
It
was
not
possible
I,
know
and
I
was
looking
into
it
last
year
in
terms
of
waking
up
from
background
from
IRS.
I
would
do
something
like
that,
like
that's
essentially
impossible,
due
to
sort
of
how
Apple
devices
work.
Is
that
still
definitely
the
case
or
is
there
some
avenue
for
hope
there?
It.
H
Depends
on
how
much
you're
hoping
for,
but
there
is
a
chance
that
you
can
wake
me
up
on
background
notifications,
but
they
need
to
be
spaced
in
time,
so
I
think
it's
like
a
couple
or
three
times
per
hour
max.
So
that
would
be
one
area
to
explore.
For
instance,
in
case
we
want
the
notification
servers
to
work
without
any
knowledge
of
your
keys.
H
So
when
one
way
it
could
work
is
that
when
you
use
work
ooh,
it
would
check
the
topics
and
if
there
is
a
message
in
one
to
pick
that
you're
asking
for
it
would
send
a
background
notification.
So
it's
not
necessarily
that
you
have
a
message
there,
but
that
there
is
messages
to
read
for
that
topic.
So
if
there
is
not
too
much
to
pick
collision,
then
there
there
is
chances
that
when
you
wake
up
be
up,
there
will
be
stuff
to
read
or
so
yeah.
There
is
things
we
could
do
in
in
that
area.
H
This
one
is
even
less
reliable,
so
that's
what
Android
tested
last
year
and
the
heuristics
are
completely
unknown,
but
it
seems
like
it's
actually
very
rare
that
your
app
is
being
run,
especially
if
it's
doing
a
lot
of
stuff
like
like
we
do
with
some
network
ioin
and
so
on.
It's
it's
more
likely
to
work
for
apps
that
basically
just
do
a
quick,
HTTP
request
and
shut
down.
If
there
is
nothing
to
do.