►
From YouTube: Core Devs Meeting #18 - Monday June 3, 2019
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
C
A
C
C
D
F
C
G
G
G
C
E
That
should
be
close
to
being
done.
We're
waiting
on
right
now
me
and
Jakob
are
trying
to
figure
out
how
to
set
the
infrastructure
for
approving
that
every
time
someone
does
a
submission,
you
check
it
to
make
sure
it's
legit
everything,
okay,
well,
we'll
approve
it
and
then
from
there
it'll
go
off
and
work
as
intended,
and
then
once
we
have
that
set
up.
We'll
will
then
figure
out
whether
or
not
we
want
to
do
a
full
scope.
Audit
on
that
or
just
do
an
internal
audit
on
it.
D
Right
so
for
the
Talent
Network,
the
sidechain,
we're
still
waiting
on
the
P
away
kite.
So
there's
looking
at
the
buckle,
we're
having
triger
purse
arcane.
We
also
did
some
experiments
with
with
a
tender
meant
it
like
a
basis
I
chain,
and
this
is
in
terms
of
the
scalability
and
the
stock
we've
been
working.
The
most
is
on
the
on
on
the
zero
fees
aspect
of
it,
and
for
that
we've
been
using
our
own
gas
filler.
D
It
was
built
by
ricardo
and
also
we've
been
experimenting,
a
lot
with
the
the
one
from
tableau
key,
which
is
most
likely.
The
one
will
go
it's
because
I
was
the
sort
of
network
belt
around
it
and
from
the
community
and
for
the
liquid
funding.
We,
we
both
a
new
client,
basically
a
command
line
that
was
the
desire
to
workflows
and
we're
waiting
on
feedback
on
that
for
the
for
the
next
steps
to
take
on
that.
E
E
That's
dishes:
first
round
of
blog
posts
movie
aimed
at
just
trying
to
introduce
people
to
the
concepts
of
modeling
the
different
use
cases
of
SNC
utilities
and
walking
him
through
do
that
and
that
having
some
kind
of
discussion
around
what
what
the
models
are
where
they
come
from,
and
once
we
go
once
we
finish
those
across
the
essence,
he
use
cases
will
kind
of
go
into
combining
them
looking
forward,
they're
kind
of
fun,
stuff
and
modeling
across
the
ecosystem.
But
that's
gonna
be
a
couple
weeks
from
now.
So.
E
Then
we
have
to
it's
kind
of
like
a
obscure
workflow,
of
finding
ways
to
embed
the
observable
notebooks
that
Barry
has
created
into
into
our
dot
status.
That
I
am
which
is
run
by
ghosts.
So
it's
a
little
annoying,
but
at
the
end
of
the
day,
what
it's
all
done,
it's
it's
actually
quite
neat
I,
can
share
the
link
if
you'd
like
to
read
over
it.
A
Great,
so
the
next
thing
is
improvements
and
I,
see
that
Ann
is
not
here,
so
I
can
do
the
update.
So
within
the
last
two
weeks.
Yet,
first
of
all,
we
released
a
new
version,
0
13
0,
and
we
you
find
that
you
can
like
shake
the
phone
to
send
an
error
message,
ship
or
if
you
have
an
exception,
for
instance,
on
JavaScript
exception.
Then
we
also
the
dialog.
It
used
to
be
just
a
dialect
and
then
you
press,
ok
in
closed
app
and
right
now.
A
You
can
also
send
an
error
report
there
and
we
are
working
a
lot
on
making
reproducible
builds
on
Android,
which
is
not
super
easy,
taking
into
account
amount
of
like
dependencies.
We
have
specially
the
JavaScript
dependencies
and
for
some
reason
they
sometimes
want
writable
node
modules,
which
is
which
is
not
perfect
for
that
and
but
yeah
we
had
troubles
here
and
there.
So
we
are,
but
it's
progressing.
So
it's
very
good
chance
that
it
will
be
done
relatively
soon
and
then
one
more
thing
is:
we
were
working
on
the
performance
improvements
all
over
the
place.
A
So
one
thing
is
to
improve
the
cold
start
of
the
application,
like
split
it
into
multiple
modules
and
extract
things
that
we
don't
want
to
start
up
from
that
from
loading
on
startup
and
stuff
like
that,
and
the
second
thing
is
that
we
are
slowly
moving
their
protocol
and
some
wallet
staff
also
status
go
side,
and
we
have
a
topic
about
this
later
on,
so
I
won't
go
into
details,
okay,
discuss
it
there
and
yeah.
So
that's,
oh
yeah!
Also.
A
We
are
working
on
this
that
we've
last
time
we
discussed
this
topic
negotiation
working
on
implementing
that
there
is
already
a
PR
new
view,
so
by
Andreea.
So
we
hope
we
also
will
fix
some
issues
with
the
traffic
consumption
with
growth,
especially
with
your
private,
chats
and
yeah.
That's
all
for
improvements
and
now
the
protocol.
E
A
H
H
They've
had
some
issues
with
integrating
into
the
console
clients
I
believe
that
it
goes
help
from
ego
and
a
couple
others
to
get
that
going
and
currently
it
is
an
outstanding
issue
in
terms
of
receiving
messages
which,
but
it
seems
to
be
more
of
an
issue
in
the
console
client
self,
rather
than
the
the
underlying
protocol
and
their
implementation,
so
I
think
they're.
Looking
into
that
next
and
I
know
something
else.
H
The
you
know
like
after
we
had
the
storm
summer
last
week,
so
we'll
be
looking
into
assessing
TSS
and
how
we
can
potentially
use
key
SS,
which
is
a
whisper
like
API,
but
it
has
basically
direct
routing
and
also
nearest
neighbourhood
browsing
another
thought
we
had
on
that
is
like.
If
you're
going
to
go
that
route,
you
could
also
embed,
and
so
swarm,
has
essentially
this
concept
of
aggregated
notes.
So
what
could
potentially?
What
could
be
potentially
done
with
these
aggregated
notes?
H
Is
you
could
collect
a
bunch
of
messages
and
then
process
them
in
some
way?
So,
for
example,
you
could
actually
embed
a
mixed
net
within
the
swarm
network,
so
so
to
give
you
a
picture
of
what
that
might
look
like
is
you
might
have
a
node
within
the
storm
network
that
you
can
send
directly
messages
to
which
will
then
bring
it
into
an
embedded
mixed
network
which
would
then
give
you
all
the
privacy
properties
and
global
adversary
resistance
that
a
mixed
net
would
provide.
H
You
could
also
potentially
have
2
mixed
Nets
in
a
nearest
neighbourhood
perspective
and
send
a
message,
this
nearest
neighborhood
and
not
even
know
which
mixin
it
goes
through,
and
it
kind
of
would
give
us
like
the
best
of
all
worlds
that
we've
been
we've
been
looking
for
in
messaging.
You
would
have
fast
one-to-one
routing
if
you
wanted
to.
H
If
you
wanted
to
have
something
a
little
more
whisper
like
you
could
do
something
like
nearest
neighbourhood
and
then,
if
you
want
to
like
ultimate
privacy,
you
could
use
the
embedded
mixed
net,
I,
know
and
or
a
combination
of
all
of
the
above,
so
so.
This
is
an
exciting
progress
on
on
that
front
and
I'm
looking
forward
to
seeing
that
moving
into
the
client.
Of
course,
there's
no
timelines
on
that,
and
this
will
be
looking
at
doing
a
collaboration
agreement
with
swarm.
H
A
And
one
other
thing
that
I
was
also
on
this
message:
layer,
security,
meetup
and
that's
essentially
the
idea
how
to
make
perfect
forward
secrecy
and
perfect
secrecy.
If
you
can
call
it
like
this
for
group
chats
so
right
now
we
use
the
thing.
That's
called
double
agents,
which
is
good
thing.
It
works
like
a
perfect
forward
secrecy
and
perfect
backwards.
A
You
can
see
one
bar
one
checks,
but
it
doesn't
scale
well
huge
group
chats
and
some
companies
there
right
now
working
on
this
kind
of
standard
to
make
it
work
on
group
chats
again
it's
a
very
early
in
the
research
right
now,
so
they
secure
they
have
some
fancy
scheme
up
with
like
ratchet
trees
and
other
fancy
maths
there.
But
it's
not
yet
proven
to
be
secure,
so
they're
working
on
kind
of
cheating.
How
secure
is
it
and
figuring
out
the
security
properties
of
that?
So
right
now?
C
Yeah
I'd
add
two
more
little
things
to
the
protocol
stuff
one
is.
The
swarm
has
done
a
lot
of
work
on
this
feature,
which
is
basically
wait
to
have
some
mutation
capabilities
of
contents
for
an
image
in
this
one,
and
one
proposed
use
case
for
us
like
once
we
have
once
we
have
the
sync
layer,
one
use
case
for
that
seed
is
basically
to
use
it
as
a
little
cash
or
a
little
temporary
storage.
C
While
nodes
are
flying
to
basically
solving
the
offline
use
case,
and
so
there's
two
ways
you
can
use
the
storage
like-likes
form
one
is
one
is
like
a
backup
so
that
you'd
dump
the
entire
conversation
there,
and
then
you
can
decode
it
as
with
a
single
key.
But
if
you
want
to
maintain
a
perfect
for
secrecy,
what
you
do
instead
is
that
you
just
store
all
the
messages
as
they
travel
on
the
wire
right
now
between
life
pairs.
A
little
bit
like
we
use
our
main
service,
you
can
use
the
feeds
the
same
way.
C
Implementation,
that's
been
a
slowly
improving
and
we
use
it
in
in
a
new
command
line
or
now
little
GUI
client
for
which
could
talk
to
swore
to
status
notes.
So
you
could
basically
chat
chat
using
this
whisper
yulian.
Now.
Last
week
we
replayed
a
bit
further
with
this
idea
and
we're
able
to
use
this
with
whisper
implementation,
instead
of
guess
the
guess
one
from
go.
C
So
what
that
means
is.
Basically
we
tried
the
idea
that,
if
we
wanted
to,
we
could
swap
out
guess
in
spatters,
go
or
in
status,
console
client
and
use
Nimbus
instead,
and
we
were
able
to
actually
both
send
and
receive
messages,
which
is
pretty
well
fun,
little
experiment
to
do
so
at
some
distant
point.
In
the
future
we
could
look
into
integrating
like
Nimbus
in
the
status
application
as
well.
A
C
I'd
say
using
get
from
status.
Go
it's
a
lot
easier,
then
use
a
hand
in
this,
because
it's
you
know
thing
language
generally.
It
doesn't
make
much
sense
to
use
name
from
goal,
except
that
you
can
reuse
the
go
code
so
like
this
would
like.
If
we
decide
to
go
down
the
shrubs
with
the
status
happen
in
some
distance
distant
future.
What
would
probably
happen
is
that
we
remove
go
completely.
A
C
A
Now
we're
moving
there
I
think.
It's
also
makes
it
easier
because
we're
moving
stuff
to
like
we
move
our
protocol
to
the
RPC
calls
like
JSON
RPC
calls,
so
you
can
kind
of
run
the
seconds
no
they're
gonna,
replace
a
part
of
it
with
the
part
of
our
PC
Pro
code
might
go
to
Nimbus,
for
instance,
in
part
still
to
stutters,
go
but
yeah.
That's
yeah!
A
C
Of
the
protocol,
like
whisper,
is
a
separate
layer.
So
what
you
want
to
do,
there
is
actually
see
them
as
independent
components,
and
ideally
we
like
when
we
create
the
protocol
and
any
protocols
we
create
really
it's
good
to
know,
tip
them
as
being
part
of
a
stack
or
any
components
that
that
we
can
pick
and
choose
so,
for
example,
one
application
might
need
synchronized,
there
are
transfer.
Basically,
you
know
the
TCP
of
private
communication
and
other
one
might
might
prefer
UDP,
which
is
basically
what
we
have
in
which
the
knowledge
is
unreliable.
C
C
C
A
H
The
one
that
I'm
particularly
care
about
is
application
performance.
So,
sir,
the
better
we
get
like
under
estimations
of
what
we
imagine,
those
things
that
look
like
then
the
better
we
can
get
sort
of
managing
our
resources
and
trying
to
paralyze
certain
things,
especially
when
we
you've
got
like
milestones
like
v1.
So
so,
if
there's
anyone
that
can
help
contribute
to
that
that'd
be
great
I.
Think
there's
also
a
revision
on
the
swarm
review
process.
That's
being
underway.
H
There
was
a
discussed
post
I
stood
by
Nana
bill,
so
there's
a
Google
Doc
out
there
somewhere
that
you
can
leave
feedback
on
and
I
think
it's
in
that
post.
So
so,
please
do
I'll,
be
leaving
my
fix
League
back
on
it
shortly
and
then
we'll
be
reviewing
it
only
Janice
Cole
again
tomorrow,
yeah
and
I
think
that's
pretty
much.
It.
A
F
We
have
both
core
UI
and
I
think
that
maybe
we've
got
multi-account
or
key
card
as
well.
I
can
give
a
quick
update
on
core
you
I
just
status
wise,
so
basically
like
today.
F
The
most
important
thing
is
that
Eric
and
Andre
are
gonna,
kick
off
work
on
the
mold
count
screens
on
starting
with
just
the
UI,
for
the
account
explorer
I
believe,
but
we're
gonna
break
that
work
out
into
some
issues
today
and
get
that
into
right
and
then
Eric
has
finished
work
on
refactoring
wallet
what
she
was
doing
to
set
up
or
persisted.
Well,
it
transit
or
token
transactions
tokens
and
stick
for
a
longer
than
two
weeks.
F
The
actual
that
actual
work
is
now
going
to
fall
under
the
multi
count,
scope
and
then
Andre
is
making
really
good
progress.
I
think,
probably
nearly
wrapped
on
the
new
signing
of
the
new
screen
for
the
wallet,
which
is
part
of
the
multi
count
work
as
well.
Technically
and
meanwhile,
Julian
has
filed
a
PR
for
native
ans
registration,
which
I
think
is
in
QA
and
Italy
is
still
working
on.
F
The
VA
account
setup
screen
the
initial
set
of
screens
that
you
encounter
when
you
are
first
onboarding
to
the
app
and
and
will
continue
to
work
on
an
onboarding
flow
flexible
weeks.
So
if
anybody
from
the
gene
has
technical
details,
discuss,
please
go
for
it,
but
that's
where
we're
at
progress
wise.
J
J
So
four
key
card
itself,
Dimitri
has
started
to
integrate
the
new
screens
from
from
embodying
and
logging.
We've
decided
to
proceed.
Second
sequentially
with
regards
to
key
card
and
ledger
screens
to
first
implement
key
card
screens
and
once
that
will
be
approved
and
good
to
go,
we'll
work
on
the
ledger,
one
because
we
feel
otherwise.
If
we
do
everything
at
once,
we
put
too
much
to
the
schedule
at
risk
and
this
schedule
is
to
have
a
target
code
freeze
of
this
key
card
integration
by
a
first
week
of
July
and
the
material
count
front.
J
We
are
having
these
design
/
user
experience.
Discussions
mostly
multi-account
affects
the
wallet,
of
course,
with
the
with
an
account
Explorer
view
and
in
some
ways
to
add
new
accounts.
So
we
are
discussing
that
since
what
I
mean
Rachel
mentioned
it,
we
need
to
end
off
to
call
UI
the
work
on
the
wet
side,
so
Andreas
has
produced
some
designers
or
we're
in
the
final
stage
to
to
hand
off
these
two
to
call
UI
and
also
Merc.
You
counts
as
impacts
on
other
parts
of
the
app.
J
So
we've
been
discussing
that
a
lot
in
the
past
days,
impacts
I
mean
on
chat,
app
and
ens
on
chat,
because
now
there's
a
whisper
key
and
a
different
wedding
key.
So
we
are
trying
to
make
things
very
clear
and
documented
about
what
happens
when
someone
wants
to
send
the
funds
in
chat
to
someone
else,
I
mean
which
accounts
are
used
on
both
side,
both
on
on
the
sender
and
receiver.
J
And
this
has
some
impacts
on
constants
on
tribute
to
talk,
so
we
we
preside
that
and
discuss
that
in
the
coming
early
this
week,
actually
on
the
death
side.
Basically,
because
when
someone
opens
adapt,
we
need
to
define
precisely
which
account
is
used,
I
mean,
and
can
the
user
choose
this
account
and
on
the
nside
the
same
thing
we
need
to
clear
out,
which
is
the
account
that
actually
signs
the
registration
of
transaction.
J
So
we're
having
all
this
discussion
to
all
these
impacts
that
the
fact
that
we
now
have
several
account
within
status
can
have
on
the
different
parts
of
the
app.
So
that's
about
design,
mostly
and
on
the
implementation
side.
Andrea's
proposed
last
week,
a
proposal
on
how
to
use
the
telescope
art
from
the
react
patent
from
this
module
count
and
I
mean
the
need
now
needs
to
be
some
agreement
between
yeah
I.
A
A
G
Yes,
so
it's
related
to
the
performance
improvement,
so
I
think
when
we
talk
to
performance
improvements,
we
really
have
two
aspects
of
it.
There
is
the
startup
time
and
and
time
so
this
one
is
for
the
rent
time,
but
it
could
also
potentially
improve
the
start
time
seats.
It
means
there
is
less
study.
Studies,
react,
could
involved,
potentially
so
regarding
wallet,
API
I
am
currently
working
with
Dmitry
on
study
site.
G
Well,
is
doing
the
statistical
side
and
I
test
it
on
studies,
free
excited
to
replace
the
fetching
of
transactions
on
react
side.
So
on
react
side.
Currently
it's
mostly
done
through
a
certain
API
and
the
idea
was
to
make
it
on
stereo
aside
using
only
the
blockchain,
so
that
will
all
be
a
performance
improvement
because
it
means
there
is
no
need
to
parse
the
data.
On
studies
react
side.
There
is
no
need
to
there.
There
will
be
persistence
as
well
and
right
now,
when
we
get
neutrons.
G
So
what
we
do
right
now
is
when
the
user
is
logged
in
in
order
to
receive
the
transaction
as
fast
as
possible.
We
check
every
block
and
basically
Dmitry
is
doing
some
optimizations.
So
that
the
issues
I've
pointed
out
with
the
RPC
API
in
terms
of
what
data
it
provides
and
what
kind
of
calls
it
requires
to
fetch
all
the
data
that
we
want
for
a
transaction
so
is
optimizing
that,
by
making
signals
from
status
code
that
provide
me
with
all
the
data,
I
need
to
save
a
transaction.
G
And
by
doing
this
on
go
side,
then
we
reduced
the
number
of
calls
and
with
multi
accounts,
it's
even
more
beneficial,
because
the
Mediacom
means
that
we
have
to
do
all
of
this
stuff
n
times
for
n
being
the
number
of
accounts.
So
it's
not
a.
This
is
about
not
making
performance
improvement
but
not
making
a
performance
degradation.
G
A
G
So
the
next
thing
is
the
cherry
API
and,
regarding
that
I'm
really
looking
forward
to
the
filters
and
chats
being
moved
to
Stars
go
because
that's
the
last
invisible
polling
that
we
have
on
studies
react
because
that's
the
last
part
that
use
web
3
actually
I
made
up
here
this
weekend.
That
removes
the
last
remains
of
web
3,
except
for
for
this.
G
For
for
the
filters
and
stuff,
that's
also
a
lot
of
course,
because
Frances,
when
you
I
think
that's
one
of
the
main
reason
Jared
client
is
so
slow
because
it
probably
has
a
lot
of
chats
and
they
are
all
requiring
creation
of
scene
keys
and
all
kind
of
back
and
forth
between
status
quo
and
I
was
relaxed
during
initialization.
So
I
think
this
will.
G
G
G
Maybe
I
will
try
to
make
a
more
fine-grain
analysis
off
bet
because
their
presence
there
is
whenever
you
receive
a
message.
There
is
some
computations
that
are
made
in
subscriptions
to
recompute
the
order,
and-
and
actually
that's
not
that
expensive,
it's
it's
me
a
millisecond
or
two
while
the
receive
many
is
easily
150
millisecond.
G
A
G
A
G
I
was
just
wondering
if
anyone
knows
the
like
what
would
be
the
cost,
for
instance
with
realm',
it's
pretty
fast,
get
by
ID.
So,
for
instance,
when
we
receive
a
new
message,
we
we
can
do
a
get
by
primary
key
and
and
it's
it's
under
millisecond,
to
get
the
response.
If
the
message
is
there
or
not
and
I'm
wondering
if,
if
we
move
all
of
chapter
systems
to
status
quo,
if
it
isn't
going
to
be
a
slow
down.
G
G
G
A
The
idea
is
that
we
will
that
status.
Go
will
actually
notify
about
new
messages
like
proactively,
first
of
all
and
the
second
of
all
its
it
will
only
notify
about
the
messages
where
you
need
to
be
rendered
for
so
that's
my
idea.
Okay,
so
you
know
that
this
chat
has
this
many
messages
rendered
and
then,
if
you
receive
a
new
message,
that's
like
let's
say
it's
yesterday's
message
and
you
already
have
yesterday
so
to
delayed
message
for
some
reason
intact.
Then,
then
you
will
be
render
stuff,
so
you
will
figure
out.
A
G
G
And
four
new
messages,
I
think
the
ideal
is
simply
that
you
have
an
event
signal
that
says
there
is
a
new
message
and
there
is
some
additional
information
regarding
messages
that
needs
to
be
tweaked
because
they
are
not
last
messages
anymore.
Stuff,
like
this
I,
think
that's
the
simplest
solution,
yeah
that
would.
A
A
C
A
C
G
G
A
Work,
the
old
way
can
China
but
yeah.
We
can
of
course,
move
it
later
on
as
well,
because
I
don't
see
that
it
takes
a
lot
because
you,
you
will
still
make
a
mess
of
a
request.
Fine,
that's
not
heavy
operation,
and
then
you
just
wait
and
then
we
get
events
from
status
go
as
soon
as
you
get
messages,
so
yeah.
G
A
Management
is
like
Adam
is
like
working
on
it
just
right
now,
all
right
so
and
then
we
want
to
make
messages,
and
essentially
what
technically
I
want
to
plug
it
into
this
subscription
that
you're
talking
about
so
that's
where
you
go
integration
will
gonna
be
or
not
exactly
there.
It's
will
be.
It
will
be
plugged
into
when,
when
we
request
more
messages
from
beyond
so
yeah.
Let's
take
that
place.
Okay,.
G
G
Okay,
another
performance
issue,
I
noticed
in
terms
of
rent
time,
is
whenever
you
have
a
lot
of
markdown
going
on
in
your
messages
and
so
far
I'm
like
I,
don't
know
how
accurate
it
is
with
the
emulator
to
measure
that.
But
it
seems
to
me
that,
like
the
stuff
I
expect
it
to
be
expensive.
The
way
we
we
parse,
the
message
and
cut
it
into
chunks
doesn't
seem
to
be
the
like.
It
seems
that
even
after
it's
mounted
it
still
that
takes
some
time
to
appear
on
the
screen.
G
A
Like
normal
labels
on
iOS,
at
least,
they
can
display
all
this
text
formatting
that
we
want
them
to
display,
including
names.
So
maybe
just
we
are
trying
to
invent
something.
That's
already
in
react
native
like
so.
You
can
just
use
one
text
element
and
just
make
a
depends
on
formatting
sync
to
them
like,
oh
and
is
called
attributes
when
you
send
a
string-
and
you
also
sent
a
make
it
bold
from
this
character
to
this
character
and
then
it's
a
normal
label,
but
it's
Kings
plate,
bold
italics,
like
underlying
monospace
and
clean.
G
A
C
A
A
H
Cool
so
I
mean,
like
you,
guys
started
getting
into
the
details,
and
some
of
that
so
so
basically
I
wanted
to
raise
this
application
performance
stuff
and
when
I'm
talking
about
that
I'm
talking
about
the
user
interface
like
loading
of
the
application,
the
visual
responsiveness
and
a
great
user
experience,
there's
been
some
great
work.
That's
been
happening
on
this.
Incentives
are
like
with
JavaScript
modulation
and
moving
a
little
chat
processing
to
go
as
well
as
finding
some
like
UI
rendering
stuff,
like
the
markups
thing
that
Eric
just
mentioned
what
I'd
love
to
hear
from.
H
What
other
ideas
or
items
are
just
important
or
maybe
should
be
considered
as
high
priority
and
I'm
also
kind
of
interested
to
hear
from
everyone?
What
you
imagine
the
version
one
will
look
like
performance
and
user
experience
perspective
igor.
If,
if
you
want
to
start
with
that,
and
I
can
write
those
questions
down
in
the
notes
as
well,
if
that's
helpful,.
A
Yeah
so
yeah
I
think
this
that
we
just
do
too
much
on
script
and
I.
Think
that's
caused
a
lot
of
issues
when
you,
when
I
either
have
a
lot
of
chats
for
joining
the
exit.
Chats,
so
I
really
think
that
the
moving
protocol
of
parsing,
just
as
though,
and
only
exposing
events
that
are
needed
to
be
exposed
to
JavaScript
locale
port.
So
the
regard
to
the
starting
time
personally,
I
don't
have
the
issue
with
that.
Specifically,
so
it's.
G
So
I
would
back
you
up
on
the
started
startup
time.
I.
Think
personally,
I
would
prefer
that
for
v1
we
focus
on
the
runtime,
because
that's
the
yeah,
the
bar
is
not
always
very
high
for
when
you
look
at
other
apps,
but
we
are
definitely
a
bit
behind
on
on
the
forces,
the
the
view
switching
and
that
kind
of
stuff.
G
So
if
there
is
anything
we
can
improve
on
that
side,
it's
it's
I,
think
important
for
v1
and
that's
why
the
the
chat,
API
and
the
wallet
API
from
Cisco
will
at
least
help
with
that
by
removing
some
of
the
load
under
transcript
thread.
So
yeah
I,
like
I,
think
the
the
details
of
what
things
we
could
look
at
good
I
can
write
down
later,
because
I
have
lots
of
ideas,
but
we
already
talked
a
lot
with
Igor
to
a
yeah.
A
Yeah
but
wasn't
ready
to
I'm
sure
my
sound
is
horrible.
No,
we
can
hear
you
okay,
so
sorry,
I
missed
a
question
so
right
now
we
are
doing
three
major
things
to
improve
performance
versus
to
improve
cold
startup
by
splitting
javascript,
and
things
like
this.
The
second
is
that
we
are
moving
protocol
to
status
go
and
the
third
one
is
that
we
are
fixing
like
chat,
rendering
with
the
formatting.
So
do
you
think
that
is
these
are
the
right
thing
to
focus
on?
Is
there
the
most
important
one
and
if
no,
then,
which
areas?
C
A
A
D
Yeah,
well,
my
opinion
is
we'll
be
a
little
bit
different
or
a
little
bit
higher
level
and
I.
Think
what
really
matters
and
what
is
really
important.
And
not
it's
not
very
clear
to
me
that
we
did
that
so
far
is
we
need
to
very
pragmatically
measure
things
and
depending
on
scenario
and
and
actually
first
thing
is
actually
we.
D
So
it's
kind
of
a
very
high
level
err
opinion,
and
it's
not
clear
to
me
that
we
are
fixing
the
right
things
right
now
and
then,
when
it
comes
to
experience
from
the
user
perspective.
Well,
I
guess
we
all
see
that
the
the
app
does
not
feel
instance
always,
and
so
that
would
be
like
me
and
I
in
just
make
the
kind
of
experience
I
would
expect
from
our
users,
but
at
perspective
that
everything
feels
instance,
especially
given
that
we
have
a
small
workload
so
far.
So
how
do
we
do?
D
G
I
I
I
Write
like
really
easy
to
cover
these
things
and
my
ring
what
this
company
means
in
all
spread
optimize
this
yeah.
So
so,
from
my
point
of
view,
it's
it
would
be
really
useful
understand,
what's
happening
in
just
for
it
and
find
the
ways
how
we
can
optimize
the
UI
by.
K
Yeah
so
startups,
it's
kind
of
easy
to
say
that
it's
fine
to
wait
three
or
four
seconds
I
mean
it's
totally
fine
for
me.
I
have
five
on
ten
and
it
loads
like
in
one
second
and
I,
I,
don't
notice
the
problem
button,
my
slower
device,
it
takes
more
than
10
seconds,
and
it's
not
that
good
and
well
for
the
end
user.
It's
it's
really
bad
to
wait.
10
seconds,
that's
my
opinion,
so
we
actually
can
just
keep
it
and
say
like
my
better
phone
and
you
will
have
1
second
setup
time.
That's
it!
K
But
well,
not
good!
My
opinion.
We
actually
we
don't
need
to
make
it
perfect,
but
it
should
be
better
than
it
was
a
month
ago
or
so
regarding
performance,
doing
screen
transitions,
etcetera.
So
as
far
as
I
can
say
from
what
I've
seen
when
I
touched
this
part,
like
few
weeks
ago,
most
at
least
its
rendering
of
UI
components
so
yeah,
if
you
will
find
some
screen
which
did
not
touch
yon
database,
doesn't
doesn't
do
anything
really
special
on
jet.
K
Besides
rendering
components
it
will
be
slow.
Anyway,
we
have
some
places
where
we
use
wrappers,
which
are
not
really
needed
for
rendering
the
screen.
So
we
add
extra
components
like
in
some
sunscreens.
You
have
like
20%
of
components
which
aren't
really
used.
They
are
not
important
for
rendering
the
screen.
This
contributes
to
slow,
rendering
we
have
segs,
which
contribute
to
slow
rendering
on
Android.
That's
for
sure
they
drop
like
10
frames,
on
each
navigation
easily
and
so
on.
So
there
are
a
lot
of
things
which
we
can
improve.
K
I'm,
just
not
sure
that
some
magic
stuff,
which
is
going
on
J
thread,
is
the
reason
of
song
as
doing
navigation
and
as
far
as
I
understand,
that's
the
biggest
concern
the
way
how
you
feel
how
it
feels
when
you
like
touch
some
button
and
have
application
reacts.
Also,
we
probably
need
to
move
from
dispatching
refrain
event
on
touching
the
button
when
you
want
to
know
get
to
another
screen,
you
probably
need
to
get
rid
of
it
and
just
use
like
some
deal
call
to
navigation,
listen
for
some,
like
inputs
very
using
Rephaim
loop.
K
K
Well,
that's
it
from
I
said:
what's
most
important
agree
that
probably
navigation,
fast
navigation
and
like
smooth
UI
is
more
important
than
startup,
but
it
can
be
10
seconds.
That's
that's
really
bad
one
more
thing,
which
is
really
bad
in
many
places
in
our
application
is
animation,
because
I
saw
that
even
recently,
some
animations
without
native
dialer
were
added,
and
that's
not
good.
We
need
to
I
have
some
kind
of
policy
to
not
add
animations
without
native
driver
to
be
either.
K
G
It's
good
that
you
pointed
out,
I
think
we
should
really
think
about
that
more
because
there
is
a
lot
of
cases
where
there
is
no
point
throwing
events
around,
and
it's
been
a
it's
been
good
so
far
to
get
to
like
figure
out
the
app
and
everything.
But
at
this
point
we
can
really
make
more
with
local
state
and
and
direct
course
I'm
doing
that,
for
instance,
in
the
wallet
for
for
callbacks.
There
is
no
point
throwing
an
event
for
each
callback.
G
F
Perspectives
offer
about
performance
related
issues.
All
I
can
say
is
like
what
I
experienced
as
a
user.
I
mean
I'm
also
on
an
iPhone
10.
So
start
time
is
really
not
bothersome.
To
me,
I
mean
the
only
thing
that
I
find
noticeable
and
confusion
if
I
were
coming
from.
Another
application
is
obviously
the
time
it
takes
your
message
syncing,
but
that
has
been
even
Darce
to
be
improved
in
the
past
couple
months
so
and
yeah
sorry,
I,
don't
think
I
have
to
have
much
to
offer
here.
F
G
F
A
E
G
Want
to
say
that
I
made
a
pair
that
should
improve
that,
because
right
now,
the
promise
that
we
have
this
separate
entity
in
the
database.
That
is
storing
the
message
statuses,
but
we
actually
only
use
it
for
personal
statuses,
so
I
moved
a
sim
field
in
a
message
entity.
So
that
means
that
later
on,
when
we
sync
messages,
we
could
sink
the
boolean
force
in
as
well
and
therefore,
since
status
should
be
synced
between
devices
possibly
much
more
easily
than.
G
E
So
I
understand
that
most
of
the
things
that
I'm
worried
about
are
being
worked
on.
I
just
want
to
speak
up
and
the
types
of
things
that
I
think
are
priorities
for
version,
one
to
make
sure
they
worked
correctly,
because
you
don't
want
to
do
a
large
marketing
push
to
get
a
bunch
of
users
and
happier
than
they
need
to
get
some
small
things
like
this
well
necessarily
small
on
the
back
end.
But
their
perception,
that's
probably
that
they're
small
and
then
multi-account
is
taken
care
of
a
lot
of
the
stuff.
E
B
I
I
can't
add
much
performance
to
be
honest,
especially
not
next
to
what
I
understood
is
being
worked
on
and
what
has
been
mentioned
before,
like
they
only
I
mean
I
have
a
long
long
list,
but
the
the
primary
thing
I
would
be
concerned
about
in
an
ideal
app
is
that
I
keep
seeing
it
come.
It
comes
back
to
me
over
and
over
when
I
look
at
how
people
use
messages
messaging
as
an
application
and
what
they
would
expect
from
a
new
messaging
application
is
that
it's
strongly
focused
on
family
and
friends.
B
B
That
would
be
the
major
the
major
difference.
I
need
to
put
some
more
thought
into.
If
there's
anything
else
missing,
but
I
think
that
would
that
would
be
a
big
one
and
next
to
that
I
think
we
can
still
improve
it.
How
you
invite
friends,
I
think
a
lot
of
that
is
being
fixed
in
profile,
because
a
lot
of
the
problems
we
saw
was
people
not
really
understanding
who
they
were
and
how
to
share
their
account
with
others.
So
I
think
we're
fixing
some
of
that,
but
we
haven't
been
paying
too
much
attention
to
it.
B
A
H
No
I'm
going
to
I
mean
that
that
was
amazingly
helpful.
So
thank
you.
Everyone
for
participating
on
that.
The
one
thing
that
I
thought
was
interesting
was
that
the
the
rendering
of
screams
didn't
seem
was
still
slow,
regardless
of
the
usage
of
the
Jay
Jay
s
thread,
all
the
lack
of
so
I
would
say
that
probably
needs
to
have
a
little
bit
more
focus
as
well.
Just
to
understand
that
a
bit
more.
But
apart
from
that,
it
all
sounds.
It
all
sounds
pretty
good
I.
G
G
We
have
a
discussion
on
what
is
the
lowest
end
device
that
we
are
supporting,
because
that's
kind
of
what
comes
out
of
everyone's
opinion
on
startup
time,
as
as
Julian
said,
we
might
want
to
have
matrix
based
on
the
target
users
that
we
have.
So
if
we
say
let's
say
it's,
the
lowest
end
device
click
take
is
and
galaxy
s5
or
something,
and
it
shouldn't
take
more
than
five
second.
G
And
then
we
see
if
we
take
already
less
than
five
second
and
then
we
can
consider
start
time
done
for
the
one
and
then
we
will
improve
further
on
v2,
considering
that
there
is
some
incoming
react
native
improvements
regarding
startup
time,
because
they
have
the
same
problem
with
their
marketplace
and
at
Facebook
and
they
plan
to
during
this
year
to
merge
some
changes
that
could
improve
that
as
well.
Oh.
K
Using
slow
device,
I'm
kind
of
start
application
and
measure
how
much
time
it
takes
there
depends
on
what
you
are
going
to
measure.
Actually,
you
can
like
record
the
video
and
measure
frames
needed
to
open
application
and
the
first
screen,
or
you
can
just
measure
the
damage
is
needed
to
Lourdes
JavaScript.
H
Yeah,
there's
there's
certainly
ways
of
getting
getting
quantified.
Data
on
this
I
would
say
that
it's
probably
worth
looking
at
android
market
share
in
general
and
then
finding
out
what
is
like
the
most
sort
of
dominant
versions
of
android
on
this
sort
of
lawrence
so
like
if
something's
got
like
a
lot
larger
than
like
10%
or
20%
market
share
in
android
in
a
second
old
version,
then
look
at
these
sort
of
top
of
the
line.
H
Almost
dominance,
android
devices
for
that
particular
version
that
are
still
operating
in
2019,
and
I
think
that
would
probably
give
you
a
pretty
good.
That's
pretty
crappy
I
think
the
Galaxy
s4
is
bad,
choose
something!
That's
pretty
it's
pretty
lame
by
today's
standards,
so
it's
probably
fine
to
type
it
up.
You
know
that's
based
on
Europe
from
the
hip.
K
K
G
F
I
just
wanted
to
give
her
the
read
a
gentle
reminder.
If
you
create
a
bounty
on
github
as
the
intuition
get
coin,
please
be
sure
to
follow
up
on
it,
because
we've
observed
a
few
times
that
there
will
be
a
contributor
who
maybe
signs
on
and
then
we
don't
hear
back
from
them
or
I
knew
that
there's
a
gate
coin,
bot
that
automates
like
a
payment
for
the
contributor
or
they
maybe
get
stuck,
and
we
don't
have
people
necessarily
watching
all
of
your
bounties.