►
From YouTube: Status Core Dev Call #29 - May 4, 2020
Description
The team catches up on the topics ranging from the progress for Status Quo library, Keycard, IPFS gateway for Sticker Pack, 3rd Party API usage, future chat features, Waku documentation, Roadmap plan Q2, and much more.
Catch up on the latest topics with the Status core dev contributors.
Agenda & Notes: https://notes.status.im/core-dev-call-29-notes
https://status.im/
A
C
C
E
F
D
D
I
want
to
present
you,
the
status-quo
library
we
which
will
contain
all
the
UI
components
of
status.
I
want
to
start
with
the
lot
most
important
thing:
projects,
structure,
I
decided
to
divide
it
in
four
main
parts.
First,
will
be
the
components
it
will
be
the
root
of
our
UI
component,
the
same
party
design
tokens
it
contains
all
the
color
spacing
typography
may
be.
We
will
include
over
parts
which
together
will
compose
into
how
UI
components
are
created
for
each
component.
We
will
create
a
create
previews.
D
A
preview
is
a
screen
which
will
show
how
to
how
to
use
a
component,
and
also
it
will
have
a
Cartesian
product
of
all
possible
purchase.
So
with
this
Cartesian
product
we
will
generate
our
possible
views.
Then
we
can
use
this
to
make
some
automated
testing
and
the
root
part
will
be
the
coordinate
space
which
will
have
all
the
public
components,
because
some
components
may
be
constructed
from
over
smaller.
D
All
the
components
which
will
have
a
more
stable
API,
also
in
the
routine,
will
contain
keep
all
the
library
of
wrappers
like
we
have
a
wrapper
for
Jack
native
animated
for
just
render
and
our
libraries
that
we
can
first
of
all
see-
and
you
can
see
here
a
preview
of
how
it
is
right
now
it
is-
has
three
folders
and
only
closed
of
files,
how
to
use
status
quo.
First
of
all,
we
need
to
use
components
only
for
from
core
namespace.
All
the
components
should
be
designed
in
the
layout
is
related
what
it
means.
D
It
means
that
a
component
should
not
anyhow
effect
over
companies
that
are
nearby,
for
example,
the
component
should
not
have
aligned
itself
why
this
is
bad,
because
if
we
have
a
component
which
we
say
that
should
align
itself
start,
if
we
contain
it
in
a
call
and
in
a
rope
in
two
different
places,
it
will
align
different
spaces.
So
if
you
want
11
to
start
tour
line,
for
example
on
the
top,
we
will
align
it
in
where
we
use
it.
D
We
can
add
custom,
tell
story
in
this
in
a
specific
place,
but
if
we
will
add
the
aligned
self
in,
for
example,
in
the
middle
it
will
in
different
places,
will
look
different.
So
this
is
this
can
show
us
some
cases
that
we
did
not
expect
and
it's
easier
it's
harder
to
test
them,
because
in
our
testing
of
our
environment,
look
we
cannot
use
all
the
possible
states
also.
D
We
should
avoid
external
margins,
because
when,
if
element
has
some
margin,
we
cannot
remove
it,
but
it's
easier
to
add
external
margin
by
wrapping
a
specific
component
in
fur
in
a
view
which
will
have
margin
or
padding
to
document
and
check
that
props
are
correct.
We
can.
We
will
use
closure
spec
for
now,
only
two
components
which
I
have
implemented
have
four
stick
and
I'm
just
testing
how
it
will
work.
D
D
D
On
the
day
when
we
will
decide
to
separate
it
as
a
separate
library,
it
will
be
harder
to
follow
up
all
the
dependencies
that
we
have
and
to
re-implement
them.
But
if
we
from
the
beginning
you'll
avoid
requiring
this
code
from
the
status,
it
will
be
either
in
future
to
maintain
it
also,
we
should
use
always
the
design
comes
from
design
system
and
namespaces,
because
having
coded
sizes
will
make
a
harder
to
follow
up
with
the
Sigma.
For
example,
designer
will
change
the
standard
lying
hate
for
a
font.
D
D
So
let
me
start
from
the
beginning:
it's
the
status
quo
up
is
auto-generated
and
it
is
generated
from
from
the
domain-specific
language.
In
the
end,
you
will
see
an
example
next
slide,
so
this
is
example
how
we
have
preview
for
text
on
the
top.
We
have
some
selects,
which
we
change,
and
it
shows
a
next
line
of
how
component
you
can
you
see
the
video.
D
E
E
E
D
D
D
D
E
D
D
You,
as
you
can
see,
we
have
a
lot
of
auto-generated
examples.
These
examples
can
be
used
for
testing
in
future.
Right
now,
the
testing
is
not
created,
but
because
we
generate
Cartesian
product
of
all
possible
States.
We
can
then
use
it
for
generating
automated
testing.
How
a
preview
that
we
seen
right
now
we've
generated
is
just
a
hash
map.
We
have
a
label.
D
D
Future
work
is
immigrate
all
the
components
that
we
have
right
now
in
status
and
to
separate
them
in
into
this
library
and
after
that,
to
implement
them.
This
is
a
list
of
the
next
component
that
we
want
to
migrate,
and
the
last
step
will
be
to
create
automated
testing
when
the
all
companies
will
be
ready.
This
is
an
example
of
how
automating
testing
blog.
We
will
have
screenshots
of
the,
for
example,
development
branch
and
the
screenshot
of
the
current
branch,
and
we
will
using
some
automated
tools
for
computer
vision.
D
We
can
check
the
differences
in
the
images,
so
we
can
see
that
in
this
image
the
font
weight
changed
from
both
to
regular,
and
we
can
see
this
red
squirrels,
which
which
shows
us
what
was
changed
on
the
screen
based
on
some
amount.
In
percent
percentage
of
error,
we
can
check
what
how
much
changed,
for
example,
because
at
the
time
on
phone
is
different.
This
is
a
really
small
change,
so
we
can
add
an
error
of
up
to
5%.
If
the
the
image
differs
by
only
5%,
it
is
a
truth
pest
test.
D
We
will
need
to
check
what
in
the
UI
was,
was
changed,
was
broken
and
to
change
and
fix
it
if
something
is
was
updated
and
it
expected
to
break
test,
because
the
new
test
new
state
is
correct
after
merge
into
the
develop
branch,
we
will
use
these
new
screenshots
as
base,
and
we
will
compare
all
the
new
changes
today.
These
new
screenshots,
that's
it
that
I
have
at
the
moment.
C
H
H
A
C
C
C
C
E
F
Well,
yes,
it
is
pinned
on
ours,
although
we
have
no
process
for
doing
this
consistently.
When
you
start
a
parks
are
added
and
so
on,
which
we
should
they
should
be
automatic,
which
wouldn't
be
difficult.
It's
just
that
yeah
another
finding
out
in
our
posture
that
I
in
for
a
custom
can
find
it.
I
should
hide
in
it,
but
we're
part
of
the
squirrel
sing
properly.
F
E
F
I
I
Like
one
yeah
one
question
that
one
only
I'm
not
sure
if
it
so,
my
question
is:
does
it
need
to
be
included
in
the
spec
I'm
wondering
when
the
methods
to
get
own
sticker
sticker
packs
is
used
like
whether
that's
like
I'll
install
as
soon
as
we
know
like
that,
the
user
has
a
given
address
or
when
the
user
goes
to
few
stickers
and
we
check
if
they
they
already
have
the
stickers?
That's.
G
C
Yeah,
so
the
the
idea
of
the
specs
is
so
that,
if
you
wanted
to,
if
you
wanted
to
implement
a
new,
a
new
status
client
that
you
would
have
different
enough
information
to
do
it
with
so
we're.
You
know
we're
in
in
this
regard,
we're
not
trying
to
we're
not
trying
to
change
the
world,
we're
just
trying
to
give
out
a
view
of
the
world
as
it
is
so
that
you
can
better
understand
that
if
you
want
to
implement
a
new
status,
client.
G
C
Correct
so
I
mean
obviously
that
we
have
we
do
have.
We
do
have
the
Wall
of
shame,
project
which
I'm
sure
Cory
will
talk
at
length
to
you
about
and
that's
something
we
need
to
address
slowly.
You
know
Akal
chip
away
at
those
things,
but
for
now
this
these
are
the
problems
that
we
have,
or
these
are
the
third
parties
that
we
use.
B
E
C
B
B
B
C
J
In
terms
of
I
mean
that
documented
I
mean
is
no
I
mean
that's
not
something
that
it's
like
implementation
completely
like
it.
There's
a
bit
of
I.
Think
these,
like
Berkshire
interactions,
I
mean,
is
unclear
exactly
what
we
needed
from
this
cuz.
The
tedium
already
provides
a
well-defined
API,
and
you
know
like
it's,
not
protocol
in
any
shape
or
form.
So
you
know
like
if
we
have
to
detail
the
algorithm
that
we
used
to
create
a
bar
chain.
A
J
A
J
A
Need
I
need,
I
need,
I,
guess,
ENS
user
names
is
a
good
example
of
what
the
blockchain
usage
backward
babes
like
we
rely
on
the
blockchain
for
this
specific
purpose
and
then
how
you
want
to
implement
it.
It's
fine,
but
this
is
the
kind
of
the
specification
of
like
how
our
username
maps
to
a
block
am
lookup
and
how
you
want
to
do
that.
Lookup
is
up
to
you.
Yeah.
J
I
need
an
onion
s,
I
mean
there
is
some
logic.
That's
the
project.
I
mean
we
always
defer
to
the
contracts
or
no
detail
in
the
working
of
the
contract,
because
it's
not
our
contract,
but
there
are
some
B's
that
is
our,
but
there's
a
wallet,
inflation,
trans
and
stuff.
That
is
like
some
images
that
we
fetch
the
instruction
from
material
like
this.
That's
them
the
extent
of
that
someone
needs
to
know.
Yeah.
A
F
That
sounds
to
me
more
like
an
optimization.
What
the
spec
says
is
here
is
the
authoritative
source
for
this
information.
This
call
is,
and
maybe
we
don't
mean
we
might
have
more
optimized
version,
but
this
is
how
you
can
do
it
as
a
starting
point,
because
it
should
work
right,
assuming
oh
I,
see
I'm
just
the
facts
of
the
gap.
I
J
Other
than
what's
career
with
a
curb,
but
if
you
I
mean
you
would
see
them,
you
know
we
would
have
the
actual
transaction,
even
if
it
is
pending
just
not
confirmed
right.
I
guess
you
know
I'm
not
I'm
very
familiar,
but
you
know
there
needs
to
be
a
record
which
we
can
fetch
from
the
auction,
and
so
we
would
be
able
to
identified
it
as
such
and.
I
J
Not
sure
this
is
the
best,
but
I
mean
we
need
to
explain
people
how
to
use
the
blockchain
here.
I
mean
it.
Just
doesn't
feel
like
these
things
that
you
know
that
guy
I
mean
everyone
has.
You
know
like
it's,
not
the
best
place.
I
will
refer
to
other
documentation,
investigate
I,
think
that
yeah
and
they
talk
it's.
H
I
C
E
C
A
Couldn't
that
be
just
implemented
through
that's
rough,
like
URL
unfurling,
most
the
time
gifts
are
linked.
J
E
J
E
J
C
J
A
A
C
A
C
C
A
C
I
Maybe
just
how
do
we
want
to
move
forward
with
these
specs
that
are
currently
in
PR,
because
I
imagine
you
don't
want
to
leave
them
open
for
too
long
and
things
change
in
the
meantime?
No
sorry.
I
C
B
Just
a
question
on
going
forwards
with
other
things
that
needs
specification
start
documentation
are
we
are
we
going
to
continue
to
make
a
concerted
effort
to
sort
of
address
the
things
that
currently
need
addressing
and
then
going
forward
every
time
a
new
feature
is
written.
Part
of
the
PR
needs
to
be
an
inclusion
of
Docs
or
specs
correct
okay,
so
that
would
be
part
of
the
review
process
going
forward.
It
yeah
I.
J
B
I
All
right
consider
it
a
reminder.
This
is
not
wildly
if
at
all
different
from
the
outcome
of
the
planning
session
and
what's
what
Rachel
posted
on
discuss,
but
okay
and
I
had
some
back
and
forth
to
see
how
this
would
fit
on
a
timeline
and
kind
of
like
what
what
user-facing
features
should
come
first
or
after
and
based
on
that.
What
we're
looking
at
for
the
coming
weeks
is
keycard
integration
and
notifications
on
androids
first,
so
that
would
be
for
to
come.
I
Let's
say:
they're
coming
three
weeks
roughly,
please
shout
if
there's
any
reason,
you
think
that
something,
that's
not
manageable
or
you
see
any
like
red
flag
staring.
This
is
very
much
in
flux,
then,
after
that
so
notifications
on
androids
keycard
integration
once
we
have
that
in
a
release
depending
on
when
that
would
be
referrals
on
androids
and
starter
pack
on
androids.
Those
are
very
much
tied
together
and
those
are
the
features
that
are
part
of
the
whole
growth
and
acquisition
strategy.
I
So
the
sooner
we
can
get
those
in
the
better
there's,
no
growth
to
be
expected
or
going
on
before
we
release
those
features.
So
those
are
very
important,
but
it
seems
like
we
need
a
bit
more
time
to
work
on
on
referrals.
We
still
have
an
issue
with
starter
pack
on
iOS,
so
p-card
integration,
notifications
on
androids,
followed
by
referrals
on
androids
and
starter
pack
on
Android,
then
after
dad's
and
kind
of
running
in
parallel,
and
you
see
if
I'm
not
missing
anything
in
chat
here.
I
Yes,
images
in
chat
as
part
of
that
as
well
so
now
applications
on
androids
key
card
integration,
followed
by
starter
pack,
referrals
and
images
in
chat.
So
those
are
the
two
buckets
and
then
the
third
bucket
that
could
go
out
as
kind
of
parrot
parrot
features
would
be
starter
pack
on
iOS.
Once
we
have
that
sorted
out
with
the
App
Store.
I
What
our
developer
status
is
there,
as
well
as
a
solution
for
notifications
on
iOS,
and
that
would
be
opt-in,
centralized
notifications,
I
believe
we
just
skipped
over
specifications
on
that,
because
we
really
don't
have
any
specifications
on
how
that
would
work.
Yet
so
I
can
imagine
that's
a
little
bit
up
in
the
air
what
the
approach
would
be,
but
basically,
referrals
and
starter
pack
are
important
aspects
of
growth
and
acquisition,
which
we
really
do
need
to
get
started
with
notifications,
whether
they
are
centralized
and
opt-in
or
decentralized,
are
critical
to
retention.
I
I
Some
already
came
out
of
the
latest
roadmap
planning
session
and
some
were
already
defined
before
hands
like
we
didn't
even
bring
them
along
in
the
roadmap
planning
session,
because
they
were
already
plans
for
just
not
released
yet
like
starter
packing
and
referrals.
Do
you
have
anything
to
add?
Unlike
anything,
yeah.
C
Just
just
a
touch
based
on
the
notifications.
We
we
know
for
a
fact
that,
for
example,
matrix
has
solved
this
at
the
decentralized
notifications
problem,
but
the
if
that
is
that
I,
don't
understand
how
and
and
before
before
kind
of
promising.
Anything
I
want
to
understand
how,
before
and
I
want
to
understand
how
undocumented
document,
how
that
would
look
for
status
potentially
before
before
kind
of
even
suggesting
anything,
I
mean
worst
case
scenario.
C
I
would
say
that
maybe
we
could
even
run
our
own
notification
service
centralized,
but
obviously
that
leaks
metadata,
whether
that's
something
that
that's
interesting
for
us
or
not,
is
is
really
really
up
for
debate
but
yeah.
Ideally,
ideally,
notifications
on
iOS
as
well
will
be
decentralized
and
we'll
look
at
look
at
how
matrix
did
it
and
learn
from
their
experience?
Is.
C
Oh
absolutely
I,
just
wanna
I,
just
wanna
I,
don't
want
to
just
start
discuss
post
with
like
does
anyone
have
any
ideas?
I
want
to
start
with
like
starting
a
discussion
there,
and
then
you
know
having
having
that
as
a
starting
point.
I
think
will
be
a
lot
more
productive
yeah.
So
give
me
today
to
kind
of
break
through
that
and
understand
how
that
works,
and
then
we'll
start.
The
discussion
there
yeah.
I
Okay,
that
sounds
good
yeah.
A
few
things
I
haven't
touched
on,
which
is
like
like
I,
would
say.
Two
more
phone
user
facing
features
that
also
came
out
of
the
roadmap
session,
so
mentions
ranks
pretty
high.
There
that's
I
mean
yeah.
Those
are
definitely
the
ones
that
we
would
want
to
plan
for,
but
all
after
referrals
in
starter
pack
and
notifications,
that's
what
it
comes
down
to
basically
staying
with
emoji
reactions,
a
kind
of
considering
emoji
reactions
and
S&T
reactions
separately
here,
because
SNT
reactions
do
require
signing
of
trends.
I
I
Also
happy
to
do
like
wait,
maybe
just
Forge
it
see.
This
is
the
only
remaining
agenda.
Item
may
be
to
click
close
off
the
call
we
could
do
like
a
roundtable
if
anyone
has
questions
or
comments
and
then
like
feel
free
to
raise
any
commentary
on
roadmap
planning
and
what
it
looks
like
now.
Does
that
make
sense
only
if
we
do
a
little.
I
C
C
B
A
I
find
it
very,
very
useful
for
helping
people
understand
what's
going
on
with
any
application
when
they
have
problems
as
well
as
figuring
out
where
potential
risks
lies,
and
things
like
that,
so
the
more
have
more
stuff.
We
do
like
this.
The
better
people
like
me
can
do
their
job.
So
please
keep
this
effort
up
on
an
ongoing
process.
C
I
Right,
yeah
I'm
the
right
opportunity.
If
not,
please,
please
send
the
cinema
search
on
this
court,
because
I
I'd
rather
know,
if
there's
anything,
you'd
rather
see
on
the
roadmap.
Then,
if
we
like,
if
we
have
to
deviate
because
at
some
points,
people
start
seeing
it
ultra-low
or
they
see
discuss
posts
and
they
like.
We
raise
expectations,
we're
not
tying
ourselves
to
two
dates
or
deadlines,
but
we
do
want
to
manage
expectations.
So
if
you
have
any
concerns,
just
send
a
message,
because
we
we
can
surely
move
things
around
as
well.