►
From YouTube: Status Devs Meeting
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
A
A
D
No
problem
sticker
market,
the
first
round
of
the
audit,
is
done.
We
have
a
bunch
of
issues
in
a
private
repository
which
are
low
bits
that
we're
going
through
and
finishing.
Ricardo
has
made
all
pull
requests
to
fix
all
issues,
but
one
of
them
is
going
to
be
a
little
more
complex,
so
I'm
going
through
that
and
reviewing
it
once.
D
We
feel
we're
done
with
all
the
changes
we'll
submitted
back
to
Trello
bits,
which
should
happen
sometime
this
week
and
they'll
just
go
over
once
again
to
make
sure
that
what
we've
done
is
sufficient
for
fixing
the
problem
that
they
initially
said.
So
that
should
all
be
done,
vote
something
quickly.
D
So
I
guess
I
can
I
can
I
get
to
go
into
that's
now.
Currently
we
I'd
be
in
the
Jakob,
had
a
talk
with
LimeWire
enough
lime
chain,
so
I
mine,
Mars
a
little
Peter
pew
client
lime
chain
to
discuss
the
state
of
it
was
in
and
they
have
basically
built
everything
out
with
Andy
and
now
it
needs
to
be
it
needs
to
undergo
tests.
We
were
waiting
and
I
like
this
kind
of
debt
approval
back-end
that
we
needed
to
do
that's
been
implemented.
D
G
G
Maybe
that's
one
mole
or
something
to
see
Britax
more
details
on
it
and
that's
also
related
to
the
doll,
because
it
would
be
a
way
to
distribute
funds
to
to
a
dollar
can
manage
that
that
they
could
manage
the
teller
and
for
I
mean,
is
related
also
to
the
dough
and
look
at
funding.
We
are
waiting
for
some
feedback,
but
we
we
just
started
to
do
some
preparations
also
for
the
teller
in
terms
of
road
map
and
security
audits,.
D
Yep
sticker
market
is
currently
being
wrapped
up
on
its
a
it's
right
up:
I'm
hoping
that
blog
to
go
up.
You
bought
this
wait.
If
we
took
a
little
bit
longer
on
it,
because
I
wanted
to
explain
some
of
the
key
differences
and
how
it
worked
versus
the
ENS
user
names,
because
the
model
is
quite
different,
so
yeah,
let
you
go
out
and
then
next
I'm
hoping
to
get
DAP
store
because
that'll
be
closer
to
releasing
finalized
and
I'll,
have
a
better
understanding
outwards.
A
A
We
have
this
markdown
each
person
in
our
clients
and
turns
out
it's
you
have
a
lot
of
formatting
New
York
messages
can
be
very
slow.
I
made
experimenting
and
replacing
that
enough
with
the
native
rendering
of
a
native
person
from
this
markdown
each
syntax,
and
it
looks
like
that.
It's
it
looks
very
promising
so
far,
so
for
one
extreme
message
where
every
character
is
formatted
separately
and
it
has
like
around
five
thousand
characters
on
the
old
version
on
on
at
least
my
simulations.
A
They
release
built
to
click
around
20
seconds,
to
render
the
chat
because
photos
law
and
with
this
native
frontier
it
takes
around
around
a
second
or
something
like
this.
So
it's
way
faster.
So
it
looks
like
I'll
continue
with
this
and
nobody
ever
this
opening
the
chats
even
but
happy
formatting,
Quan
da,
that
have
a
problem
anymore
and
I.
A
Guess
one
more
thing
that
we
do
is
we
are
getting
closer
and
closer
to
making
reproducible
builds
for
Android,
so
we
can
submit
it
to
F,
draw
it
or
other
places
where
it's
necessary
and
then
side
load
the
application
in
a
more
secure
way
and
basically
Pedro
is
getting
closer
closer.
It's
always
like
he
I
guess
he
passed
the
face
when
he
was
working
with,
like
gotta
yarn
to
essentially
build
the
JavaScript
enclosure
script,
and
now
it's
on
the
face
where
it's
actually
building
their
Android
release,
which
is
not
producing
reproducible
results.
A
So
far
so
buddy
I'd
say
at
least
we
are
not
staying
on
one
place,
we're
just
moving
towards
the
truck
that
looks
pretty
good
and
what
else
one
more
thing
but
I
guess
it's
it's
on
the
level
between
the
protocol
and
core
improvements.
Is
that
that
unprepared
first
PR
that's
useless
what
we
have
the
technology
that
we
use
in
the
console
coil,
you
actually
use
it
as
a
back-end
to
our
status
react.
So
we
can
parse
protocol
on
the
go
side.
It's
a
first
off,
but
this
is
relatively
me.
A
still.
A
F
Okay,
cool,
so
I've
been
continued
to
work
to
integrate
data
sink
into
the
status
console
client.
There
were
some
issues
with
whisper
depth
and
so
on.
We
also
been
doing
some
initial
very
basic
simulations
for
that
to
sort
of
see
the
latency
and
bandwidth
overhead
if
there
is
since
we
don't
currently
have
swarm
and
we
sort
still
have
mail
service
sort
of
deal
with
most
of
fun
devices,
it's
a
bit
of
an
issue
in
terms
of
latency
and
bandwidth.
So
the
next
text
we
want
to
test.
F
We
want
to
do
dairies
who
want
to
expose
the
sort
of
simulation
parameters
we
have
in
minimal
viable
data's
Inc,
which
deals
with
things
like
shown.
So
with
the
fact
that
I
client
is
aligned
90%
of
the
time
and
sort
of
this
bouncing
back
and
forth
of
messages,
and
we
want
to
integrate,
expose
those
tests
instead,
console
client,
because
that
way
we
can
see
how
things
actually
improve.
F
What
else
Data,
Sync
general
stuff
going
on
stats,
console,
client
and
topic
position,
and
so
on
we've
been
working
with
over,
did
sync
right,
so
we
also
have
some
amendments
distance
off
the
minimal,
viable
version
which
is
about
using
swarm
as
they
remote
log.
So
you
surf
replicator
on
top
of
that
and
use
feeds
and
so
on.
That,
however,
has
a
dependency
on
actually
having
a
swamp
like
thing,
which
is
something
that
we
started:
collaborating
collaborating
with
with
swamp
team,
Louis
and
I.
F
We've
been
spending
less
a
few
weeks,
sort
of
speaking
out
to
the
requirements
in
the
path
towards
that,
and
we
want
to
have
solid
specifications
for
pieces
and
for
light
mode
and
then
also
for
the
pieces,
heads
some
sort
protocol
kind
of
thing.
So
we
have
country
for
in
terms
of
the
planning.
Roughly
the
kind
of
pieces
have
to
be
done
and
so
on,
and
then
it's
going
to
be
a
priority
for
Peugeot
Dean
for
July
August
and
September
Tech's
release
of
implement
this
kind
of
swarm,
adaptive
notes
and
so
on.
F
I
think
that's
it
we're
also
working
on
some
proposals
for
DEFCON
as
well
yeah
that
all
we
also
working
on.
We
can
begin
on
this
weekly
in
a
so
revisit
and
actually
having
some
kind
of
roughly
solid
draft
of
our
current
specifications,
because
we
kind
of
left
them
hanging
after
a
bit.
So
we
want
a
sort
of
document
or
current
protocol
as
best
as
we
can,
and
this
is
a
roughly
reflect
version
one.
So
it's
something
stable
that
we
can
point
to
and
client
implementations
can
still
rely
on.
That's
it
for
me.
Thank
you.
E
I'll
give
it
up
databases
right.
So
at
the
moment
we
are
trying
to
rejigger
the
v1
Lorne
scope,
just
purely
because
there's
so
much.
We
need
to
do
and
I
think
the
timelines
for
us
to
hit
end
up
chord
is
probably
not
realistic.
So
that's
the
current
priority
is
to
make
is
to
find
out
what
a
realistic
deadline
is.
Multi-Account
work
is
pretty
much
the
beast.
E
That's
not
holding
up
everything
else,
but
it's
probably
work
that
should
be
done
first
before
we
tackle
the
rest,
so
multicam
is
a
priority
to
complete,
and
then
we
can
finish
off
the
rest
of
the
features
and
yeah
bugs
for
for
v1
I,
think
I'm
yeah.
There
was
also
an
email
that
we're
not
regarding
putting
in
effort
for
the
amount
of
work
needed
that
will
also
help
timelines.
E
A
E
It
depends
on
who
right
now,
multi
account
both
of
them
need
to
get
completed.
So
I
would
say
that
those
are
the
two.
The
main
reason
why
multi
capably
should
get
completed
first
is
because
it's
blocking
a
lot
of
other
features,
for
example
tribute
to
talk,
and
basically
anything
else
that
requires
anything
account
related
is
blocked
on
multicam
work,
so
I
would
say
multicam,
it's
probably
slightly
more
important,
but
they
both
need
to
get
done
so
yeah.
H
I
think
it's
important,
because
it's
if
we
do
this
after
we
implement
the
life
force
input
to
boot,
to
talk
we
out
this
migration
work
that
will
probably
costs
a
lot
of
guests.
So
it's
important
to
do
before
so
the
users
are
already
signing
in
into
whatever
is
their
application.
We
are
using
into
these
separate
accounts.
A
A
G
G
D
G
So
next
step
is
implementing
the
water
count,
support
so
generating
account
or
import
watch
on
the
account.
Also,
we
have
a
pull
request
for
first
step
for
important,
so
we
have
the
first
part
for
first
screens
for
unburden,
and
currently
we
are
working
on
pin
code
and
yes,
so
working
progress
on
the
pin
code.
We
tally
is
working
and
for
invest
names.
We
we
also
I,
think
where
it's
mostly
testing
part
is
mostly
finished,
so
we
are
ready
to
merge
the
first
part
of
in.
G
I
I
We
are
we
plan
to
have
this
week,
some
discussions
with
maked
au
and
au
o
mais
good
to
progress
for
on
the
payment
networks
for
point-of-sales
to
be
used
with
key
card,
and
we
want
to
do
this
together
with
a
teller
team,
since
they
are
also
working
on
that
and
that's
it
for
key
card.
The
rest
is
about
Mattie
account
and
I.
Guess
we'll
discuss
it
after
the
swamp
run,
table.
H
Now
it's
just
wait
for
for
them
to
up
these
changes,
and
then
we
have
this
new
smart
contract
for
the
sticker
market
that
is
properly
out.
Is
it
and
you
have
out
the
property
architecture,
a
proper
spec,
spec
yeah?
That's
it
Oh
in
regarding
topic,
democracy
I'm,
also
working
on
it,
so
I'm
doing
progress
on
how
you
the
ABI,
because
when
you
create
proposal
you
you
don't
want
the
user
to
enter
that
and
stuff.
You
want
like
the
problem
ABI
of
this
much
contract.
H
H
I
G
I
Okay,
so
yeah,
so
a
summary
of
the
situation
with
regards
to
multi-account,
since
we
had
several
discussion
in
the
past
weeks
about
that,
first
I
just
wanted
to
give
one
once
the
context
for
everyone.
Why
we're
doing
that
yeah
today
in
beta
within
the
the
status,
we
only
have
a
one
key
pair.
Basically,
so
it's
the
big
44
standard
one
and
forty-four
60000,
we
use
it
for
whisper
and
we
use
it
invalid
type
of
functions
to
send
and
receive
fans.
I
So
that's
pretty
simple
and
in
the
view
one
what's
different
is
that
we're
going
to
separate
the
the
key
pair
this
key
pair
that
we
used
to
send
and
receive
fund
the
big
44
index,
0
1
from
the
key
pair
used
for
messaging,
which
we
call
the
whisper
key
and
for
the
whisper
key
we're
going
to
use
em,
slash,
44,
star,
60,
/,
1581
staff
zeros
a
zero,
and
why?
What
is
the
fundamental
reason?
Why
we
do
that?
Because
in
this
v1
we
want
to
allow
the
use
of
keycard
with
status?
I
I
We
would
have
to
tap
the
card
to
the
phone,
which
would
be
a
pretty
bad
experience,
so
that's
before,
and
the
other
reason
is
that
we
want
to
lay
the
groundwork
to
have
a
more
flexible
way
to
manage
keys
within
status.
We
see
it's
not
easy.
It's
raising
a
lot
of
questions,
but
it's
better
to
have
all
this
work
done
now
than
later
on,
once
v1
will
be
launched
and
the
other
thing
we
want
to
12
in
v1.
I
On
top
of
this
separation
of
key
pair,
is
we
want
the
user
to
be
able
to
add
more
accounts
so
that
you
can
manage
all
these
all
these
assets?
The
way
he
sees
fit
so
yeah?
So
these
are.
This
is
really
what
we
are
doing
now.
What's
the
status,
we
can
see
things
in
separated
in
two
things.
First,
there
is
some
how
the
core
of
multi
account,
which
is
how
it
impacts
the
account
view,
a
next
program
review
and
the
way
to
add
accounts.
I
The
Explorer
view
it's
a
new
layer
that
we
don't
have
now.
Instead,
us
which
sits
on
top
of
the
account
level
that
shows
the
list
of
all
these
accounts
and
which
gives
a
summary
of
all
these
accounts.
Typically,
what
are
the
assets?
What
is
the
sum
of
all
assets,
the
value?
Sorry,
the
sum
of
the
value
of
these
assets
and
the
main
assets
are
there.
So
that's
a
new
thing
for
status
app,
we
didn't
need
an
updated
account
view
and
we
need
to
add
accounts
with
the
Explorer.
I
So
that's
really
the
core
new
things
we
are
adding
to
to
the
app
the
other
thing
and
I'll
come
to
that
are
what
are
the
impacts
of
having
several
key
pairs
now
in
the
app
and
they
can
be
on
several
stuff,
but
just
to
finish
on
that,
what
we're
trying
to
do
is
we
are
trying
to
progress
as
secondary
as
possible,
both
in
the
design
and
implementation,
so
from
main
priority
to
lowest
priority.
So
we
need
this.
I
We
need
an
updated
outcome
view
we
need
a
way
to
add
account
very
simply
and
the
most
simplest
form
of
adding
an
account
is
without
the
user
having
to
input
any
type
of
derivation
path
or
private.
Key
or
public
key
just
the
user
is
creating
a
new
account
on
the
witch
which
will
sit
on
the
next
index
available
on
the
bit
44
path,
then
we
need
to
add
watch
addresses
we
need
to
add
account
from
private
keys
and
then
we
need
to
add
accounts
from
seed.
I
So
so
the
the
five
first
point
here
and
will
work
I
mean,
will
we
our
focus,
is
to
get
into
the
very
detail
of
all
this
stuff
to
have
them
implemented,
and
then
we
also
add
add
account
from
a
hidden
derivation,
which
is
a
more
advanced
use
case
from
an
implementation
standpoint.
Android
just
said
that
he
has
already
started
work
on
explore.
Everyone
I
can
view
and
submitted
a
cure
last
week.
I
So
that's
the
current
situation
with
this
core
multi-account
work,
but
now,
interestingly-
and
this
is
something
we
spent
a
lot
of
time
discussing-
is-
is
really
checking
all
the
different
impacts
that
now
that
we
have
several
t
pair
with.
Instead
us
everywhere,
we
use
a
key
pair
to
make
sure
which
is
the
keeper
we
use.
I
So
that's
the
key
principle
that
guides
all
our
decision-making
currently,
so
the
current
agreements
we
have
and
that
we
will
actually
we
want
to
submit
that
or
so
to
Jared
with
out
here,
because
we
want
Mick
to
add
some
gauging
cross
process,
12
or
destroy
Caesar
confirmed,
but
the
team
is
pretty
much
aligned
on
a
couple
of
things.
First,
transaction
from
chato
profile
view:
when
a
is
going
to
send
assets
to
B,
then
both
on
a
and
B
side
we're
going
to
use
the
main
accounts
of
a
and
B.
I
We
are
not
going
to
use
a
whisper
address
coming
from
the
whisper
key
on
any
side
and
to
do
that
they
must
add
a
twist
contacts,
so
the
ad,
so
that
B
gives
to
provides
who
a
is
a
main
account
address.
So
that's
first
very
important
thing.
Then
we're
going
to
use
the
main
account
to
sign
all
that
transactions
to
register
from
for
the
ENS
name
and
also
to
receive
tributes
in
tribute
to
talk.
So
this
has
impacts
Constance
entry
to
talk.
I
This
has
impacts
and
should
be
to
talk
that
have
been
taken
into
account
on
the
the
things
that
needs
to
be
worked
on
in
tribute
to
talk,
or
so
we've
settled
on
the
fact
that
we're
not
gonna
provide
flexibility
to
the
user
to
change
the
main
account
I
mean
the
one
that's
used
for
all
new
stuff.
For
this
v1.
We
make
things
simple:
it's
the
this
first
them
in
the
main
account
with
the
index
zero
when
the
one
that
you
use
a
got.
I
I
We
also
discussed
the
case
where
the
user
would
get
some
assets
on
his
whisper
I
mean
the
new
whisper
address
coming
from
his
key.
So
if
you
see
what
I'm,
what
I'm
alighting,
if
someone
is
sending
me
as
sets
there,
we
had
several
discussions,
see
hey
what
are
we
going
to
do
there,
and
our
conclusion
is
also
to
me
to
make
that
very
simple.
I
So
this
is
what
we're
in
agreement
with.
What
still
in
discussion
is
the
migration
meaning
migration
from
our
current
beta
up
to
the
v1,
because
the
user
I
mean
the
cases
if
someone
is
using
the
beta
app
and
wants
to
chat
with
someone
that
used
a
new
app
because
they've
been
in
contact
in
the
past.
The
person
with
the
new
app
has
got
a
new
whisper
kid.
I
So
this
person
with
the
new
app,
is
going
to
need
to
listen
to
whisper
messaging
incoming
on
the
whisper
key
from
the
older
path
and
then
answer
either
from
the
old
or
the
new
whisper
key.
So
there's
discussion
about
this
migration
and
we're
going
to
come
back
to
that
and
the
other
big
subject
is
about
all
the
stuff
that
we
still
have
to
do
before.
I
V1
I
mean
finishing
the
implementation
of
the
core
part
of
material
counts
and
all
the
impacts
like
on
tribute
to
talk,
I
mean
and
all
the
side
thing
we
need
this
in
v1
and
so
there's
a
v1
Pro
ization
effort
led
by
Rachel
to
to
see
what's
the
planning
for
that.
So
that's
what
the
main
things
that
were
discussing.
I
H
Have
a
question
about
this:
I
see
that
you
will
explain
the
relationship
between
the
whisper
key
and
the
wallet
account
and
in
the
relationship
between
ENS
usernames.
That
is
a
adapt
from
stages.
But
it's
not
clear
for
me
how
it?
What
is
the
relationship
with
other?
That's
because
the
stages
it
has
this
that
browser,
and
so
the
user
would
be
able
select
what
is
the
account
or
which
will
be
generated
when
account
for
their
poor
on
what,
for.
I
The
en
si
letter
Rachel
comment
but
relief
for
dads
from
the
browser,
because
for
ENS
now
it's
a
native
to
native
development
for
taps
from
the
browser
at
this
stage
in
v1.
We
really
want
to
make
things
simple
and
use
toward
you
always
use
this
key
here.
I
mean
you
know
the
main
key
for
apps,
okay,.
H
I
Then,
probably
the
in
future
iteration
we
could
have
a
step
approach.
Maybe
in
the
first
step
we
could,
you
know,
define
a
custom
main
accounts.
If
the
user
wants
to
change
the
key,
that's
used
for
all
this
stuff,
you
could
customize
his
main
account
and
even
further
I
mean
without
I,
mean
further
down
the
path.
We
didn't
come
back
to
these
ideas
of
our
of
adding
a
unique
that
keys
and
so
on,
but
that's
not
for
now
for
sure.
C
B
Yeah
sure
so
there
are
mainly
three
things
that
we
are
going
to
change.
So
the
first
thing
is
that
we're
moving
to
use
our
PC
methods
also
for
accounts,
so
that
it
would
be
easier
for
statistics
to
interact
with
the
new
API
without
changing
and
adding
more
native
code
for
each
platform
and
and
then
one
big
thing
that
we're
changing
in
go
is
that,
instead
of
creating
a
new
key
deriving,
the
so
creating
a
new
master
key
deriving
the
one
that
we
want
to
save
and
save
it.
So
removing
it's
basically
quickly
from
memory.
B
We
are
going
to
keep
it
in
memory
for
more
time,
because
we
we
want
to
allow
status,
react
to
basically
create
a
new
master
key
and
then
the
rides
different
from
different
paths.
Different
addresses,
so
that
the
user
can
check
the
address
and
check
the
balances
and
choose
the
one
that
they
want
to
use.
And
then
cities
react
can
say.
Okay,
I
want
to
save
this
set
of
keys
and
then
remove
the
master
key
from
memory.
B
And
the
last
thing
is
that
so
we
show
all
the
keys
now
are
saved
in
key
store
files
which
are
like
the
default
for
gas
is
real
wrapping
up
anything
go
and
we
extended
the
format
of
this
file
to
have
a
new
field,
so
the
default
one
has
a
key
field
where
the
private
keys-
and
we
added
so
in
the
past.
So
this
was
always
always
their
extended
key,
which
is
actually
not
the
extended
key
of
the
same
key.
B
But
it's
like
the
like
the
next
key,
because
in
the
in
the
past
we
wanted
to
use
the
index
one
to
derive
sub-accounts.
So,
first
of
all,
we
wanted
to
use
the
parent
key
of
the
b44
first
address
to
derive
new
keys
so
that
you
can
have
like
the
normal
standard
list
of
addresses
that
you
can
get
from
any
IP
44
compatible
wallet
so,
for
example,
in
metal,
mask
and
and
then
yeah.
B
So
we
want
to
save
this,
and,
and
actually
we
want
to
save
the
parent
in
a
different
ISO
file,
so
that
status
react
knows
that
every
time
one
one
key
is
saved,
it
has
an
extended
key
and
from
that
one
can
can
ask
like
to
load
it
unlock
it
and
derive
other
other
side
keys.
So
this
allows
in
the
next
steps
to
basically
do
everything
we
can
do
for
importing
keys
and
deriving
any
custom
path
and
anything.
B
H
B
So
the
so
the
API
is
already
I
mean
it
will
allow
to
derive
any
key
and
I
think
in
the
first
release.
We
want
to
save
by
default,
the
VIP,
44
first
key
and
then
the
parent,
so
that
you
already
you
can
already
derive
the
next
one
and
the
next
one
I
mean
the
full
list
of
this
without
introducing
again
the
mnemonic
phrase.
I
We
want
also
to
have
a
possibility
to
add
any
private
key
key
pair
so
outside
of
the
tree
either.
If
it's,
we
are
either
from
a
historic
on
fire
or
from
a
rope,
private
key,
adding
watch
address,
but
here
there's
nothing
involved
in
go
up
nor
any
private
key
and
then
a
passivity
to
input,
a
seat
phrase
and
then
to
the
derivation
path.
I
mean
this
diagram
can
help.
You
understand
the
full
picture.
A
A
B
H
D
H
So
speaking,
on
security
storage,
that
remembers
me
off
key
card,
and
maybe
it's
too
early
to
talk
about
the
integration
and
key
card
on
on
this
multi
account
but
seems
like.
If
you
tap
the
the
maybe
they
the
car,
then
then
it
would
allow
the
wallet,
but
they
said,
would
you
don't
need
the
clicky
I
think.
D
I
D
D
We
should
be
able
to
figure
out
how
we
store
use
and
maintain
keys
and
isolate
that
out
in
such
a
way
that
if
it's
ever
like
it
shouldn't
be
touched
because
status
go
will
be
touched.
So
that
means
that,
like
the
you
know,
the
hashes
will
change
of
whatever
gets
built
so
on
and
so
forth,
but
parts
of
it
won't
be,
which
means
that
the
audit
will
still
be
valid
for
those
parts.
So
what
I
need
to
do
is
figure
out
one.
D
What
parts
can
I
focus
Trello
bits
on,
so
that
the
audit
isn't
obsolete
after
a
month
and
then
two?
How
do
we
flag
the
rest
of
the
system?
So
that,
if
that
is
touched,
someone's
notified
particularly
me
that
it's
changing
and
I
can
evaluate
whether
or
not
it's
it's
obsoleting
the
the
audit.
So
it
makes
sense.
D
It's
like
there
needs
to
be
some
way
in
which
we
can
isolate
these
things
appropriately
and
then,
and
then
we
know
what
we've
had
audited
and
what
it
means
to
ops
that
like
make
it
obsolete
and
on
that
I'm
not
suggesting
to
go
through
this
now,
but
now
would
be
a
good
time
to
figure
out
who
should
be
on
that
call.
I.
D
A
A
D
F
We
would
isolate
on
protocol
side
when
isolated
things
like
data
sync
versus
like
double
ratchet,
and
these
types
of
things
I
want
to
make
sure
that
double
Retta
stuff.
We
don't
mess
around
and
refactor
that
if
we
do
things
like
papa,
crocheting
or
dating
stuff,
so
we
keep
them
mainly
variants
and
that
sort
of
I
said
in
a
module.
Ideally.
A
A
D
A
H
Maybe
would
be
interesting
to
instead
of
like
making
this
change
in
stages
goal,
but
making
it
in
in
get
so
like
it's
harder
to
have
some
critical
changes.
My
idea
would
be
to
make
up
this
implementation
of
because
they
they
have
a
build
for
Android
in
gas,
so
maybe
that
dude
for
Android,
for
example,
would
implement
the
key
star
using
these
features
from
Android.
If
they
are
available.
D
A
We
should
have
stream
it's
for
sure,
but
first
then
the
first,
because
we
had
to
migrate
to
go
mobile
instead
of
whatever
we
used
to
use
the
same,
build
system
that
guess
what
was
using
to
build
multiple
builds,
and
it
wasn't
you
that
really
integrate
with
it's
only
integrates
from
gear
to
the
system,
and
you
can't
do
anything
from
system
to
guess
in
that
way
how
they
do
this
right
now
and
go
mobile
makes
it
to
way.
So
we
can
inject
keychain
into
yes
right
now
in
our
build
yeah
yeah.
A
H
D
C
C
C
So
we've
also
done
a
little
bit
of
a
survey
of
the
community
that
Hester
has
worked
on
to
see
what
people's
sentiment
is
towards
breaking
change
and
it's
it's
pretty
positive.
So
far,
people
seem
to
be
okay
with
it.
But
if
anybody
has
strong
opinions
on
that,
then
let's
continue
a
conversation
about
it
offline.
You
can
hang
in
status
core
about
it.
C
If
you
want
to
talk
about
it,
there's
one
other
sub
point
that
we
discussed
very
briefly
in
status
and
I
want
to
make
sure
on
this
call
that
nobody
has
pushed
back
on
and
that's
the
idea
of
clearing
users
database
when
the
grade
two
multi-account.
So
therefore,
basically
like
a
user
on
multi
account
would
lose
all
of
their
messages
and
contacts
as
well,
and
it
sounded
like
we
had
support
for
that
in
status
core
last
week.
But
Andre
could
did
you
that
a
little
better.
G
G
G
Legacy
in
release-
and
maybe
it
had
a
notes
for
fit
for
to
start
with
start
schemes
from
scratch,
but
in
this
case
yes,
we
need
to
clear
de
and
also-
and
also
we
have
two
things
more
first
one
is
we
move
all
our
messages
to
status
go
so
we
need
to
somehow
we
create
these
messages
from
realm
to
status
quo
and
also
yes,
multi-account
support.
We
need
somehow
migrate
old
accounts
to
to
multi-account
to
mute
account
support.
So
maybe
we
could
consider
this
with
like
to.
I
F
So
I
just
want
to
go
back
to
the
first
comparable
package
comedy
stuff
like
this
is
a
good
place
to
have
a
discussion.
I
I
would
have
respect
against
that
I'm
trying
to
understand,
because
when
we
had
this
discussion
a
few
times
I'm
back
with
computer
in
general,
and
why
it's
useful
in
terms
of
sort
of
coerciveness
creating
a
culture
on
it
around
it,
sort
of
generally
being
good
news
experiences
on
I'm
trying
to
understand
like
what
what
is
stopping
us
from
having
some
fun
backwards.
Compatibility
I
was
the
main
blocker
that
people
see
the.
C
Roi
doesn't
seem
to
be
high
enough
other
than
in
terms
of
principles
like
and
I
understand,
like
the
ethos
around
supporting
backwards
compatibility,
but
like
going
from
beta
to
be
one
when
you're
under
2k
users
and
it's
gonna
cost
I'm,
not
quite
sure
how
long
it
would
take.
But
I
understand
that
it
would
be
a
high
like
a
high
effort
thing
to
build.
F
A
Is
that
listening
to
the
old
whisper
idea,
as
we
probably
discuss
it
before,
but
from
the
security
standpoint,
then
it
defeats
the
purpose
of
multi
account
because
to
listen
to
the
whisper?
Do
you
still
need
told
key
in
the
memory
and
diffused
it
hard?
For
instance,
they
get
to
top
every
time
to
decrypt
every
message
which
is
it's
inconvenient,
so
you
have
the
key
in
two
places
at
once.
So
it's
from
that
standpoint
like
this
migration
strategy,
yeah,
not
sure
how
good
is
it?
A
F
A
F
A
F
A
F
F
An
occultist
and
it's
very
stable
and
stable
and
open
sort
of
base
that
people
can
sort
of
interact
with
right
and
and
giving
you
sister
option.
At
least
it's
you
living
the
power
in
their
hands
and
they
can
choose
whether
it
went
up
here
or
not,
and
we
can
obviously
encourage
people
to
upgrade.
But
I
really
don't
see
why
we
would
just
throw
that
away,
especially
once
this
is
a
great
learning
opportunity
for
us
and
learning
how
to
do
these
things,
because
it's
not
gonna
come
up
several
times
over
the
next
few
years,
because.
A
C
C
A
F
So
so,
if
I
have
an
account
and
I
haven't
used
it
in
a
long
time
and
then
I
like
what
full
the
path
look
like
if
I
just
say,
I'm
not
rig
I'm,
a
regular
firm,
usurp,
I,
don't
use
tabs
because
it's
not
good
enough
and
then
we
reach
for
someone
and
then
I'm
gonna
recover
my
account
where
I
have
my
cryptic
eaters
and
what
not
exactly?
What
does
the
path
look
like.
F
F
J
Oscar
we
we
still
need
to
detail
what
that
leg.
If,
depending
on
the
decision
we
take
on
the
kind
of
migration,
we
would
look
for,
we
still
have
to
work
on.
How
do
we
communicate
that
best,
accusers
and
I
agree?
It
should
ideally
be
some
sort
of
opting,
so
it's
not
a
forceful,
like
maybe
upgrading,
yeah
I,
think
just
it
needs
to
be
detailed,
more
I.
Agree
to
that.
So
the.
A
Can
also
solve
the
issue
with,
let's
say,
C
phrase:
by
making
this
C
face
versions
and
maybe
I'm
still
compatible,
but
you
can
add
some
specific
it's
there.
Then
it's
a
new
account.
If
it's
not
there,
that's
an
old
account
and
you
recover
the
old
one
is
still
there
annoying
message
that,
oh
well,
you
use
an
account,
make
sure
that
your
private
data
or
so
private
data,
but
your
transaction
might
might
leak
with
it
from
your
IT
and
stuff
like
that.
So
and
we
should
like
I'm
still
not
exactly.
A
J
A
A
C
Sounds
like
the
the
proposal
that
we
had
in
the
doc
I
shared
is
not
the
best
option
for
Migration
anyway.
The
option
that
you
proposed
igor
sounds
better,
so
maybe
what
we
can
do
is
I,
don't
know
who
should
be
involved
in
that
conversation,
but
definitely
you
can
help
us
like
bring
spec
out
that
work
a
little
bit.
C
So
we
can
look
at
like
the
time
estimate
because
again,
like
we're
trying
to
be
conservative
and
and
in
our
development
time,
but
it
just
to
me
you
like
what
you're
doing
thing
is
the
context
when
you're
upgrading
from
beta
it's
expected
that
there
could
be
significant
changes
and
again
like
we
we've
surveyed
the
community
and
we've
had
some
response.
That
indicates
that
the
community
would
not
be
upset
by
this
kind
of
breaking
change.
At
this
point,
development
I,
don't.
F
Personally,
in
terms
of
multi-county
partners
on
I
would
rather
see
that
the
key
structures
of
like
that's
a
set
it
does
respect
out
and
so
on.
But
then,
instead
of
having
spending
a
lot
of
time
on
fixing
up,
like
things
like
tribute
to
talk
and
so
on,
making
sure
there's
a
smooth
upgrade
path
because,
but
if
you
don't
break
things,
if
you
leave
things
running
and
then
you
ensure
that
there's
a
path
to
move
to
something
better,
then
you
don't
need
to
change
all
the
things.
F
You
just
need
to
have
this
new
sort
of
structure
and
then
you
can
sort
of
slowly
move
things
that
you
can
nudge.
People
of
Oh
move
your
tribute
up
to
this
sort
of
thing
or
whatever,
or
stop
listening
to
this
whisper
topic,
because
you
have
synced
devices
and
so
on.
I
cannot
short,
that's
always
doable,
but
that
would
be
my
preference
as
opposed
to
changing
stuff,
just
taking
something
and
then
adding
to
it
and
then
finding
a
smooth
up
in
that.
C
F
Changing
things
like
everybody,
we
had
this
discussion
a
lot
of
times
and
it
often
comes
back
to
this
that
if
you
introduce
new
behavior
it
shouldn't.
Ideally
it
shouldn't
change
things.
It's
something
you're,
adding
stuff,
you're
accreting
stuff
to
the
knobs
as
possible,
and
then
you
can
find
a
path
for
so
slowly
moving
to
other
things,
and
that
I
mean
it.
If
it's
a
general
principle,
then
it's
not
just
yeah
like
it's
a
general
code
architecture
principle:
how
do
you?
How
do
you
think
about
code
and
what
you,
whatever
you
for
watching.
E
G
D
I
would
argue
that
I
like
Oscars
approach,
but
only
after
v1,
if
we
ever
have
a
chance
to
break
compatibility
and
start
fresh
with
this
is
the
base
in
which
we
do
these
things.
It's
going
to
be
now
when
we're
in
the
appropriate
form
of
an
application
where
you
can
do
that,
and
users
expect
it,
because,
at
the
end
of
the
day,
I'm
gonna
write
a
discussed
post
that
outlines
how
little
users
we
actually
have
based
on
the
metrics.
We
can
take
it's
not
a
lot
of
people,
it's
mostly
just
us,
and
our
ambassadors
just.
G
D
Second,
we
have
a
lot
of
app
downloads.
A
lot
of
people
have
the
application,
and
so
when
we
release
v1
you're
right,
they're
gonna
come
to
a
new
application,
but
there's
no
other
chance
in
the
future.
Where
we're
going
to
be
able
to
say
we're
starting
fresh.
This
is
the
the
way
we
wanted
to
build.
The
app
in
the
first
place
welcome
the
status
versus
the
the
principle
you're
trying
to
uphold
now.
F
F
It's
just
gonna
get
harder.
It's
as
much
a
cultural
thing
and
I
think
it's
much
easy
to
just
see
the
side
effects
that
are
negative,
because
they're
obviously
obviously
is
pain
in
the
ass
to
maintain
backwards,
compatibility
backers
compared
with
it,
and
it
takes
more
development
time
as
it's
easier
from
scratch
all
the
time.
F
But
but
the
positive
side
effects
are
less
visible
and
they
are
in
terms
of
how
we
how
we
treat
through
protocols
the
specifications
we
create
and
sort
of
taking
that
seriously
in
terms
of
not
breaking
stuff
all
the
time,
as
well
as
often
the
skill
set
that
we
develop
and
sort
of
their
respect
for
certain
type
of
design
shows
and
so
on.
But
in
general
I
agree
that
yeah
short
version
one.
F
And
technically,
in
terms
of
our
sophistication
of
thinking
about
these
problems,
I've
seen
because
right
now
in
this
proposal,
example
I,
don't
even
see
that
being
entertained,
and
this
was
a
big
thing.
When
we
talked
about
topic
negotiation
where
it's
like.
Oh,
we
can't
do
it
because
it's
broadcast
table
and
then
we
just
spent
a
week,
thinking
about
it
and
and
Andrea
came
up
with
this
great
proposal,
actually
solves
it.
So
it's
about
putting
serious
effort
into
it
and
then
actually
weighing
the
trade-offs
and
having
some
sophistication
about
it
and
how
we
approach
these
things.
F
A
Of
course,
you
can
always
tell
that
it's
easy
for
me
to
say,
because
I
I'll
be
on
leave
but
yeah.
That's
kind
of
my
thought
again.
It
might
be
that
this
will
actually
take
long,
but
let's
just
try
to
at
least
estimate
it
right.
How
to?
How
do
we
keep
backward
compatibility
and
at
least
how
how
hard
would
it
be
to
do
this
and
I
can
assist
it.
F
If
that
sort
of
it's
clear
what
the
exact
trade
office
and
we
know
how
to
do
it,
then
we
can
make
a
choice
because
we
have
two
options
we
can
either
maintain
is
and
then
it's
it's
more
of
an
informed
choice
as
opposed
to
so
developing
time
and
so
on.
But
it's
more
about
here
is
the
actual
technical
trade-off
and
and
that's
the
arena
where
you're
making
a
decision
and
at
that
point
I
would
at
least
personally
feel
more
confident
that
we
have
learned
how
to
deal
with
these
things
and
we're
making
informed
position.