►
From YouTube: Status Townhall #36 - June 10, 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
All
right
and
let's
get
started,
hi
everyone
happy
Monday
and
welcome
to
our
36
townhall.
Let's
get
started.
First,
we
have
a
update
from
people
opps.
We
are
actively
hiring
for
two
roles,
as
you
can
see
listed
here,
a
developer
advocate
slash
technical
writer
and
product
designer.
If
you
know
anybody
who
would
be
great
for
these
positions,
don't
forget
about
our
referral
program
and
just
a
reminder
that
we
have
the
off-site
coming
up
in
September.
So
please
make
yourself
available
for
those
dates
and
more
information
will
be
coming
soon.
B
C
B
Changed
so
multi
count
is
still
looking
like
towards
the
end
of
July,
and
we
have
a
couple
of
the
onboarding
and
profile
and
client
facing
elements
that
are
probably
going
to
be
worked
on
from
the
month
or
so
and
then,
following
all
of
that,
we
have
our
security
audit.
A
quick
word
on
timelines
I
think
it's
important
for
us
to
maintain
accuracy
of
like
a
realistic
amount
of
work.
You
know
we've
we
had.
B
We
had
a
deadline
at
the
end
of
the
quarter
and
I
think
that's
probably
unrealistic
amount
of
work
that
we
need
to
put
into
status
b1
so
keep
keep
updating
the
timelines
with
realistic
estimates
and
I
think
that's
probably
a
better
way
for
us
to
start
getting
estimates
on
when
things
will
get
done
and
completed
and
the
more
work
that's
in
there.
The
more
we'll
be
able
to
make
sure
that
we
don't
underestimate
the
amount
of
work.
That's
left
on
the
next
slide.
B
You
can
see
kind
of
a
part
based
progress,
update,
so
we're
out
of
186
total
issues.
79
of
them
are
completed.
A
pie
chart
is
definitely
gotten
bigger
since
last
time,
and
you
know,
if
you
are,
you
know,
if
you
do
want
to
have
a
play
around
with
it
check
out
right,
there's
a
lot
of
cool
visualizations.
You
can
do
and
yeah
so
that
that's
essentially
a
quick
update,
we're
looking
at
probably
a
code
phrase
towards
the
end
of
July,
based
on
the
amount
of
work.
B
D
So
last
week
we
kicked
off
the
artist
series
with
Venus
usernames
that
articles
live.
You
can
find
it
at
the
top
of
our
about
status.
That
I
am
also
you
can
check
out
the
discuss
clothes
linked
in
here
for
their
conversation
and
a
linked
Q&A
that
me
and
Barry
did
for
the
a
bunch
of
community
questions
fun
on
doing
those
as
much
as
possible.
D
So
please
go
read
that
play
the
variables
see
how
they
work,
give
us
feedback,
and
also
you
can
find
us
in
the
token
economics
channel,
to
chat
about
all
things
regarding
this
work
up
next,
to
put
the
sticker
market
originally
want
to
do
the
damn
store,
but
Maggie's
gone,
there's
some
other
other
modeling.
We
want
to
add
to
it.
So
that's
in
progress,
the
sticker
market
articles
in
progress,
it's
a
different
model
than
clintus
blocking
of
capital,
and
assuming
it's
going
to
be
gone
for
a
long
time.
D
We
also
last
week
integrated
critic,
which
is
a
new
product
from
Trello
bits
that
were
that
we're
testing
out
for
them.
So
this
is
a
github
integration
that
links
into
various
repositories
that
have
solidity
smart
contracts
and
what
it
does
is
runs
a
series
of
checks,
mostly
using
right
now,
their
tool
called
slither
for
any
problems
with
a
solidity
contract
for
every
commit
or
pull
request
you
make
on
that.
D
On
that
repository,
it
uses
the
already
established
github
permissions
that
we
set
up
for
the
status
organization,
so
anything
that
you
have
access
to,
but
that
status
you
should
be
able
to
log
in
to
critic
that
IO
and
see
whatever
I've
linked
or
look
at
yourself,
and
this
should
help
us
quite
drastically,
prepare
for
audits,
so
making
sure
you
squash
all
of
these
bugs
within
github
that
return
to
make
a
commit
or
think
you're
done
with
the
project.
This
helps
me
and,
and
auditors
I
figure
out
what
work
needs
to
be
done
or
not.
D
D
Two
point,
two
for
the
community
to
say:
oh,
we
had
this
issue
is
just
how
I
got
fixed,
so
you
can
feel
better
about
the
deployed
smart
contract
and
maenette.
So
future
versions
of
this
there's
a
brand-new
product
from
them.
It's
kind
of
part
of
our
retainer
to
work
on
this
and
something
I've
been
wanting
for
a
while,
but
they'll
be
integrating
a
lot
of
their
other
tooling
to
automatically
work
as
well
to
give
us
more
robust
feedback
when
we
do
smart
content
development.
A
C
A
C
So,
in
this
case,
it's
a
little
bit
mixing
together
with
the
protocol
stuff
and
sometimes
mixing
together
with,
let's
say,
core
UI.
So
it's
a
so
first
thing
that
we
do.
We
do
like
protocol
negotiation.
What
it
helps
us
to
do
is
to
actually
get
rid
of
the
this
shared
topic
for
one-on-one,
chats
and
essentially
what
for
end
users.
It
would
be
just
less
traffic
per
day.
Essentially,
then,
we
are
continuing
to
moving
protocol.
C
C
Romanist
continue
working
on
splitting
our
huge
javascript
file
that
we
load
at
startup
into
modules,
so
we
don't
load
the
things
that
are
not
needed
for
us
and
also
some
other
miscellaneous
fixes,
but
he
and
also
in
here
we
also
like
Eric,
also
help
to
improve
like
30
percent,
like
our
chat,
formatting
and
sound,
but
it's
still
very
slow.
So
there
is
still
not
an
issue
for
that.
So
we
need
to
work
on
the
this
a
little
bit
more
and
the
next
thing
is
we're
working
a
little
bit
on
the
reproducible.
C
Android
builds
and
I
guess
right
now.
The
main
obstacle
is
the
unification
of
JavaScript,
which
we
can
turned
off,
obviously
because
for
the
performance
reasons,
so
Pedro
is
right
now
working
on
solving
this
issue
to
make
this
reproducible
and
the
one
more
thing,
that's
like
almost
done
nice
to
meet
Ruiz
working
on
the
wallet
API,
which
helps
to
make
our
wallet
like
I,
said
essentially
like
transaction
history
and
total
transaction
history
a
bit
smoother,
faster
and
yeah,
because
we
used
to
re-request
date
over
and
over
again
from
either
scan
right
now.
C
C
There
is
one
more
thing
were
working
on
is
the
performance
goals,
and
basically
we
took
some
really
fast
app
and
we
decided
on
the
three
types
of
devices
like
low-end
meter,
lantern
files
and
high-end
plug
flow
and
is
around
I
think
it's
a
galaxy
s4
each
device.
So
it's
we
mostly
focusing
on
that
choice
right
now,
because
first
of
all
performance
is
usually
less
of
a
problem
on
iOS
and
second
of
all,
because
of
all
these
App
Store
rules,
we
might
need
special
treatment
for
iOS
application.
C
So
in
the
top
you
see
there
like
the
data
for
the
fast
app
and
colors
here
means
like
green.
It
means
that
the
person
feels
it's
the
interaction,
'since
instantaneous
and
one
second
like
less
than
one
second
means
that
there
is
a
delay,
it's
visible,
but
it's
not
hard
to
keep
your
attention
there
and
again
and
more
than
one
second,
it's
like
orange,
or
between
one
second
and
ten
seconds.
C
It's
like
you
have
to
actively
keep
your
attention
on
this
task
to
be
able
to
to
wait
for
this
time,
and
then
we
had
a
release
in
March
to
seven,
and
then
we
are
trying
to
build
a
release
build
because
it
makes
sense
only
to
compare
these
builds
because
they
have
additional
performance
optimizations
between
each
other,
and,
first
of
all,
that
you
can
see
is
it
looks
like
we
digressed
in
what
is
called
interactions,
but
it's
actually.
It
is
a
first
kind,
but
it's
actually
just
due
to
how
we
measure
this
stuff.
C
So
essentially
interactions
for
us
is
when
you
topology,
at
least
until
you
see
all
the
messages
and
reply
to
may
make
this
the
whole
interaction
a
bit
smoother.
We
delay
loading
messages,
while
the
navigation
happens,
so
it
doesn't
interact
with
this
animation
and
this
kind
of
touch
response
and
so
and
since
with
you
lay
them
they
they
appear
in
like
like
further
way
in
the
timeline.
C
So
it
looks
like
it's
lower,
but
we
also
need
to
fix
this
rendering
issue
with
the
chat
messages
that
we
found,
that
I
hope
they
will
return
to
numbers
that
are
faster.
So
we
already
pretty
cool
at
restoring
when
the
app
was
launched
it
and
it
was
in
the
background
to
foreground
and
then
the
startup
time.
As
you
see
it's,
it's
improved
from
like
2.9
seconds
to
196
on
the
first
devices,
it's
around
30%
on
a
slower
devices.
It's
about
20%
improvements
and
also
this
seemed
was
a
little
bit
better
in
the
current
one.
C
But
that's
not
include
as
I
understand
it's
not
including
the
new
updates
with
the
mail
servers
that
are
not
there
yet
and
the
last
thing
here,
it's
the
target
times.
So
what
we're
trying
to
achieve
realistically
I,
like
the
date
right
now
might
be
discussable
right
now,
but
yeah
foreground
is
still
should
be
very
fast.
C
Theoretically,
we
can
achieve
startup
time
and
like
around
2
seconds,
maybe
a
bit
less
on
the
fast
devices
and
around
5
seconds
on
a
really
slow
ones,
and
then
for
sync:
we
we
need
to
investigate
a
bit
more,
taking
into
account
network
conditions
and
the
it's
a
little
bit
more
variables.
Here's
obedient
decided
on
these
numbers
just
yet
and
I
guess.
That's
all
for
me.
Thank
you.
A
E
E
One
dealing
with
the
wallet
screen,
one
dealing
with
native
ENS
registration
and
then
one
dealing
with
the
new
onboarding
flow,
the
wallet
and
the
onboarding
work.
That's
been
done,
set
us
up
to
offer
the
new
pin
code
and
login
as
well
as
key
card
support
and
multi
account
support.
An
Andre
will
demo
both
of
those
maybe
Andre
and
fiddly
after
this
slide.
So
that's
been
some
great
work
by
andre
julian
and
italy.
Over
the
past
few
weeks,
eric
meanwhile
has
made
some
performance
improvements
to
the
way
that
we
render
chat
messages.
E
So
we
have
more
efficiency
there
and
I
believe
he's
also
started.
Work
on
integrating
the
new
status,
go
wallet,
API
into
react
and
also
generally
preparing
for
other
API
changes
that
need
to
happen
in
react
in
order
to
support
multi
account
and
I
think
that
Andre
is
also
accounts.
Accounts.
Explorer
work
in
progress
is
probably
referring
to
the
UI
for
multi
account
and
we've
got
github
issues
for
those
in
place,
but
we'll
have
a
status
update,
I'm,
not
tomorrow
during
our
sync.
F
F
F
A
G
All
right
so
the
various
people
to
get
some
feedback
and
test
everything
work.
As
expected
with
the
current
tab.
Where
happen,
we
can
be
we.
What
we
were
I've
been
working
most
on
is
doing
the
to
enable
Phyllis
Phyllis
transactions
for
the
for
the
buyers,
we're
still
exploring
multiple
options,
but
the
the
most
promising
right
now
seems
to
be
to
use
the
Casper
linear
solution.
I
was
up
being
a
we're
trying
to
penalize
the
basically
incentive
and
punishments
for
arbiters
and
sellers.
So
we
can.
We
can
finalize
those
parameters
on
the
code.
G
H
Everyone
so
last
few
weeks
we
got
sort
of
minimal
version
of
the
sync
fully
functional
and
with
some
in
process
simulation
great
work
by
Dean,
so
that's
integrated
into
the
status
console
client
as
eagerly
mentioned.
We're
two
parallel
with
that
work,
preparing
sort
of
console
client
in
integrating
the
app,
which
would
then
allow
us
to
actually
use
they'd
sink
in
that
top
negotiation
as
well.
The
stars
jackpot
is
mostly
done
and
hoping,
hopefully
get
the
rest
of
it
done
roughly
this
week,
then,
as
part
of
the
swim
summit.
H
Sort
of
this
adaptive
note
concept
where
the
idea
is
that
you
can
change
mode
depending
on
on
what
cue
abilities
you
have
so,
for
example,
if
you
are
connected
to
Wi-Fi,
you
might
sort
of
be
able
to
use
more
data
and,
if
you're,
on
a
desktop
or,
if
you're
plugged
in
in
batteries.
Another
consideration
for
you,
then
you
might
be
able
to
do
more
things,
and
so
on
so
we're
working
on
that.
Instead
of
finalizing
requirements
in
different
phases,
it
will
sort
of
be
centered
initially
around
PSS,
most
likely
and
creating.
H
But
this
will
be
a
focus
in
queue,
free
going
forward
and
all
senses
of
his
a
like
this
home
team
is
of
aiming
to
have
a
production
grade
MVP
at
the
end
of
August.
So
that
means
that
things
like
chunks
or
song
will
hopefully
be
more
stable,
which
would
be
useful
for
a
lot
of
other
domains.
Out
of
of
communication
protocol
per
se.
H
Also
did
a
bit
of
sort
of
testing
in
a
sec,
Adria
and
I.
We
went
in
Zurich
after
some
summit
and
we
did
a
bit
of
testing
in
terms
of
trying
to
get
a
Nimbus
entrap.
It's
just
super
hacky,
but
it's
kind
of
working.
You
can
sort
of
connect
from
go-to
to
Nimbus
and
surf
used
to
whisper
protocol.
For
that
it's
it's
sort
of
very
hacking.
There's
lots
of
problems
with
it,
and
it's
not
the
integrated
instance
right
and
so
on.
But
it's
not
that
far
off
and
what
would
this
would
enable
us
to
do.
H
So
moving
forward,
we
gonna
sort
of
do
more
simulation
testing
for
immediacy,
which
was
sort
of
informed
to
what
extent
we
Sophie,
where
we
actually
turn
it
on
for
the
free
app
once
it's
integrated
and
yeah,
keep
working
on
the
source
form,
adaptive,
node,
stuff
and
so
on.
That's
it
for
me!
Thank
you.
Thanks.
A
After
all,
right
that
was
it
with
our
swarm
update.
So
now
we
have
two
questions
from
QA
that
was
submitted
from
the
town
hall
questions
group.
So
the
first
question
was
regarding
customed
and
f
teas,
oops,
sorry,
one
second,
okay.
The
question
was
now
that
custom
year
c
20
token
support
has
been
added
to
the
wallet.
Is
it
both
technically
and
feasibly
possible
to
add
custom
ERC,
seven
to
one
non-functional
token
support?
Does
anybody
have
I
answer
for
this
question.
F
That
it's
possible
to
show,
but
it's
possible,
to
show
only
balance
because
for
showing
details
for
this
talking,
for
example,
description
or
picture,
it's
may
be
complete
difficult
because,
for
example,
we
have
four
different
collectables
implemented
in
stalls
in
we
had
to
implement
each
collectible
in
different,
very
specific
way.
So
the
this
may
be
problem,
so
I
think
extension
may
help
here.
But
so
answer
is
yes,
we
can
add,
but
role
on
the
balance,
we
can
show
the
details
and
picture.
A
B
I
can
help
answer
that
on
behalf
of
that
discuss
red,
so
it
has
been
considered.
There's
a
threat
there.
So
the
moment
the
decision,
it's
a
stick
with
react,
native
in
order
for
Android,
iOS
and
desktop
clients
to
basically
have
feature
feature
parity
there's.
You
know,
there's
a
lot
of
talk
about.
Having
made
a
client
specifically-
and
maybe
that's
something
we
can
look
into
in
the
future
and
I
do
think
that
there
are
valid
points.
I,
don't
think
that
we've
done
enough
to
fully
extending
our.
B
H
H
What
we
want
to
do
is
which
sort
of
the
protocol
work
and
specification,
and
so
on
is
that
we
enabled
multiple
clients-
and
we
already
seen
this
through
some
sort
of
implementations
through
Nimbus
and
also
in
JavaScript
and
so
on,
and
we
want
to
see
some
more
implementations,
so
I
think
the
way
this
is
more
likely
to
happen.
Is
it's
not
going
to
be
sort
of
an
official,
a
client
at
least
initially?
H
But
if
someone
wants
to
go
ahead
and
do
this
and
they
have
sort
of
clear
rationale
for
it,
I
would
encourage
people
to
submit
this
sort
of
as
a
proposal
to
discuss,
Fred
and
stop
their
conversation
there.
And
then
maybe
we
can
use
to
hook
into
so
far
doubtful,
liquid
funding
and
so
on
at
some
point,
because
it's
sort
of
useful
to
have
multiple
clients
and
have
some
competition
in
terms
of
how
well
they
serve
our
users,
because
it's
supposed
to
be
a
such
an
open
network.
C
Point
out
what
scores
points
that,
with
moving
protocol
to
status,
go
a
bit
like
console,
client,
the
more
and
AP
eyes
are
like
settled
around
instead
of
stars,
go
and
yeah.
It's
essentially,
you
can
use
it
like
from
sweet
from
Catelyn,
is
it
from
flat
or
whatever
your
favorite?
So
if
you
want
an
alternative,
clientÃs
makes
this
work,
makes
it
easier
and
easier
to
just
make
an
alternative
status
client
in
whatever
technology
that
it's
useful.
A
Alright,
thanks
guys-
and
we
actually
have
one
more
question
that
was
submitted
from
JB
and
so
I'm,
going
to
quickly
jump
back
to
the
core
improvement
slide,
so
bear
with
me
one
second,
okay
and
JB's
question
was:
do
we
have
full
or
minimum
performance
expectation
for
start-up
and
sync
before
we
launch
v1
up?
That's
on
the
slide.
Sorry!
A
C
Yeah,
that's
the
lowest
part,
that's
a
target
time.
That's
mean
right
now,
for
scene
is
a
little
bit
in
flux
right
now,
as
I
told,
because
we
have
to
take
Network
conditions
into
account
and
stuff
like
this,
but
we
will
figure
out
some
threshold
for
that,
but
for
yeah,
for
reacting
to
the
tabs
and
for
switching
for
program
to
background
and
startup
time.
This
is
the
the
most
important
target
times
by
June
17
essentially,
and
these
are
different
devices.