►
From YouTube: Core Devs Meeting #15 - March 25, 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).
B
B
A
B
B
A
Cool
so
yeah
thank
you
and
welcome
to
the
15th
core
dev,
a
call,
that's
not
with
some
very
brief
swap
date,
if
just
anything
that
hasn't
been
mentioned
in
the
last
Town
Hall
that
you
think
other
people
should
know
about,
and
then
we
could
talk
briefly
about
partition
with
the
topic.
Compatibility
started
to
go
as
the
next
package.
Briefly
on
cares.
A
E
A
F
Yeah,
the
contract
was
updated
so
that
it
can
be
deprecated
in
the
future
and
the
message
personalized
message
for
attributed
talk
has
been
replaced
by
a
hash
for
for
ipfs,
so
that,
instead
of
just
having
a
message,
can
have
a
bunch
of
metadata,
including
the
message
and
store
it
on
ipfs
and
yeah.
That's
it
forward
to.
A
C
A
ruler
that
can
the
market
I
want
to
ask.
There
were
a
couple
changes
that
were
that
were
happening
with
regards
to
the
contract.
Are
those
done?
Are
they
still
in
progress
right?
So
Ricardo
did
like
a
very
simple
change,
and
it's
done
as
far
as
I
know,
so
you
yeah
it
should
be
origin.
The
rapport
now.
A
C
So
we
we
try
to
put
the
dap
in
rinkeby
and
we
we
debugging
south
deployment
issues
that
are
happening,
namely
with
some
caching
issues
that
that
was
happening
on
the
on
the
client
side.
We
fix
this
issue
with
the
S&T
token
that
we
found
I
mean
we
did
a
little
bit
of
I.
Did
a
lot
of
small
fixes
here
and
there
and
and
was
the
goal
right
now,
is
to
get
it
working,
1%
and
maker
be.
B
Yeah,
basically,
the
goal
for
the
this
weeks
is
to
make
an
event,
went
very
like
simple
proof
of
concept
original,
so
essentially
the
whole
sort
of
flow
from
running
a
mail
server.
In
our
case
right
now,
it's
a
status
node
and
registering
it
for
now,
while
it's
some
sort
of
a
closed
beta
and
then
using
it
in
the
app
so
essentially
to
have
this
flow
of
no
incentivization.
But
it
is
the
flow
around
your
custom
node
and
you
can
use
it
in
status
in
a
more
or
less
convenient
way.
G
G
What's
the
probability,
what
are
the
factors
that
influence
the
probability
of
a
project
failing
and
then
just
about
you
know
your
the
your
own
specific
drivers,
a
value
yeah
and
we're
thinking
about
maybe
starting
to
publish
some
of
our
research,
maybe
has
blog
posts
to
try
to
get
a
broader
feedback.
Yeah.
D
B
It
was
one
zero
release,
testing
and
things,
and
we
actually
decided
that
after
this
discussion
discuss
post
to
have
a
no-go
for
the
current
implementation
of
topic,
partitioning
we'll
discuss
it
later,
but
yeah,
that's
just
for
the
information,
so
we
will
not
enable
it
in
0
11
0.
That's
all
for
me.
A
Cool
right
I
can
do
protocol
briefly,
don't
freaking
mention
something
so
we
had.
We
had
this
panel
in
if
you
see
a
few
weeks
ago,
and
that
sort
of
work
is
ongoing
to
some
more
long-term
mix.
A
You
seen
sort
of
the
data
synchronization
resource
log
I
started
a
week
or
two
ago,
with
the
goal
of
sort
of
taking
a
step
back
and
looking
at
sort
of
existing
literature
when
it
comes
to
data
replication
and
so
on
so
see
all
the
various
alternatives
and
try
to
categorize
them
and
understand
the
trade-offs
more
in
a
better
way.
So
I'll
keep
working
on
that
and
getting
a
better
sort
of
comparison
and
then
see
what
comes
out
of
that
and
then
one
sort
of
there's
a
better
on
say
of
that.
G
G
This
project
completed
I
think
maybe
perhaps
a
stretch
goal
to
try
for
it
is
to
create
a
page
that
would
easily
allow
someone's
who
create
their
own
project
page,
not
just
view
one
and
back
one,
maybe
in
time
for
build
week,
and
we
might
be
able
to
dog
food
with
a
different
people
and
teams
inside
of
status
store
and
build
week,
uploading
their
projects
to
using
liquid
funding.
So
that
sort
of
a
stretch
goal
we'll
see
if
we
can
get
that
we
can
get
that
built
in
this
next
week
or
not.
F
Can
make
a
small
update
for
chat?
What
we've
done
that
concerns
for
other
teams?
So
there
is
the
the
typographic
component
that
has
been
implemented
so
from
now
on,
it's
better
to
use
this
instead
of
font
type
and
font
font
size
and
all
these
font
related
parameters
when
implementing
CSS
and
unless
it's
a
very
specific
component
that
doesn't
have
a
unknown
typography.
C
Can
say
a
few
word
for
the
browser
team
I
was
meeting
than
before
so
yeah,
because
we
are
mostly
done
with
sticker
market.
Now
we
take
this
opportunity
to
push
a
bit
more
extension
and
the
short
term
goal
is
to
extension
out
of
alpha,
so
that's
behind
the
flag
and
usable
directly.
So
that
means
mostly
nailing
error,
handling
and
permission
mechanism
and
also
with
we
plan
to
crucially
a
little
it's
the
developer
experience
just
to
make
sure
it's
easier
to
create
extension.
A
I'm
curious,
sir
any
plan
or
research
around
making
sensors.
So
so
you
could
use
the
dinners
of
in
a
different
environment
whether
that
would
be
like
some
JavaScript,
API
or
I.
Don't
know
what
it
would
look
like,
but
making
it
so
it
could
be
implemented
in
other
clients.
What
closed
script
is
not
surfing
as
first-class
system.
C
C
C
Yeah
four
key
card
when
she
finishing
the
Android
integration
in
VP
last
week,
we
still
had
to
work
on
the
Dubs
transaction
signing
also
death
integration
is
almost
done
under
eyes.
L
ping,
diem
value
from
other
ROM
team
to
finish
that
week's
progressing
very
well
and
we
are
getting
in
a
research
phase
to
a
low
point
of
cell
use
cases
within
the
apps
through
either
payment
I
mean
through
either
through
QR
codes
or
with
Kiko,
and
there's
been
a
brainstorming
about
that
last
week
that
I'll
post
right
there.
C
D
A
D
A
D
A
B
B
It's
it's
great
for
privacy,
because
each
node
is
downloading
each
other
nodes
traffic,
which
is
good
because
you
can
figure
out
who's
talking
to
whom,
but
the
baddest
yeah,
because
each
node
is
downloading,
knows
traffic
so
and
I
don't
know
we
had
this
outage
of
the
Hong
Kong
mail
servers
awhile
ago,
and
before
that
we
had
an
issue
with
traffic
draining
on
East
Berlin
I,
guess
it
was
so.
It
was
all
started
roughly
at
its
Berlin.
B
When
we
looked
at
this
issue
and
then
yeah,
essentially,
we
figured
out
that
it's
right
now
with
our
current
user
base
is
around
like
in
on
a
normal
day.
It's
around
100
megabytes
of
private
messages
per
day,
and
each
one
has
to
download
everything.
And
that
means
that
if
we
just
if,
when
we
release,
if
we
will
have
like
10
times
more
users,
it
will
means
that
each
one
will
have
to
download
the
gigabytes
of
traffic
per
day
just
for
private
messages,
which
doesn't
look
like
a
good
idea.
B
B
And
then,
after
this
issue
with
mail
servers
that
was
in
December
I
guess,
then
we
decided
to
re
like
we
evaluate
this
and
I
created
a
poster
on
discuss
about
what
do
we
want
privacy
or
do
we
want
like
an
efficiency
out
of
traffic?
And
then
this
post
didn't
get
any
attention
almost
at
all
and
I
guess
one
day,
Ricardo,
Adam
and
Andrea
were
participating
there
more
of
us
and
then
essentially
we
just
figured
out
there.
B
B
B
Isn't
I
mean
it's
not
that
bad,
but
it's
not
the
simplest
one
and
it's
not
the
simplest
one
to
re-implement
it
other
languages,
then
JavaScript
or
closure
script
or
anything
that's
compile
to
JavaScript.
So
we
decided
that
we'll
postpone
this
partition
topic
and
yeah.
Well,
should
we
change
to
do
this
and
it
will
still
be
a
breaking
change?
Will
that
we'll
probably
try
to
split
across
multiple
releases?
A
So
every
question
on
the
backwards
compatibility
aspect,
which
is
like
I,
was
saying:
there's
we
don't
think
there's
any
way
we
could
maintain
backwards
compatibility,
even
though
we
have
multiple
devices
on
like
it,
sir,
because
you
could
imagine
that
you
that
you,
you
still
have
support
sending
of
a
discovery
topic,
but
once
you
discover
another
device
is
using
the
Sun
topic
than
you
would
use.
That
is
that
something
like
that
not
feasible
at
all
I
mean.
B
I
B
B
It's
much
harder
to
communicate
because,
right
now
we
can
just
tell
it's.
Okay,
if
you
have
version
that
starts
with
0
9,
please
upgrade
it
right,
but
if,
if
you
don't
do
this
and
try
to
yeah,
it
will
be
much
harder
to
coordinate
this
thing
and
it
it
will
meet
it
somehow
and
of
course,
this
breaking
change
is
not
that
bad,
because
they
we
are
in
beta
and
B.
B
We
can
revoke
bills
on
iOS
and
Android,
it's
much
worse
than
on
desktop,
of
course,
but
it's
it's
far
from
being
a
smart
plan
was
essential
as
soon
as
we
release
this
incompatible
change,
then
the
old
versions
will
be
expired
and
both
as
fight
a
little
play.
So
for
those
who
install
these
versions,
they
won't
be
able
even
to
use
them
anyway.
B
So
it's
it's
sort
of
a
mitigation,
well,
a
bad
one,
and
then
I
wanted
to
ask
as
well,
since
we
will
probably
will
have
to
break
this
like
we
want
to
delay
it
for
the
better
algorithm
for
partition
topic
for
simpler
one
and
is
the
one
that
it's
easier
to
implement
it.
Otherwise
we
just
in
JavaScript.
B
J
So
there
is
some
handshake
in
these
private
messaging
communication.
If,
if
there
is
couldn't
be
a
dis
handshake
informing
that
the
brought
the
client
is
using,
this
new
protocol
of
partition
and
topic
is,
and
if
they
don't
communicate
this
handshake,
they
just
considers
that
it
uses
the
old
generic
topic.
Wouldn't
wouldn't
be
that
possible
and.
A
J
Could
have
like
some
additional
message,
then,
like
a
protocol
message
that
is
sent
using
the
old
topic
and-
and
this
could
inform
the
these
new
clients
to
use
this
because
then,
if
you
are
a
new
client
and
you
see
that
you
are
receiving
a
message
in
the
old
system,
maybe
you
could
ask
them.
I
know
that
this
could
not
be
the
best
thing.
But
if
you.
B
B
And
the
second,
it
doesn't
solve
the
issue
when
you
have
one
like
you
have
to
merge
them,
so
I'll
say
the
desktop.
It
already
supports
it
and
then
the
mobile
that
doesn't
and
they
have
the
same
key
and
we
don't
have
a
client
information.
We
just
know
that
yeah
we
sent
something
to
a
public
key
and
this
public.
You
might
be
like
five
devices
with
different
versions
so
which
one
will
you
choose.
B
I
A
J
So,
regarding
the
waiting
more
for
this
feature,
I
think
it's
a
smart
move,
because
this
is
a
we
should
probably
discuss
better
so
I
remember.
This
discussion
was
like
when
the
first
problems
arise.
It
actually
commented
I
need
some
ideas
on
how
to
solve
and
actually
I
think
it's
just
the
same
thing,
but
I
maybe
got
some
details
wrong,
but
I
wanted
to
participate
in
your
discussions
about
this
and
to
see
what
we
can
do
like
to
have
a
better
solution.
I
Hey,
once
you
have
device-to-device
communications,
of
course,
you
know
like
the
method
that
we
mentioned
it's
possible
so
that
it's
trivial
it's
just
like
at
the
moment
we
were
literally
on
top
of
whisper
whisper.
Does
not
have
this
multicast,
you
send
to
a
public
key
anyone
with
that
public
key.
You
know
like.
Can
you
know?
Essentially
it
thinks
there's
no
way
you
can
do
it
with
whisper,
because
anyone
can
spin
up
a
version
of
the
previous
version
of
the
app
and
then
you
miss
you're
gonna
miss
that
message.
E
So
went
for
a
second
go
back
to
point
that
ever
made
that
we
can
be
happy
that
we
can
force
users
to
upgrade.
This
is
actually
had
kind
of
the
problem.
Every
time
you
force
the
users
to
upgrade.
That's
that's
a
coercion
Avenue.
That
is
how
that
is
how
vulnerabilities
get
introduced
involuntarily
for
users.
Basically,
if
you
want
to
get
an
update
out
to
users,
that's
what
you
do
it.
You
can
use
sort
of
masqueraded
as
a
protocol
update
or
whatever
right.
E
It's
a
very
classical
thing
like
Skype
does
it
when
they
became
centralized
and
so
on,
and
everybody
just
happen.
It
accepts
right.
So
we
should
be
a
little
bit
careful
about
being
too
happy
about
the
fact
that
you
can
force.
For
example,
Iowa's
users
are
great,
in
fact,
I
think
we
should
be
creatively
looking
for
ways
to
make
sure
that
that
is
not
possible.
E
B
And
I'm
happy
to
discuss
the
possible
solutions
right
now,
because
so
far
one
of
the
like
I
think
pretty
valid
critiques.
That
Andrea
points
with
and
I
totally
back.
Is
that
people
tell
that?
Ok,
you
don't!
Please
don't
do
this
and
there
is
no
essentially
dialogue
about.
Oh,
there
is
another
possibility,
it's
very
easy
to
just
tell,
but
you
never
break
compatibility.
So
what
are
we
going
to
do
so?
We
have
this
protocol
thin
year.
That
is
realized
on
I.
B
Obviously,
first
and
abstraction
like
because
we
shouldn't
use
whispered
topics
directly
in
our
protocol
period.
That's
another
topic
on
this,
so
we
have
this
very
rude
decision
that
was
made
before
we
are
recently
wrote
for
probably
reliability,
reason
so
and
that's
yeah
and
we
don't
really
have
devices
online
all
the
time.
So
what
are
the
good
solutions?
How
how
others
usually
decide
this,
in
mostly
as
synchronous,
communication,
I.
E
E
F
I
mean
I
just
wanted
to
say
that
there
might
be
a
way
to
do
it
with
that.
Breaking
change
if
asked
our
assumption
is
right
that
over
time
the
discourage
will
be
less
overused,
as
people
upgrade.
So
then
we
just
could
just
revert
to
what
the
protocol
was
initially
doing,
which
is
use
the
discovery
to
pick
on
e
for
contact
requests
and
then
switch
to
a
random
topic
after
the
first
reply,
and
then
there
is
much
less
traffic
in
in
the
discovery
topic
and
that
doesn't
require
an
upgrade
for
breaking
change.
I
think.
I
All
these
solutions
that
always
the
same
issue
at
the
moment,
the
way
we
do
multi
device
support,
which
is
basically
relying
on
the
public
key
you
know,
have
the
same
problem.
So
you
really
either
rely
on
some
state
I
random
topic
we
received.
Oh,
you
know,
you're
gonna,
miss
messages.
If
you
have
one
device
at
the
upgrade
to
the
run
topic,
you
are
the
new
device,
you
know
the
other
user
would
not
know,
and
it's
gonna
send
the
topic.
It's
gonna
send
a
message:
it's
gonna
send
it
to
the
ramen
topic.
I
A
I
That
to
me,
like
you,
know
like
we
should
just
like
the
fundamental
problem,
is
that
we
use
that
system
called
device.
You
noted
for
multicast
ik,
so
anyone
with
a
public
key
will
be
able
to
you
know,
basically,
no
matter
what
client
is
using,
no
matter
which
version
is
able
to
decode
those
messages,
and
that's
really
is
not
readable.
You
know
essentially,
because
you
know
like
because
it
is
embedded
in
this
in
whisper,
so
you
know
essentially
like
if
you
want
to
move
to
device.
I
The
device
is
basically
sending
its
gonna
come
at
the
cost,
of
course,
because
it
means
that
you
know
like.
If
someone
you
know
it's
the
same
as
see
with
group
chat.
So
it's
essentially
now,
if
you
mean
group
chat,
if
you
create
a
new
device
and
you
don't
sink
it
and
you
are
in
a
conversation
or
another
group
chat,
you
won't
receive
those
messages,
and
so
what
we
did
is
there
are
techniques
so
that
that
information
is
propagated,
but
that
information
which
is
similar
to
protocol
negotiation,
but
the
information
needs
to
be
propagated
extension.
I
A
It
yeah
this
a
greedy
would
be
submit.
There
might
be
some
it's
cases
where,
if
you
don't
look
at
you,
you
recover
an
account
with
an
old
version
and
you
haven't
synced
with
the
device,
and
you
do
this
like
several
months
off
that
yeah.
This
might
be.
Some
eschatos
I
think
that
look
going
forward
like
having
something
that
whisperer
topic
as
a
kind
of
transport
transport
property
such
that
we
think
instead
about
it
in
terms
of
syncing
between
devices.
A
That
means
it
shouldn't
matter
for
applicate
ability
for
change
out,
whisper
or
whatever,
because
that's
not
actually
what
we
it's
just
one
form
of
transport
there,
multiple
forms
of
transport,
so
I
think.
If
we
have
that,
then
we
have
device
abstraction
and
we
can
have
sort
of
a
path
to
upgrade
graceful
upgrades
in
the
future.
I
F
F
Then
we
could
could
we
simply
have
used
the
old
mail
servers,
the
one
that
are
already
hard-coded
in
the
all.
Those
devices
has
like
legacy
mail
servers
and
we
make
a
new
fleet
and
this
fit
would
take
all
messages
from
from
the
new
devices
new
topics
and
put
it
all
in
this
curry
topic
so
that,
like
the
old
devices,
will
have
everything
in
discovery
to
pick
so
they
won't
miss
anything
but
I
mean
I,
guess.
B
The
signature
won't
signatures
won't
match,
but
we
can
do
it
too
short
and
check
it.
Probably
it's
signed
with
with
the
topic
and
I
know
how
whisper
will
probably
will
just
reject
envelopes
with
if
you
tamper
the
topic,
but
we
can
take
a
look
because
it's
a
it's
actually
at
a
solution.
If
that's
yeah.
F
All
the
other
one
would
be
to
allow,
because
right
now
you
cannot
send
a
message
if
you
don't
listen
to
to
a
topic,
but
we
could
do
a.
We
could
allow
it
for
for
this
topic
and
just
drop
a
copy
of
the
message
on
that
topic
and
never
listen
to
it.
We
could
effectively
ignore
it
form
for
yeah,
because
I
mean
yeah
anyway,.
A
There
was
another
point
if
it
was
a
good
point.
It
was
brought
up,
which
is
the
lack
of
engagement,
just
person
speaking
I,
think
that
positioning
topics
is
like
a
great
way
to
optimize
the
bad
way
from
the
second.
It
says
a
reasonable
thing
to
do,
and
it
seems
like
something
that
generally
could
be
done.
Loca
sort
of
local
form
decision-making
within
this
form
I
think
that
concern
might
be
when
it
comes
something
that
breaks
the
protocol,
so
that
impacts
sort
of
more
groups
of
people
and
I.
A
A
That's
something
we're
going
to
work
on
over
the
next
few
weeks
and
months
to
sort
of
we
have
some
haphazard
documentation,
but
bring
it
more
together
and
also
created
this
space
repository.
And
then
maybe
we,
when
we
have
questions
like
the
East
and
we
can
bring
them
us
up
in
a
quota
call
as
of
come,
prepare
with
a
proposal
for
changing
some
the
protocol
in
some
way
and
then
we
can
discuss
it.
B
F
A
You
want
to
call
it
at
least
that's
how
I'm
thinking
about
right
now
and
I
think
is
a
pretty
scheme,
scalable
and
and
and
tested
a
process
for
protocol
changes
in
general
and
something
that's
generally
used.
So
that's
how
I
met
it
specifically,
how
decision
will
be
made
or
when
something
will
move
from
draft
is
always
something
we
can
discuss
further.
J
A
So
this
would
be
so
this
would
be
more
about
client
implementers
and
then
maybe
it's
the
stairs
app
would
choose
to
expose
such
options,
but
across
I
mean
it's
more
about.
If
such
clients
of
example,
like
BitTorrent,
they
introduced
deep
support
and
all
clients
have
pretty
much
implemented
because
it
was
useful
and
then
you
added,
like
a
private
field,
to
have
private,
trackers
and
local
peer
discovery
and
these
types
of
things
and
it's
like
enhancements,
but
it's
up
to
each
client
how
you
want
to.
A
How
do
you
want
to
deal
with
it
and
most
clients
will
likely
expose
it
in
some
way?
If
you
want
to
use
tht
and
then
there's
all
these
considerations
and
so
on.
So
that's,
but
that
ins
itself
could
be
a
local
decision
for
the
status
app
and
it
would
be
separate
from
the
protocol.
So
the
idea
is
to
think
of
them
as
to
sort
of
separate
animals
kind
of
that'll
be
a
circus,
any
insights
or
or
thoughts.
He
would
like
to
add
to
this.
J
So
maybe
we
could
support
a
Java
version.
That
would
be
a
good
option
because
Java
is
a
is
a
really
clear,
written
language
and,
like
mostly
understood
widely
so
I,
am
myself
updating,
updating
it.
Cerium
j2
support
new
whisper
and
then
to
start
making
rising,
am
a
server
or
something
so
but
I'm
doing
that
three
time.
So
maybe
this
could
this
effort
would
help
in
that
the
protocol
definition,
because
having
these
implementations
just
make
it
on
reach,
how.
A
Do
you
got?
Oh
sorry,
sorry,
Kara
I
want
to
make
sure
we
don't
stray
too
much
into
protocol
and
disorientation
so
on
I
think
go
back
to
topic
with
whisper
finishing
and
so
on,
like
what's
the
specific
steps
we
want
to
do
here,
I
think
one
is
just
roughly
capturing
the
current
protocol,
and
so
these
types
of
changes
would
have
sort
of
carry
more
weight.
So
if
there's
gonna
be
some
some
kind
of
breaking
Kabaddi
bit
or
whatever
that
it's
sort
of
formatted
in
in
a
way,
that's
outside
the
code
base.
A
Yeah
yeah,
it's
just
a
question
of
time
frame
because
we
have
this
with
semi
specified
thing
living
in
app
right
now
and
then
draw
certain
core
pressures
that
sort
of
means
that
some
changes
have
to
be
made
sooner
or
than
later.
So
it's
a
question
of
find
the
balance
between
having
like
I,
don't
know,
protocol
specification
like
protobuf
specification
or
whatever,
for
everything
versus
sort
of
making
sure
that
the
thing
we
already
have
in
the
app
and
then
doing
graceful
changes
of
that,
but
that
sort
of
dealt
with
properly
yeah.
B
I
mean
there
are
few
things
that
you
started
the
second
implementation
and
go.
We
were
planning
to
have
a
like
a
separate
when
you
separate
the
repository
sooner
or
later
and
some
documents,
and
it's
already
helped
just
finding
this
issues
with
the
Java
JavaScript
specific
things
in
the
product.
I
hopeful
will
continue
with
that.
I
kinda
miss
working
on
this,
but
yeah.
A
B
A
Can
we
it's
just
some
way
we
could
have
some
kind
of
proposal,
fraud
to
deal
with
it
ameno
device
to
buy
space.
It's
like
what
the
path
that
looks
like
and
how,
how
we
think
that
the
last
breaking
change,
or
whatever
we
make,
will
be
compatible
with
the
change
in
the
transport
completely.
That's
one
thing,
and
another
thing
is:
if
there
is
some
creative
solution,
we
can
do
right
now
to
reduce
bandwidth,
to
example,
bye-bye
not
send
what
we
are
whatever.
E
B
We
always
listen
to
the
discover
it
so
anyway,
so
there
is
some
new
coin
that
goes
back
again
to
using
this
single
topic.
It's
me
it
will
work
by
default
as
I
understand
it.
It
costs
nothing
to
listen
to
these
topics
or
that
right
out,
yeah.
Of
course,
nothing
because
we
still,
we
use
it
for
other
things
as
well.
So
if
there
will
be
private
messages
to
me
in
these
topics,
they
will
be
on
whatever
it's.
Okay,
they'll
be
still
I
used
to
work
so
yeah.
If
anything,
but.
C
C
J
A
I
B
A
E
E
E
As
a
way
out
from
from
from
really
bad
decisions,
I
mean
we
do
have
the
advantage
that
we're
open-
and
you
know
the
code
can
be
audited
and
so
on.
But
then
we
also
need
this
very
long
period
of
time
for
the
information
to
seep
out
and
sort
of
in
case,
the
code
becomes
tainted
somehow
that
there's
time
for
this
taint
problem
to
become
known
even
for
people
that
are
maybe
not
online.
E
All
that
might
move
like
you
know
that
they
know
what
kind
of
trend
Verizon's
we're
looking
at
when
we
make
these
changes
when
they
start
using
gap.
So
basically,
I
know
that
alright,
if
I
start
using
status
today,
I
know
that
for
the
sixth
next
six
months,
nothing's
gonna
change
with
the
protocol
and
so
on.
B
So
what
do
you
think
there
is
a
reasonable
time
horizon
for
this
kind
of
changes?
For
instance,
if
we
do
still
do
a
partitioning
on
topic,
it
will
still
break
compatibility,
but
let's
say
we
do
not
like
one
release,
but
would
you
like
six
releases
or
something
before
we
actually
activate
it?
So
it
means
that
the
last
six
releases-
and
this
means
three
months
or
something
already
support
this.
So
if
you
have
a
version,
that's
older
than
three
months
and
we're.
B
E
F
B
E
Well,
the
time
period
is
sort
of
a
product
decision,
maybe-
and
it's
a
little
bit
of,
but
the
principle
here
is
that
when
I
start
using
that
I
would
know
that
the
guarantee
will
be
upheld
for
this
period
of
time.
So
I
would
also
know
how
often
I
need
to
check
whether
something
has
changed
and
generally
like
I.
Think
the
pair
should
be
fairly
long
as
in
more
than
three
months.
But
you
know
that's
really
I
don't
want
to
I.
E
A
J
H
E
I,
don't
think
that
matters
I
think
it's
about
establishing
what
status
is
in
order
to
attract
users,
and
if
we
go
about
thinking
like
I,
wonder,
have
100
users,
so
we're
gonna
break
it
and
that's
not
taking
a
reputation.
We
think
illnesses
I
really
want
to
have
like
we're,
making
a
stand
here.
Basically
and.
C
A
D
Two
sons
from
test
team
who
actually
using
status
very
intensively
I,
don't
know
if
I
can
survive
for
six
more
months
without
reliable
messaging,
to
be
honest
and
I'm,
not
sure
that
they
will
have
a
good
reputation
in
eyes
of
users,
because
we
don't
change
protocol
but
is
still
not
reliable
in
messaging.
Let's
yeah
a
bit
of.
A
E
C
D
D
It
would
be
great,
but
again
it's
like,
like
really
cheesy
things
that
yeah
we
can
say
that
we
are
good
because
we
don't
change
protocol,
but
at
the
same
time
maybe
we
need
to
be
a
bit
I,
don't
know,
look
for
other
ways
to
be
more
realistic
to
please.
Our
users
in
ways
that
you
know
features
are
good
messaging
is
reliable.
D
I
Two
out
there,
like
changing
the
whole
reason
why
we
were
actually
partition.
The
topic
is
that
currently
we're
a
bit
limited
but
as
pointed
out,
the
amount
of
data
that
we
fetch
and
so
like.
Therefore,
we
only
fetch
the
last
24
hours
of
data.
So
if
you've
been
offline
for
more
than
24
hours,
you
will
miss
messages.
So,
although
it's
true
that
is
not
an
effect
effect,
but
reliability
in
terms
of
like
you
know,
like
no
more
messages,
are
going
to
be
dropped
by
the
transport
layer
than
before.
A
A
A
next
quarter
call
because
I
think
that's
the
several
ideas
and
they
go
side
against
each
other,
but
they
might
need
to
be
fleshed
out
a
bit
more,
whether
it's
sort
of
the
timeframe
recoverability
or
if
we
do
a
breaking
change,
then
to
how
we
show
we
have
a
path
to
forget
ability
in
some
way
we
can
limit
the
scope
by
creative
solutions
and
so
on.
I
think
this
difference
of
there's
multiple
options
here
that
we
can
explore,
but
it
probably
requires
asynchronous
effort.
A
J
J
So
tomorrow
there
is
a
meeting
in
the
state
whose
agenda
that
I'm
going
to
present
the
swarm.
What
is
the
idea
that
is
being
to
the
develop
it
in
top
democracy,
basically
how
it
works
and
why
it
works
like
this,
and
so,
if
you
are
interested
in
democracy
and
centralized
the
autonomous
organizations-
and
this
can
be
used
in
many
creative
ways
once
it's
created.
So
my
might
be
interesting
to
many
people.
H
So
I
think
this
is
the
the
next
logical
step
in
terms
of
having
reproducible
builds
right.
Now
we
we
host
status
code
artifacts
in
digitalocean,
so
it's
kind
of
a
hand,
roll
solution
which
really
isn't
required.
Now
that
we
have
we
hosted
in
this
in
this
mix
cache.
So
we
could
just
make
status,
go
another
mix
package
ideal.
You
also
make
the
same.
H
Downloads
during
the
the
builds
that
are
handled
by
us,
it's
a
matter
of
consistency
with
all
the
other
packages.
I,
don't
know
if
there's
anything
anything
against
this
or
if
it's
like
logical
for
everyone,
I,
don't
know
it
might
be
like
for
people
who
are
working
barely
on
status
Co,
that's
maybe
the
people
who
will
be
more
impacted
by
this.
H
So
it
would
just
require
that
you
do
make
shell
and
ensure
that
you're
inside
of
this
special
shell
from
mix2
to
build
your
app.
But
it's
not
a
big
deal.
You
know
from
the
experience
with
cities
reacted,
it's
not
a
deal
breaker,
but
I
would
be
interested
in
hearing
there
anything
going
forward
with
this.
No.
B
Just
one
question
is
there
so
when
we
publish
a
new
version,
it
just
get
auto,
publish
to
me
immediately
or
do
it.
How
does
it
work
because
right
now,
a
publisher
just
when
you
have,
for
instance,
and
it's
like
there
is
no
approval
process,
nothing
like
this
and
if
we
add
it
to
the
mix
as
a
new
version
well.
H
In
the
recipe
so
status
reacts,
it
has
these
these
next
files,
so
you
would
determine
there
one
basically
in
the
same
way,
isn't
where
we
change
status,
go
version
file.
Instead,
us
react
instead
of
doing
it
there
you
would
do
inside
the
next
recipe.
Saying
okay,
I
want
to
use
this
hash
of
of
telesco,
and
then
it
was
either
build
it
or
download
from
the
cache,
but
it
would
do
so
in
every
reproducible
way.
B
A
D
Yeah
I
guess,
if
you
can
hear
me-
probably
yes,
so
we
like
have
the
last
change
to
be
integrated,
at
least
for
mobile
app,
unfortunately,
for
desktop
I
I
will
need
Batali's
help
to
talk
about
the
progress
there,
because
again
we
have
desktop
used
to
communicate
and
mobile.
So
for
mobile
we
almost
ready
for
desktop
honestly
I'm,
not
sure
yet.
D
So,
if
you
today
is
in
the
meeting,
please
tell
about
about
it,
if
not
and
probably
will
need
to
sync
right
after
this,
but
again
for
desktop
it's
a
bit
easier
because
they
don't
need
any
Apple
approval
process
in
test
flow,
etc.
So
they
can.
They
do
have
a
bit
more
time
to
to
make
a
release
for
yeah.
D
D
Like
simple
user
oriented
messaging
like
okay,
you
will
not
be
able
to
send
transaction.
You
will
have
like
internal
server
error.
I
will
not
see
a
transaction
history
and
blah
blah
blah,
but
in
general
yeah.
Also
after
after
we
add
the
last
must
changed
mobile
up
as
Adam
suggested.
We
might
probably
not
might,
but
we
will
test
also
on
stage
in
fleet
and
just
to
have
complete
end-to-end
scenario
on
like
in
in
the
play
and
see
that
actually
it
works
without
affecting
Vita
fleet.
D
So
without
affecting
our
users
who
use
releases
and
as
I
sexually
it
again,
it's
it's
one
day
so
yeah
it
will
be
a
bit
ugly.
I
mean
this
pop-up
warning
and
yeah.
It
will
give
you
a
feeling
on
what
is
the
world
results
and
relay
services
and
how
you
can
do
with
this
and
what
you
can
do
to
actually
make
it
work
in
any
way
and
so
yeah,
let's
see
if
eager.
If
you
want.
E
A
B
A
A
A
Hope
so,
let's
see
you
always
get
something
else.
A
D
Can
talk
from
testing
perspective,
so
we
still
don't
have
this
separate
column
for
ready
for
auto
tests
or
whatever,
probably
just
because
the
NICS
PR
was
to
be
cold
and
bad
rent
anton
needs
to
like
need
to
work
together
on
this.
I
think
several
times
Anton,
but
I
still
don't
see
this
oh
and
again,
I'm,
not
sure
Padre.
If
you
can
shed
some
light
on
this
because
right
now,
it's
not
practical
to
expect
that
on
review
stage,
we
will
have
all
the
tests
run
again
because
of
different
reasons.
D
H
I
remember
there
was
an
issue
yeah.
Unfortunately,
it's
been
like
three
or
four
weeks
since
I
last
touched.
That's
so
I,
don't
recall
the
exact
reasons,
but
yeah
there's
there's
a
lot
of
situations
which
which
can
go
wrong
in
the
in
in
triggering
that,
but
basically
I
all
need
to
have
some
time
to
to
look
into
its
again
and
figure
out.
What
was
the
issue
but.
D
D
A
D
A
F
B
A
So
maybe
not
I'm
not
sure
how
that
means
things
work
on
the
github,
ok
and
then
I
guess
to
us
a
brief.
Maybe
if
there's
some
very
follow
up
or
comment
on
the
products
very
amount
on
mention
it
in
the
in
there
p.m.
Fred,
but
just
for
other
people.
Do
you
want
to
briefly
mention
there's
this
estate
of
of
that
research
and
like
possible
next
steps.
I
Can
do
sir
I
looked
into
basically
being
able
to
test
they
are
without
you
know
like
essentially
order
you
I
could
so
it
is
technically
possible.
You
will
need
two
separate
processes
completely
because
refrain
database.
It's
like
a
single
one,
and
you
know
we
definitely
want
to
test
some
of
the
frame
logic,
because
it's
the
most
complex
you
would
need
to
basically
touch
everything.
You
know
from
components
from
the
UI
components
at
the
moment
is
a
bit
coupled,
and
so
that
requires
a
bit
of
refactoring.
I
After
that
you
are
able
to
run
and
to
purchase
processes
inside
a
docker
container,
and
so
that's
where
you
see
what
I
got
it
is
possible
at
the
moment
you
know,
like
I,
haven't,
separated
the
components
and
therefore
is
like
the
resulting
docket
images
or
lists.
You
know
like
the
docker,
not
don't
get
image,
but
just
the
Dex
Dex
file
is
14.
400
megabytes
just
big,
but
that's
because
of
the
UI.
I
A
I
A
F
A
Yeah,
we
can
I
think
you
will
make
about
in
a
weekend.
Maybe
there's
sort
of
things
we
can
factor
out
like
there's
some
refactoring
tasks,
if
that's
seen
as
a
blocker
whatever,
and
then
we
can
see
what
other
contributors,
what
matter
if
they
can
work
and
we
can
maybe
bring
it
up
in
general-
call
call
sort
of
quorum
call
later
all
right.
Anton.
Do
you
have
anything
you
want
to
say
on
the
automated
testing
side
of
things.
D
Yeah,
so
basically
I
estaciĆ³n
is
ready.
It's
it
can
be
run
locally,
but
this
issue
is
our
sole
swab,
whatever
provider
a
way,
we
run
our
tests
like
for
PRS
for
nitrous
etcetera
and
it
doesn't
work
there.
There
is
extensive
description
like
what
is
the
problem.
Basically,
it
starts
this.
The
launching
op
takes
like
eight
minutes
or
so,
and
it's
unusable
in
this
state.
So
we
waiting
for
customer
support
from
sound
swabs
to
boom.
Yeah
solve
this
issue,
and
it's
almost
like
two
weeks
since
we
did
did.
A
D
It
works
fine,
so
there
is
something
specific
to
our
app
and
they
don't
tell
what
they
don't
tell.
What
is
exact
problem,
but
they
say
yeah
we
are
looking
into
it.
Our
dev
team
is
looking
into
it.
There's
not
like
some
customer
support
guy.
You
know
playing
this
rounds
of
checklists.
They
have.
It's
really
like
already
moved
to
to
the
dev
team
and
dev
team
doesn't
give
any
clue
on
what
it
is
and
when
it
will
be
fixed,
etc.
It
was
March
12.