►
From YouTube: [Bi-Weekly] 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).
B
Yeah,
so
this
is
a
code.
F
call
number
21.
This
is
D.
We
speaking
since
Egor
is
not
here
anymore.
In
the
past
cars
out
of
the
office,
so
I
shared
a
link
with
the
agenda
to
this
call,
so
you
can,
as
usual,
start
with
the
strong
days,
and
then
we
have
two
subjects
listed
on
the
agenda:
an
update
on
the
impacts
of
the
multi-account
on
sending
transaction
from
chat
and
some
discussion
about
backward
compatibility.
If
you
guys
want
to
add
any
subject,
please
feel
free
to
do
so.
B
D
There's
still
another
round
of
audits
to
be
performed
on
this
new
contract
changes
and
and
now
the
next
step
is
to
implement
those
contract
changes
and,
at
the
same
time,
in
parallel,
I'm
I
am
moving
away
from,
like
the
the
current
wait,
identify
stickers
which
is
tied
to
LP
FS,
and
so
we
were
moving
away
from
this
to
a
more
agnostic
way
to
identify
stickers.
So
this
way
we
could
have
stickers
asti
than
other
distributed
storages
like
swamp
and
also
your
IP
FS
know.
D
Right
now
we
are
using
getaway
to
a
PFS,
so
we
used
to
be
stuck
with
one
specific
getaway
infra,
for
the
idea
is
to
be
more
agnostic
and
to
be
able
to
select
which
gateway
we
want
to
use.
Just
two
are
being
implemented
in
parallel,
so
they
should
be
done
like
end
of
this
week
and
the
idea
is
to
make
sticker
market
available,
probably
before
the
one
like
some
kind
of
interim
releases,
so
that
people
can
start
playing
with
it.
E
E
Basically,
just
did
I
guess
we'll
have
a
meeting
to
discuss
that
and
then
dab
stores
gonna
be
well.
Actually,
that's
our
article
will
be
worked
on
this
week
as
well
to
go
out
hopefully
end
of
this
week,
beginning
of
next
week
for
another
article,
a
few
also,
if
you
have,
if
you
would
like
to
discuss
potential
impact
of
something
you're
working
on
then
ping
me
and
you
can
join
the
call
I
can
bring
it
up
to
can
start
going
around
and
saying.
D
E
D
F
Yeah
I
can
take
it
on
so
for
Talent
Network.
Last
week,
progress
includes
refactor
on
the
waifus
world,
and
now
we
send
those
fees
to
the
staking
pool
contract.
Also,
we
decoupled
most
of
the
more
contracts
in
order
to
have
a
way
to
change
their
functionality.
In
case
we
found
box
or
we
want
to
improve
them,
and
these
also,
let
us
ask
that
this
absolute,
let
us
change
the
smart
contract
without
affecting
the
other
smart
contracts
involved.
F
A
Can
give
an
update?
Basically,
people
are
on
holidays
of
people
at
left,
so
we
think
we
have
mainly
two
streams
of
work
here
and
so
proven
some
we
are
pushing
some
logic
hit
the
status
code,
so
the
protocol
logic
will
be
pushed
into
this
course
with
making
good
progress.
You
know
deciding
how
to
structure
things
and,
in
the
meantime,
as
an
early
moving
things,
scope
and
then
I
think
Pedro
is
working
on.
A
reproducible
builds
I
think
he
had
good
progress.
If
he's
on
the
Kali
will
probably
tell
you.
A
A
A
A
B
D
So
Andre
is
not
here.
Maybe
I
can
share
a
few
words
so,
as
I
said
earlier,
I'm
working
on
sticker
market
and
then
the
well,
the
rest
of
the
team
is
kind
of
spread.
While
the
word
ring
team
is
fred
and
different,
not
really
UI
related
subject,
but
so
teddy
is
working
on
embodying
and
implementing
the
the
new
pin
code
mechanism
and
eric
is
there
working
on
which
accounts
I
believe
so
that's
kind
of
the
spectrum
of
things
were
working
on
right
now.
B
Okay,
thank
you.
I
can
give
a
quick
update
on
keycard
and
energy
account,
so
four
key
card
Dimitri's
is
progressing
on
the
integration.
Instead,
us
is
really
the
pure
for
the
e
onboarding
apart
last
week,
and
so
what
we
still
have
left
is
the
login
and
recovery
of
an
account
to
be
done
with
this
integration
and
former
T
account.
B
So
there's
the
call
UI
work
being
done
for
t-account
expire,
and
you
account
view
there
was
a
pure
done
I
think
ten
days
ago,
two
weeks
ago,
but
that
eric
has
been
working
on
the
actual
creation
of
the
keepers
at
onboarding
and
on
the
good
side.
There
was
a
pure
last
week
for
the
go
api
from
each
account.
So
now
Andre
will
work
on
the
on
the
GU
implementation
for
embossing
accounts
from
a
private
key
so
and
in
the
multi
account.
B
We
have
discussion
also,
but
migration
I
mean
which
are
more
than
about
virtual
campus,
will
discuss.
That
is
one
of
the
points
in
the
agenda
that
we
discussed
right
after
and
we've
discussed
also
some
chat
implications
from
OTO
account
and,
as
you
also
wanted
to
raised
as
a
subject
in
discuss
about
what
accounts
the
DAP
can
use
so
in
v1.
We
might
just
use
the
domain
account
for
that,
but
there
were
some
discussion
raising
that
it
might
not
be
flexible
enough.
B
So
we
are
trying
to
assess
that
and
see
that
if
we
do
provide
flexibility
for
the
user
to
use
another
another
account
than
the
main
one,
how
we
do
that
and
what
would
be
the
the
consequences.
So
if
you
have
some
ideas,
you
can
check
on
discuss
about
that
and
that's
it
for
key
:,
which
accounts
may
be
in
the
beta
from
janitors
anyone,
maybe
nebula
yeah.
G
I
mean
not
not
terribly
much
is
happening
basically
just
trying
to
we
spend
last
week
trying
to
figure
out
exactly
what
is
in
and
out
of
scope
for
v1
and
the
one
unknown
the
biggest
on
run
and
unknown.
Right
now
is
the
minimal
Viable
Data
Sync
work
that's
happening
and
to
see
whether
it's
possible
to
get
that
scoped
in.
If
so,
they
gives
us
a
bit
more
a
bit
more
time
on
the
front-end
work.
G
The
front-end
work
is
continuing
primarily
on
onboarding
multi
account
and
polishing
up
some
of
our
gap,
so
we're
looking
at
code
freeze,
probably
end
of
July
mid-august
ish,
just
depending
on
how
things
progress
and
then
the
unknown
is
the
minimum
viable
minimum,
viable
data
sink
stuff.
So
Reich
has
all
the
updates,
but
that's
that's
pretty
much
the
top
priorities
to
finalize
the
scope
of
e1.
G
D
A
I
And
we
have
some
updates
in
the
topic
them
democracy
inside
of
multi
C
guy
I
am
working
on
this
ABI
in
DB.
Is,
is
already
done
that
that
now
I'm
working
on
part
of
of
the
component,
when
they,
when
you
you
don't
have
any
ABI
so
I
want
to
have
like
a
hex
viewer
and
make
it
easier
for
the
users
seeing
what
is
the
cow
data
that
is
there
to
analyze
it
and
and
I.
I
Also
I'm
working
on
this
at
value,
a
component
and
so
I
have
the
at
address
at
Cowell
data
in
at
Valley
and
I.
Think
eventually,
I
have
s
transaction
that
uses
this
all
these
compliments
and
I'm
working,
of
course,
in
the
multi-sig,
but
these
components
they
are
like
they
don't
use
any
any
like
bootstrap
is
just
react
and
and
then
they
should
be
able
to
be
easily
parted
in
any
other.
For
example,
in
topic,
democracy.
H
So
I
finally
got
my
audio
fixed.
Can
you
hear
me?
Okay,
yes,
so
I
could
probably
give
an
update
about
the
resistible
builds
on
Android.
The
the
current
status
is
that
I've
finally
was
able
to
gather
end-to-end
build
then
completely
inside
in
its
sandbox,
which
is
reproducible
across
different
machines.
So
we
have
a
bitwise.
H
B
Okay,
thank
you,
Peter.
Anyone
else.
We
cover
everything,
it
seems
so
okay,
so
we
have
two
subjects
on
the
agenda.
First,
one
it's
a
subject
about
chat
and
how
we
send
fans
in
chat
in
v1.
This
is
something
we
we
discussed
briefly
on
the
mat
you
can
call
last
Thursday
I
can
summarize
it
maybe
quickly.
Erik
yeah
I
mean
now
in
beta.
As
you
know,
we
have
whisper
and
while
it
appears
that
I
are
the
same,
but
from
v1
at
least
pears
would
be
different.
B
So
we
have
made
clear
already
a
couple
of
weeks
ago
that
we
would
use
on
the
sender
side
a
while
at
accounts
and
the
fans
would
get
to
be
where
that
accounts
to
so
that
that's
really
clear
and
these
two
addict
accounts
are
different
from
the
I
mean
they
are
not.
The
whisper
keepers
are
different
from
these
accounts,
so
we
had
already
identified
that
will
need
be
to
provide,
is
whether
to
count
to
a
and
we'll
do
that
when
B
is
adding
a
as
a
contact.
B
What
we've
outlined
and
actually
does
a
summary
of
the
discussion
in
the
agenda
I
forgot
to
mention
that
each
one
a
check
of
the
details.
What
we've
raised
on
Thursday
is
that
a
we
also
have
to
prove
in
the
whisper
level,
through
whisper
message
that
the
weather
to
County
used
to
send
the
funds
are
really
his
I
mean
he
needs
to
be
a
proof
of
ownership,
which
will
be
a
sign
message
by
the
account
used
by
the
transaction
that
we
need
to
transit
of
a
whisper.
Otherwise,
the
risk
of
in
personification.
J
It's
specifically
for
the
feature
that,
when
you
send
phones
to
someone
in
the
chat,
there
is
a
message
that
appears
and
says:
X
transferred
that
found
amount
of
X
to
you,
and
the
issue
is
that
we
should
only
show
these
messages
if
B
has
proven
ownership
of
the
wallet
to
to
a
because
otherwise
would
pretend
to
have
another
to
return.
That
transaction
from
someone
else
was
his.
So
the
idea
is
to
send
a
proof
of
ownership
when
he
wants
to
send
these
kind
of
messages
to
a
showing
that
he
sends
funds.
I
J
Yeah
or
someone
could
have
given
a
address
to
be
wallet
address,
and
he
knows,
but
here
we're
talking
specifically
when
you
have
someone
as
a
as
a
contact
or
yeah.
Actually
it
could
also
be
the
case
that
B
is
not
a
contact
of
a
and
the
Gerdes
wallet
address
from
someone
else
and
whisper
ID
as
well,
and
he
wants
to
send
funds
and
so
that
that
he
can
do
that.
J
But
if
he
wants
to
send
a
message
to
a
as
well
saying
a
I
sent
you,
you
know
the
the
same
comment
message
that
we
have
this
one:
we
don't
want
to
send
it
unless
B,
as
proven
ownership
of
the
wallet,
is
claiming
he
has
sent
a
funds
from
so
that
if
it's
actually
see
we
send
the
phone's.
B
cannot
claim
the
the
funds
by
sending
a
message
to
a
that
says:
I
I
sent
you
the
phones.
I
So,
basically,
now
that
we
have
in
this
contact
two
fields
that
is
one
is
the
public
key
for
shut
messaging
and
the
other
that
is
may
might
be
optional,
like
maybe
some
contacts
don't
have
the
address
of
the
wallet
address.
Let's
say
of
this
contact
and
then
this
context
you
might
not
be
able
to
send
phones
safely,
at
least
so
we
don't
allow
it
because
we
don't
know
if,
like
we
are
seen
into
some
stages,
desktop
a
Schottky
that
doesn't
even
have
a
wallet,
for
example.
So
is
that
is.
J
Separation
of
wallet
and
and
chat,
a
whisper
accounts
or
just
for
the
sake
of
not
having
the
wallet
account
key
in
memory,
so
with
the
v1
will
check
count.
You
will
always
have
chat
account
that
never
has
phones
or
unless
someone
somehow
managed
to
send
them
by
mistake,
and
then
you
have
the
actual
wallet
account
where
and
because
you
cannot
derive
the
chat
account.
The
white
account
from
the
chat
account
anymore.
J
That's
why
we
need
to
send
it
somehow,
but
the
thing
is,
since
they
are
not
related
anymore
before
you
could
could
verify
that
when
I
send
you
a
message,
there
is
a
transaction
that
matches
with
it.
If,
when
I,
send
you
a
transaction
sent
message,
but
now
it's
not
possible
anymore,
because
the
public
account
the
the
chat
account
and
the
wallet
account
are
not
related.
I
So
it
would
be
like
a
contract
where
the
idea
is
that
when
someone
pays
one
address,
they
have
the
boots
to
talk.
So
I
think
that
yeah
we
can
talk
to
discuss
this
better
in
the
swarm
of
through
butcher
talk,
but
I
think
that
would
be
like
setting
you.
You
said
well
I
wanna
address
and
maybe
even
you
don't
even
have
to
hold
the
key
of
that
address.
So
if
someone
have
the
the
transaction
to
data
address
that
you
selected,
they
can
say
me
and
they
sent
us
the
amount
forms
of
you
configured
it.
I
Would
be
that,
for
example,
if
you
have
the
ENS
usernames
and
then
that
would
be
the
entry
point
for
people
that
you
don't
have
in
the
contact
list,
that
you
don't
meet
or
don't
give
them
a
care
code.
This
would
be
the
entry
point
for
people
getting
into
you
so
that
public
chat
key
would
be
also
a
wallet
or
something
we
can
discuss
better
in
the
two
budget
Oxfam.
I
But
okay,
maybe
they
can
be
shut
in
like
a
society,
a
special
key
that
can
handle
this
through
budget
talks
and
then
they,
after
the
tribute
to
talk,
is
paid
and
they
can
exchange
the
actual
like
a
new
communication
key.
That
is,
of
course,
just
for
that
sheds
for
that
person
after
the
payment
is
done,
depends
on
on
the
on
the
tribute
to
talk,
but
for
the
discipline
prevention
would
be
the
most
simple
case.
B
B
B
Just
an
intro
on
this
with
in
the
past
week
with
many
I,
think
mainly
been
discussing
how
we
would
go
from
beta
to
be
one
managing
this
new
whisper
path
that
we
have
in
v1.
How
we
would
tackle
that
so
that
a
user
still
uses
all
whisper
ID
in
a
v1,
and
we
progressed
on
that
saying
that,
instead
of
having
to
whisper
ID
in
the
same
code,
that
was
the
initial
idea
distinct
with
the
old
one
answering
on
the
new
one.
B
B
D
I
It
would
work
for
using
this
type
of
legacy
integration.
For
example,
not
only
four
people
came
in
from
old
stages
but,
for
example,
day
from
people
came
in
from
other
wallets
like,
for
example,
you
you
might
have
a
wallet
in
other
wallet
software,
maybe
in
the
mobile
or
maybe
in
the
browser.
Maybe
it
was
missed
or
something
else,
and
maybe
then
you
could
also
use
this
other
wallet.
Of
course
the
case
would
be
about
the
Schottky.
You
don't
want
anymore,
the
Schottky
to
be
your
your.
B
J
If
you
are,
if
you
create
the
status
view
on
account,
you
can
import
keys
from
different
origins.
So
that's
something
that's
covered.
Yes,
you
do
import
account
and
you
will
you
provide
your
seed
phrase
or
your
private
key
or
your
what
else
who
have
key
file
and
and
then
you
will
choose
the
the
path
and
get
your
account
as
part
of
your
mich
account
here.
The
question
is:
if
we
do
a
migration
for
beta
2,
V
1,
how
do
we
handle
legacy
account?
J
Do
we
encourage
the
user
to
upgrade
and
for
that
provide
a
migration
path,
or
do
we
just
leave
the
legacy
accounts
on
the
side
and
basically
with
we
don't
maintain
them?
We
just
leave
the
opportunity
to
the
user
to
use
it,
but
with
that
in
mind
that
it
won't
have
all
the
features
that
everyone
would
get
over
time.
J
C
J
C
Exactly
and
what
we
would
want
to
try
and
offer
is
to
facilitate
you
transferring
the
funds
from
your
original
accounts
to
your
new
accounts
by
either
manually
copying
the
wallet
address
of
this
new
ik
and
another
thing
that
we
would
need
to
consider.
But
I
don't
really
have
that
fleshed
out
yet
is
to
help
people
kind
of
like
move
their
DNS
registration
to
this
new
accounts
as
well.
B
I
I
I
I
J
Thing
is
if
we,
if
we
break
compatibility
with
legacy,
accounts
in
terms
of
chat,
only
that
wouldn't
be
a
problem
because
you
could
import
the
legacy
account
as
as
just
another
wallet
to
your
new
mobility
account,
and
then
you
don't
have
to
transfer
forms
or
anything.
It
will
just
be
one
of
the
wallets
in
your
Moochie
account.
If
we
want
to
keep
all
the
whisper
ids
running,
then
we
have
to
separate
them
and
have
the
mutual
account
with
the
and
with
the
potential
security
issues
that
come
with
it.
I
There
is
also
other
consequences
when
you
change
the
key,
for
example,
because
the
key
is
use
it
for
decrypting
data
right
so,
for
example,
the
contact
list
and
also
when
you
change
the
your
key.
You
are
also
changing
your
identity
to
other
people.
So
there
is
all
these
announces
when
you
make
this
migration,
but
for
the
disorder
like,
of
course,
in
the
phones.
J
J
If
or
if
we
want
to
keep
this
wallet
without
well,
it
account
without
moving
all
the
phones.
Then
we
need
to
drop
the
the
chat
account
because
there
they
are
the
same
so
but
but
you
cannot,
since,
since
we
want
to
have
this
property
of
separation
between
wallet
and
and
chat
account,
we
cannot
have
both
keyboard
and
you,
you
cannot
have
the
chat
account
key
not
on
in
memory,
because
otherwise
we
would
have
to
unlock
the
key
for
every
message
received
and
not
only
message
that
you
for
you,
but
any
message
received
on
whisper.
I
Would
be
possible
to
create
the
the
second
version
of
like
in
multi
accounts,
the
keys
in
a
for
example,
use
a
different
type
of
mini
Manik.
For
then
we
be
able
to
detect
what
is
the
version
of
the
account
the
user
is
entering
so
because
then
we
could
autumn
because
the
it
seems
that
is
hard
for
the
software
to
detect.
I
If
it
was
a
legacy
account,
maybe
it
could
check
if
there
is
too
much
funds
on
it
on
this
or
if
there
is
Mouse's,
for
example,
if
it
can
check
in
the
ATM
blockchain,
if
that
account
have
announced
bigger
than
0,
if
it
has,
it
means
that
it
made
a
transaction
in
past.
In
probably,
is
a
legacy
account.
So
do
you
think
there
is
some
ways
of
detecting
automatically
if,
if
it
was
a
lie,
if
it,
the
user
entered
a
legacy,
account,
for
example,
in
a
new
installation.
J
I
Maybe
every
account
that
he
that
was
on
the
date
process
is
a
legacy
account.
So
maybe
it
didn't
configuration
could
have
a
check
box
saying
legacy
account,
and
if
he's
that
selected,
then
it
would
means
that
it
would
use
the
wallet
key
to
to
sign,
shut
messages
and
and
when,
when
that
check
box
is
market,
then
have
very
annoying
red
pop
up
keeps
annoying
the
user
saying
hey.
This
is
a
like
checkout.
I
Don't
know
why
you
would
need
that
in
specific
because
formed
emigration,
you
don't
need
to
migrate
this
chat.
Maybe
if
you
want
to
send
a
mass
message
in
the
old
system,
then
you
would
check
legacy
account,
but
in
the
most
cases,
if
you
you
just
need
to
make
transactions
like
freezing,
to
move
the
phones
out
or
to
make
the
migration
of
the
ENS
usernames,
that
would
need
the
wallets.
Kick
the
not
a
Schottky.
So
yes,.
B
J
J
J
We
would
only
have
new
accounts
and
therefore
we
would
only
have
accounts
that
use
partitioned
discovery
topic
so
that
wouldn't
be
a
need
for
everyone
to
still
listen
to
this
single
discovery
topic
that
legacy
accounts
are
have
to
listen
to,
and
this
this
topic
is
kind
of
a
single
point
of
failure,
because
if
you
spend
this
particular
topic,
you're
spamming
everyone
because
everyone
is
listening
to
it.
So
anybody
could
by
just
timing
this
account
you're
increasing
in
the
bandwidth
of
of
everyone
else.
Anonymously.
I
So
it
seems
like
it's
not
very
important
to
support
legacy
accounts
because
when
you
enter
for,
let's
say
a
legacy
account
in
the
new
system,
this
legacy
account
becomes
their
wallets
and
then
the
users
to
have
access
to
his
phones.
And,
as
you
said,
what?
Because
what
changes
is
the
whisper
key?
What
is
the
key
use
it
first
for
messaging,
yes,
and
so
so
the
the
support
for
legacy.
Maybe
it's
not
that
important?
I
B
I
Course,
the
migration
of
Venus
usernames
that
that
other
things
but
like
because
that
is
something
that
changes,
because
in
DNS
usernames
you
have
to
fear.
If
configurate
you
are
whisper
key
that
is
different
from
your
address.
Is
it
have
more
bytes
than
your
address
and
and
what
would
you
your
wallet
would
change?
Is
that
public
key?
Well
then
migrating.
J
Ens
names
is
going
to
be
much
easier
if
we
don't
migrate,
which
variety,
because
then
the
legacy
account
and
the
multi
accounts
are
not
separated,
because
you
would
just
import
your
old
account
as
a
wallet
account
in
your
mooch
account
and
because
it
will
already
be
part
of
your
multi
accounts.
You
will
have
access
to
the
new
whisper
IDs
and
to
the
old
wallet
account
in
the
same
media
account.
So
you
will
be
able
to
do
the
migration
in
straight
straight
forward.
If
we
propose
a
migration
path
from.
J
If
we
consider
legacy
accounts
are
as
a
separated,
multi
account
with
the
still
the
same
chat,
a
whisper
account
and
wallet
account.
Then
we
will,
in
order
to
to
move
to
upgrade
to
a
multi
account.
You
will
need
to
transfer
all
your
funds
and
you
will
need
to
copy
somewhere
your
chat
ID
from
the
new
account,
so
that
you
can
do
that.
Transfer
of
DNS
names
from
the
old
account
to
the
new
one.
I
mean
the
flow
will
be
a
bit
more
complex,
but
but.
I
I
I
J
That's
that's
what
I'm
saying
like
you
you
with
legacy
accounts
you
you
either
don't
buy
into
the
new
security
model.
We
have,
which
is
never
load
a
wallet
account
in
memory
or
you,
and
then
you
cannot
absolutely
not
use
it.
As
a
my
hello
I
see
how
sorry
I
thought
my
my
computer
went
to
sleep,
so
I
thought
I
I
was
muted
out.
Okay,
can
you
hear
me
yes,
yeah?
J
Okay,
where
was
I
yeah,
so
I
was
saying
so,
if
you
don't
buy
into
this,
then
you
can
still
import
the
old
legacy
accounts
by
by
bypassing
that
and
still
loading
the
wallet
key.
But
if
you
want
to
to
move
to
the
to
the
new
you
you,
you
need
to
migrate,
the
phones.
If
you
want
to
listen
forever
to
your
own
whisper
ID,
you
have
to
migrate
the
fonts
of
your
wallet
so
that
the
the
wallet
is
separated
from
the
from
the
whisper
accounts.
The
white
account
is
separated
from
the
whisper
account.
J
So
the
fact
that
we
need
to
be
able
to
update
as
many
versions
at
once
that
the
user
wish
we
need
to
have
the
backward
compatibility
between
the
the
sync
protocol,
which
is
not
binded
by
by
a
schema
like
the
database.
So
that's
that's
a
weak
point
in
our
in
the
current
architecture,
because
if,
if
we
want
to
sync
than
just
messages
and
account
settings,
we
need
to
be
very
careful
with
that,
because
we
can
easily,
we
already
have
easily
break
broken
compatibility
in
the
bus.
J
So
that's
one
thing:
we
should
probably
spend
more
time
on
before
release
rather
than
migrating.
This
whisperer
IDs
and
another
thing
is
well.
If
we
don't
have
compatibility
with
the
Hesperides,
then
we
might
do
some
upgrade
of
the
protocol
for
for
everyone
in
terms
of
prices,
removing
the
the
transit
wrappers
that
that
are
never
been
I've
never
been
used
until
since
they've
been
made
yeah.
So
that's
just
a.
A
A
J
Why
I
believe
in
order
to
be
more
flexible
and
and
have
a
better
understanding
on
when
we
break
things
or
or
not?
We
could
have
something
similar
to
what
we
have
from
the
database
and
then
we,
if
I,
receive
a
schema
from
v2
sync
message
from
v2.
Maybe
I
can
still
use
it
for
v3
installers.
Something
like
this
well.
J
B
B
On
the
other
hand,
why
we're
doing
that
in
terms
of
use
case?
Yes,
we
we
said
wanted
to
do
that,
willow
users
to
still
being
able
to
communicate
with
the
all
whisper
ID,
and
then
it
was
also
a
matter
of
principles,
but
I
think
I'm
not
going
to
reopen
the
debate
right
now,
but
it
really
seems
that
we
need
to
come
to
a
conclusion
there,
but
no,
not
all
stakeholders
are
present
right
now
in
this
call.
So.