►
From YouTube: Core Dev call #36
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
B
C
C
So
the
current
styles
of
accurate
v2
is
that
we
still
focus
on
track
track,
one
which
is
essentially
moving
to
getting
basically
b2b
integration.
Last
week
we
launched
and
had
the
kind
of
internal
test
net
called
nangang.
It
does
very
little,
but
it
allows
us
to
test
basic
assumptions
and
it
works
across
network
and
it's
integrated
with
the
cluster
and
so
on,
and
with
this
we
moved
the
main
spec,
the
vacuum
spec
to
draft,
as
well
as
the
reader
spec.
This
is
a
link
to
that
as
well.
C
If
you
can
have
a
look
at
how
the
specs
are
structured,
the
historical
to
the
store
and
filter
protocol
are
still
a
work
in
progress.
The
store
is
essentially
the
the
new
historical
mail
server,
whatever
replacement
and
filter
protocol
is,
is
sort
of
for
life
notes,
similar
to
what
we're
having
with
the
background
behavior
in
back
v1.
C
The
encryption
spec
is
still
sort
of
being
considered.
We
haven't
spent
too
much
time
out
yet
we
hope
we
do
that
soon.
There
is
an
open
issue
and
feedback
and
discussion
is
definitely
welcome
there
as
well
as
in
this
call.
If
people
have
any
strong
opinions
right
now
when
it
comes
to
integration
timeliness
on
yeah,
I
think
all
integration,
that's
that
largely
still
depends
on
on
resources
for
for
stimulus,
largely
from
service
pick
an
api
point
of
view.
It's
it's
ready
already
to
do
basic
initial
integration.
C
My
understanding
said
that
that
could
be
one
is
sort
of
it's
started,
but
it's
still
experimental.
So
I
would
suggest
that
whenever
we
feel
ready
to
sort
of
start
integrating
v2
with
simbus,
then
then
we
can
talk
about
that
and
go
from
there,
and
obviously
things
will
still
change
with
the
ap
and
so
on,
but
we
have
enough
to
get
started.
C
I
also
got
because
there's
been
some
discussion
about
having
back
running
in
the
in
the
browser,
and
I
got
the
very
basic
proof
of
concept:
hacky
version
up
and
running
just
to
make
sure
that
we
have
connectivity.
So
essentially,
it's
running
in
the
browser,
it's
based
on
the
dsl,
pdp
examples
and
some
hackery
and
it's
it's
web
bar
to
see,
and
then
you
have
in
the
browser
and
then
you
have
a
node
client
and
signal
server,
and
then
this
communicates
within
backup.
C
So
it
essentially
works
end-to-end,
but
it
doesn't
do
much,
but
it
at
least
shows
that
we
can
do
it.
And
if
this
is
something
you
want
to
prioritize,
there's
a
starter
vac
and
the
vacuum
won't
have
probably
want
our
resources
to
push
it
as
an
implementation
right
now.
But
if
someone
wants
to
run
with
it
definitely
definitely
go
for
it
and
then
ping
me
and
back.
We
can
figure
out
how
to
make
sure
it's
up
to
spec
and
how
to
planet
them
progresses
on.
C
We
also
have
one
to
two
hires
that
are
joining
one
I
think
next
week
and
then
one
half
time
beginning
of
october.
We
still
figured
out
and
they
are
sort
of
protocol
engineers
and
they
are
going
to
be
more
focused
on
a
privacy
aspect
and
so
on
and
really
excited
to
have
them
yeah
more
details
to
come
on
that
and
hopefully
it'll
be.
C
One
of
these
course
introduce
themselves-
and
this
was
gonna-
be
a
more
detailed
breakup
soon
and
when
it
comes
to
specific
blockers
or
questions
the
best
place,
probably
hashtag
baku
or
specific
github
issues
in
the
specs
repo
or
nimbakkurico
yeah.
So
that
wasn't
see
me
reading
the
update,
but
for
people
who
don't
have
it
open?
I
guess
any
questions
on
that
or
comments.
D
E
E
So
so
this
brings
us
topic
kind
of
related
to
our
cook,
kind
of
which
is
the
murmur,
because
I'm
getting
paint
about
that
a
lot
because
murmur
needs
to
be
updated.
If
we
we
actually
want
to
use
it.
But
with
this
effort,
is
there
a
point
to
do
that?
Should
we
just
go,
should
we
just
focus
on
the
waku
javascript
instead,.
C
I
think
it
depends
on
who's
going
to
push
it
and
what
the
exact
requirements
are,
because
I
think
there's
probably
some
overlap
there.
I,
I
guess
murmur
is
definitely
more
field
featured
in
in
the
sense
that
I
think
it
implements
part
of
the
the
stats
protocol
and
it's
it's
operating
with
the
backup
v1,
which
is
live
already.
So
if
it's
a
matter
of
having
interrupts
like
this
week
or
next
week,
with
with
the
with
this
status
protocol
murmur
might
be
a
good
start.
C
But
if
this
is
something
maybe
more
medium
long
term-
and
there
are
also
consumers
that
are
outside
of
the
status
protocol
and
app,
then
it
might
make
sense
to
push
this
more
actively.
I
do
think
there's
probably
some
overlap
there
as
well,
and
maybe
we
can
talk
more
about
that
offline
when
it
comes
to
steambus
and
because
like
when,
in
the
name
back
to
codebase
right
now,
we
have
v1
and
v2,
and
then
you
have
the
source
protocol,
that's
on
top
of
it,
which
largely
is
in
in
status,
go
and
so
on.
C
E
C
A
C
E
Well,
actually,
probably
probably
quite
soon
or
even
next,
it's
just
that
we
we
wanted
to
do
some
business
integration.
When
I
guess
we
started
with
v1
just
just
to
see
if
there
would
be
any
trading
issues,
integration
issues
and
things
like
that
and
it
seems
like
it
works
fine
with
just
using
some
pure
packages.
E
So
it's
not
signing
or
something
just
sending
a
package
that
already
exists
and
listening
to
it.
So
we
see
that
works
and
it
doesn't
seem
to
be
an
issue
on
desktop
we're
waiting
for
some
integration
on
on
mobile,
which
I
believe
should
be
ready,
or
maybe
it's
ready
this
week
to
see.
Also
if
that
works
fine
there
and
then,
if
all
is
clear,
then
we'll
continue,
and
I
don't
know
I
guess
we
might
go
directly
to
v2
but
well
I'll.
Let
you
see.
C
Well,
it
sounds
good
because
it
would
both
be
good
to
a
good
point,
then
to
just
do
some
integration
and
also
get
some
feedback
on
on
the
api
and
the
direction
there,
because
there
is
some
differences
there
that
we
have
to
still
have
to
reconcile
and
figure
out
best
how
to
do
that,
which
maybe
brings
to
the
next
thing,
which
is
the
question
on
the
encryption
topic
and
so
on.
If
people
have
any
any
anything,
they
want
to
discuss
here
or
people
refer
to
that,
they
think
I
don't
know.
C
What
I
mean
by
that
is
that
the
way
with
protocol
worked,
it
was
kind
of
tightly
coupled,
so
you
had
to
have
this
encryption
as
part
of
the
routing
and
that's
probably
less
than
ideal
for
a
bunch
of
use,
cases
and
separation
concerns
and
so
on.
At
the
same
time,
the
coincidence
protocol,
partly
if
my
insurance
correct,
relies
on
some
of
the
those
features
to
get
this
sort
of
security
guarantees.
So
as
we're
decoupling
these,
so
we
have
the
routing
and
so
on
decoupled
from
the
encryption.
C
It's
a
question
of.
Where
does
that
leave
the
sort
of
previous
encryption
we
were
doing,
because
you
could
imagine
that,
with
the
current
routing,
you
put
the
conversational
security
protocol
on
top
of
vacuum
v2
and
you
would
get
some
encryptions
on,
but
maybe
that
would
lead
to
some
sort
of
trade-offs
and
the
interface
would
look
slightly
different.
Andrea
knows
more
about
the
specifics
of
what
what
might
be
lost
there.
C
So
it's
a
question
of
like
compatibility
and
where
we
get
sort
of
specific
encryption
guarantees.
If
that
makes
sense,
and
and
it's
a
question
of
how
you
wanna.
However,
you
wanna
structure
that,
because
you
could
imagine
that
you
have
a
separate
module
where
you
do
the
encryption
that
whisper
kind
of
did
before,
or
maybe
this
is
a
a
chance
to
simplify
things,
given
that
we
we
have
like
multiple
layers
of
encryption,
so
that's
the
kind
of
the
decision
to
make
or
yeah.
I
don't
make
sense.
B
B
C
B
B
There
is
something
metadata,
for
example,
sender
and
receiver,
and
so
it's
a
matter
of
understanding
what
we
want
to
do,
then,
if
we
want
to
have
you
know
like
correct
me
if
I'm
wrong,
wacko
handling
these
essentially
or
we
want
to
address
it
on
our
side
by
essentially
like
moving
towards
something
like
oh
double
ratcheting,
cryptic
payloads
equip
the
deaders,
which
will
require
a
significant
change
in
the
product.
The.
F
C
Yeah,
I
think
so
one
maybe
thing
to
take
it
account.
Is
that
what's
happening
at
keyless
and
so
on
there
there
is
already
encryption
at
the
transport
layer
right,
which
is
better
than
the
one
that
works
in
in
in
devp
and
so
on.
It's
just
that's
from
peer-to-peer,
that's
from
on
the
phbla
right.
So
that's
not
end
to
end.
In
that
sense,
yeah
yeah,
yeah.
C
B
C
Yeah,
so
I
guess
there
might
be
certain
trade-offs
that
are
make
more
sense
for
the
status
app
because
of
not
wanting
to
change
the
protocol
when
it
works.
That
might,
and
that
might
look
slightly
different
for
something
that
would
connect
or
other
users.
So
that's
sort
of
where
maybe
there's
some
compromise
that
can
be
found
where
you
enable
both
and
then
so
depends
on
the
specific
deployment.
But
honestly.
B
F
B
Guess
that's,
you
know,
like
that's,
probably
something
that
you
know
we
can
take
it
offline.
I
take
it's
going
to
be
a
discussion
that
we're
unlikely
to
probably
resolve
here
from
the
core
perspective.
Obviously,
like
you
know,
since
the
feature
has
been
will
be
removed
from
the
protocol,
and
we
will
have
to
address
that.
B
Maybe
it's
good
to
decouple
that
a
bit
and
no
workout
to,
for
example,
deal
with
encryption
and
a
separate
component,
but
there's
a
lot
to
consider,
unfortunately,
because
as
well,
some
messages
that
in
the
city's
vehicle,
are
only
encrypted
by
whisper
for
reasons
and
which
I
don't
remember,
no,
we
will
have
to
look
into
that.
So
it's
a
bit
more
complicated.
It's
not
just
for
the.
C
B
B
Yes,
yeah
yeah.
I
think
we
need
to
on
our
side.
I
think
we
need
to
sort
of
cut
it
up,
look
at
the
code
base
and
understand
which
messages
are
sent
with
the
double
russian
which
messenger
sent
without
double
ratchet
and
understand
as
well,
because
we
kind
of
have
a
solution
already,
so
that
would
be
encrypted
as
a
double
ratio
understand
what
the
effort
is
and
compatibility
issues,
because
obviously
there's
going
to
be
compatibility
issues
because
clients
do
not
expect
an
encrypted
data.
B
Okay,
so
we
can
move
then
do
the
next
point,
which
is
review
previous
actions,
so
we
didn't
have
explicit
actions
last
time.
What
we
discussed
was
about
pictures
and
I
believe
summer
will
give
an
update
in
the
next
section.
So
probably
it's
best
to
talk
about
it
later
and
then
we
are
looking
at
a
bit
of
a
bug
which
is:
was
the
setback
value
rounding,
we're
gonna
post
this
in
chat,
we're.
B
I'm
not
sure
we
have
found
still
the
root
issue
of
my
feeling
is
that
we
convert
json
into
like
we
convert
this
value
into
an
integer
and
it
gets
probably
truncated
by
javascript,
because
you
know,
like
integers,
have
a
maximum
value,
and
so
so
that's
my
feeling,
but
still
we're
definitely
addressing
the
issue.
So,
if
there's
nothing
to
say
about
this,
we
can
just
skip
it.
Anyone
has
any
comment
on
this.
D
D
B
B
Okay,
thank
you
very
much
for
the
update,
so
we
can
move
forward,
so
the
next
step
would
be
our
organization
channels.
So
basically,
that's
the
pr
that
I've
got
out
is
still
in
draft
mode,
as
you
know,
we're
trying
to
move
forward
with
organization
channels,
so
this
is
basically
a
very
basic
implementation
of
the
protocol.
B
What
I
would
like
to
discuss,
if
anyone
has
got
some
opinions
about
it
is
essentially
like
this.
You
know
they
can
give
a
brief
explanation
of
what
it
is.
So
essentially
we're
gonna
have
organizations
with
members.
You
know.
That's
really
all
you
have
to
all
that
you
have
to
know
for
now
and
like
in
order
to
understand
what
the
issue
is,
and
we
do
not
have,
as
you
probably
all
know
like,
we
don't
have
set
decentralized
storage.
So
what
we
generally
do,
we
do.
B
So
we
will
be
propagating
a
membership
list
of
the
member
in
the
organization
for
new
joiners
or
people
who
have
not
joined,
and
what
I
would
like
to
discuss
is
basically
what
happens
when
you
retrieve
those
messages
from
the
mail
server,
because
in
some
cases
you
will
basically
retrieve
messages
posted
in
this
channel
before
you
actually
receive
the
last
membership
update,
so
you
will
have
a
user
who
has
been
added
to
the
organization,
but
you
haven't
received
the
conversation,
the
confirmation
for
that
user.
So
you
you
know
like
if
you
want
to
implement.
B
B
So
the
idea
that
I
was
thinking
about,
like
your
opinion
on,
is
basically
like
what,
as
a
user,
joins
the
organization,
the
creator
or
whatever
the
moderator
is
going
to
issue
a
grant
which
is
basically
a
signed,
invitation
or
assigned.
You
know
like
acceptance
of
membership,
which
will
tell
you
basically
like
the
clock
value,
the
user.
That
is
being
you
know,
accepted
into
the
members
into
the
organization
and
when
posting
the
user
will
piggyback.
B
B
So
you
need
to
be
very
careful
with
what
kind
of,
for
example,
like
side
effects.
You
have
on
messages,
so
you
wouldn't
be
processing
transaction
based
optimistically,
but
in
certain
assets
generally
fine,
and
that
alleviates
a
bit
the
issue
and
makes
it
a
bit
simpler
and
it
handles
the
most
generic
use
case
where
the
user,
just
you
know
whether
you
haven't
received
yet
the
the
the
membership
list.
Otherwise
you
get
into
like.
Oh,
I
fetched
first
their
membership
list,
and
then
you
get
the
messages.
But
then
you
get
into
trouble
with.
E
So
I
have
a
suggestion
like
at
least
a
possibility
to
alleviate
the
messages
load,
because
if
we
include
the
list
of
members,
it
looks
like
it's
way
too
much
or
can
potentially
be
way
too
much.
So
one
idea
could
be.
We
include
a
bloom
filter
instead
and
the
clients
can
do
a
quick
check
if
the
message
are
receiving
belongs
to
that
filter.
E
B
F
B
E
B
That's
possible,
you
know
like
you
can,
but
at
the
end
of
the
day
I
mean
we're,
not
gonna,
be
solving
network
spam
here
really
right,
but
what
you
can
do.
For
example,
you
can
already
preset
a
filter
with
a
given
public
key,
so
these
messages
will
never
surface
on
or
you
know
they
will
not
even
be
you
know
they
would
be
decrypter,
but
you
know
like
essentially
like
they
will
be
stopped
at
what
level,
but
we're
not
going
to
be
solving
any
network.
B
E
B
B
B
B
A
Any
community
chat,
basically
whether
it's
public
or
not,
because,
as
I
understand
it,
it's
still
like
in
a
way
a
public
chat.
Just
the
invitation
is
restricted.
Currently
in
a
public
chat,
we
don't
allow
images
for
some,
I'm
not
sure
to
what
extent
that's
to
limit
traffic
or
because
we
don't
want
to
allow
sending
images
in
in
public
chats.
A
B
B
D
This
is
basically
a
data
packet
that
the
user
or
the
holder
of
a
private
key
generates
and
the
and
they
use
this
as
their
representation
of
who
they
are,
and
so
what's
proposed.
Currently
are
are
three
things:
one
is
the
e
s
name,
one
is
a
display
name
and
then
the
the
other
component
are
profile
images.
D
So
in
this
particular
spec,
it's
profile
image,
singular
I'm
working
on
an
update
to
include
multiple
profile
images.
I
realize
that
there
is
a
circumstance
where
we
we
need
more
than
one
payload,
so
I
just
want
to
check
if
anybody
has
any
objection
to
the
use
of
display
name,
if
they
don't
that's
great
and
we
can
move
ahead
with
it,
but
basically
this
would
be
the
display
functionality
would
be.
F
D
D
F
F
D
Of
course,
so
we
could
do
snp
staking
at
a
later
point
when
we
have
a
layer,
two
solution
in
place
and
when
transaction
costs
in
that
case
would
be
significantly
lower.
I
still
think
there
would
be
a
use
case
for
non-ens
usernames,
but
basically
I
just
didn't
want
this
to
fly
under
the
radar,
because
I'm
I
am
basically
implementing
this.
Unless
anybody
says
I
have
a
good
reason
not
to.
B
B
So,
for
example,
my
main
concern
is
with
the
specific
image,
for
example,
is
that
you
know
the
user
is
not
able?
You
know,
we
need
something
for
identification
that
needs
to
be
constant
in
the
ui
and
whether
that
is
the
free,
random
words
username
or
whether
that's
the
public
key.
I
think
it
should
always
be
displayed,
so
that
user
has
something
he
can
trust
that
will
not
change
does
not
change,
because
we
both
know
that
user
set
user
name
will
change
and
dns
name
does
change
and
so
like.
D
B
He's
not
changed
with
this
he's
also
on
board
with
we
spoke
after
and
I
think
he's
okay
with
having
the
public.
He
he'd
rather
have
the
public
in
the
pre-works
user
name,
but
it's
easy
to
change.
Yeah
and
another
concern
is
that
now
we
have
local
nicknames
as
well
yeah,
and
so
I
mean
I
think
we
should
sort
of
like
okay.
If
we
want
to
you
know,
throw
things
at
the
world
and
see
whether
they
stick.
B
B
I
don't
see
the
reason
to
have
all
three
of
them
and
so
like
I
would
sort
of
like
if
we
decide
to
go
forward
with
this,
which
I
have
I'm
not
against
it.
We
just
need
to
say:
okay,
is
this
going
to
be
a
temporary
period?
We
have
where
we
are
going
free
or
maybe
we
want
all
three
but
there's
something
that
we
need
to
discuss.
I
think
I
think
that's
that
seems
to
be
very
confusing
for
the
user
yeah,
or
is
this
going
to
be
the
place
in
local
nicknames?
I
think
it's
just.
F
Totally
agree
with
andrea:
this
is
the
splay
lamps,
have
no
guarantee
of
uniqueness
or
any
kind
of
they're,
not
trustable
in
any
way
regarding
the
identity
of
the
person.
So
this
is
just
asking
for
phishing
or
whatever
else
people
can
come
up
with
and
also
yeah
the
point
about
releasing
other
things
they're.
Both
the
local
links
which
people
have
been
asking
for
for
all
time
and
display
names
would
be
also
kind
of
weird.
F
A
I
I
wanted
to
suggest
the
same
almost
because
I'm
very
much
in
favor
of
adding
adding
display
names
and
like
to
me.
It
runs
on
a
different
timeline
and
adding
local
nicknames.
Local
nicknames
is
an
attempt
to
solve
the
same
problem
that
people
have
a
difficulty
understanding
who
they're
talking
to
when
they
look
at
a
three-word
random
name
and
it's
expensive
to
register
an
ens
name.
A
A
I
think
we'll
get
back
that
people
would
still
want
to
change
their
display
name
and
we
might
want
to
jump
from
allowing
to
create
a
nickname
to
promoting
more
creating
a
a
display
name,
because
the
confusion
starts
when
you
have
no
control
over
it
right.
If
you
create
a
like
a
local,
nickname,
you'll
know
that
you've
done
that
for
a
particular
user.
A
D
F
F
Do
you
accept
it,
or
do
you
want
to
set
your
own?
So,
by
default
a
person
wouldn't
show
up
as
the
display
that
they
set
only
after
you've
added
them
as
a
contact?
Would
they
because
you
you
consciously,
you
looked
at
it
and
said?
Yes,
this
is
explaining
matches
with
what
I
I
want
the
person
to
be
called
right,
yeah.
D
So
I
think
so
the
root
problem
that
we're
trying
to
solve
here
marketing
says
that
people
absolutely
hate
three,
the
three
word
username,
they
hate
it.
They
absolutely
cannot
stand
it,
and
particularly
in
countries
where
english
is
not
people's
first
name,
their
first
language
or
people,
don't
even
speak
english,
which
is
the
vast
majority
of
the
world.
D
These
don't
really
mean
very
much
so
there
have
been
potential
solutions
whereby
we
do
translations
into
local
languages,
and
I
think
the
more
simple
solution
is
just
to
give
the
power
to
the
individual
to
define
what
they
what
they
want
and
going
to
your
point
yaakov.
If,
if
we
don't
show
the
display
names
by
default,
then
we
are
sort
of
neutering
to
some
degree
the
ability
of
the
user
to
present
an
identity
that
that
they
have
chosen
for
themselves.
E
So
so
yeah
I
like
suggestion-
or
for
this
not
suggestion,
but
I
guess
there's
just
a
thought.
I
I
wanted
some
also
what
we're
calling
if
it's
a
bit
confusing
because
we
took
this-
is
user
names
other
ones.
These
are
names,
two
also
called
user
names,
and
most
people
have
local
usernames.
That
doesn't
mean
much
to
them.
E
G
G
C
D
The
the
three
word
pseudonym,
I
think
we're
just
still
going
to
call
that
three
words
pseudonym
and
then
the
local
nickname
is
is
going
to
be,
is
currently
what
we
call
the
what
what
what's
going
to
be
rolled
out-
and
I
think
is
it
1.7
local
nicknames
is
coming,
so
we
do
have
distinct
words
for
them.
I
think
when
people
are
talking
about
it
generally
and
not
conscious
of
the
specific
terms,
people
just
say
username
and
it
it
does,
it
is
quite
confusing
we
do
have,
though
distinct
terminology
for
the
things.
D
D
A
Yeah
just
to
add
to
my
comment:
this
is
this
is
getting
to
a
state
where
we
can
definitely
like
where
we
can
and
should
test
whether
it
works
before
we
release
it.
It
shouldn't
be
shouldn't
be
too
hard,
but
it
does
require
some
some
effort
to
make
it
valid
more
than
a
static
figma
screen
and
like
another
thing
would
be
that
I
noticed
there's
no
one
of
the
security
team
on
this
call,
so
that
would
be
something
to
discuss
separately.
B
Yeah,
just
to
add
that
I
think
you
know
we
should
be
a
bit.
I
mean,
I
think
to
me
like
it
feels
like
we're,
not
really
thinking
things.
You
know
like
very
thoroughly
when
it
comes
to
usernames.
I
think
we're
just
you
know
like
just
throwing
things
just
throwing
things
at
the
wall
and
see
what
the
death
and
see
what
it
sticks.
I
think
before
we
do
any
implementation
of
this,
I
think
we
need
to
really
have
a
cohesive
strategy,
because
there
are
things
that
are
clearly
obviously
a
problem
like
you.
B
About
it,
if
you
combine
local
nicknames
and
you
get
displayed
together
in
the
mix
like
immediately,
you
see
problems
happening.
For
example,
I
am
talk
by
my
phone,
because
local
nixon
are
very
similar.
To
my
you
know,
like
my
contacts
agenda,
I
said
the
name
that
I
can
trust
what
I
said
right.
You
know
like
if
I
save
a
user,
a
samwell.
C
B
So
if
you
add
display
names
in
the
mix,
then
okay,
so
you
you
have
there
an
avenue
for
people
to
impersonate
someone,
and
I
don't.
I
can't
really
trust
this
anymore
unless
it's
very
clear
the
distinction
and
then
it
means
that
you
know
okay,
you're,
then
you're
left
to
have
another
this
yet
another
distinction
that
it
shows
me
visually
that
you
know
the
local
nickname
is
not
the
same
as
the
display
name,
which
is
not
the
same
as
the
ns
name.
So
we
start
creating
a
lot
of
rules
that
the
user
needs
to
abide.
B
You
know
by
to
to
use
the
apps
safely
and
the
more
rules
they
are,
the
less
safe.
The
app
is
right
because
the
more
complexity,
you
add,
the
more
problems
they're
going
to
sneak
through
so
to
me
like
it
feels
like
really.
We
should
simplify
it
other
than
the
complexity
on
top,
and
I
think
before
we
go
into
implementation,
we
need
to
figure
it
out.
B
As
esther
said,
I
think,
with
security
team
ui,
you
know
we
need
to
be
a
bit
involved
to
just
give
a
crazy
strategy
to
this,
because
we
keep
going
a
bit
in
circles
with
uniqueness.
We
had
them,
we
don't
have
them
anymore
and
now
we're
moving
forward
so
that
we're
going
to
be
that
before
we
start
an
implementation
which
is
going
to
be
costly,
we
just
need
to
sort
of
like
regroup
a
bit.
D
D
This
was
just
another
use
case
for
it,
let's
define
the
strategy
and
if
we
choose,
if
we
decide
that
that
yours,
your
own
display
name
is,
is
not
desirable,
then
that
does
that
will
be
fine,
but
I'm
happy
at
least
with
the
conversation
that
we've
had
here.
I
wanted
to
know
what
these
feelings
were
and,
like
I
didn't
feel
like
I
would.
I.
D
B
D
Okay,
I
didn't
well,
I
did
say
I
was
going
to
stop
there,
because
that
was
just
on
display
names,
so
profile
images
is
like
another
use
case
of
chat
identity,
so
the
profile
images
I
think
we're
going
to
go
ahead
with
after
a
a
good
deal
of
experimentation
and
proof
of
concepting
build
a
prototype
that
can
take
images
and
and
can
consistently
generate
profile.
Thumbnail
images
that
are
power
are
at
most
2.5
kilobytes
in
size,
on
average
they're
about
two
kilobytes
in
size.
F
D
And
then
for
like
the
larger
image
that
can
come
up
in
and
be
displayed
after
some
experimentation
and
various
things,
16
kilobytes
seems
to
be
the
the
ceiling
of
decent
quality.
So
these
are
so
this.
If
you
imagine
a
use
case,
you
click
on
a
contacts
image.
You
want
to
see
it
larger,
for
whatever
reason
it.
It
shows
you
a
larger
version
so
that
the.
G
D
2
kilobyte
thumbnail
wouldn't
really
show
in
all
that
great
quality,
but
we
can
show
you
that
this
would
be
a
240
pixel
by
240
pixel
image,
and
we
can
get
that
to
16
kilobytes,
that's
the
maximum.
On
average,
it's
significantly
less
it's
about
10
kilobytes
on
average,
which
I
think
is
very
acceptable,
and
but
these
would
probably
only
be
used
for
one-to-ones
and
group
chats
the
thumbnail
profile.
D
Images
would
only
be
used
that
would
be
used
everywhere,
including
public
chats
as
well,
and
the
work
to
get
the
size
down
was
crucial
for
making
sure
that
a
user
would
always
be
able
to
have
their
their
profile
picture
displayed.
So,
basically,
the
code,
the
real
code
work
starts
this
week
to
implement
that
and
that's
the
update
on
profile.
G
And
then
everything
goes
over
tcp
right,
but
that
can
sometimes
have
issues
because
those
connections
can
be
blocked.
So
the
alternative
here
is
to
do
something
completely
different
and
a
couple
of
alternate
like
a
thing.
A
few
things
have
been
considered.
Websockets
is
an
obvious
one.
It's
a
little
bit
difficult
when
it
comes
to
incoming
connections.
G
G
You
know
just
one
more
communication
path
so
that
when
you're
on
that
wi-fi
in
the
airport,
if
tcp
is
not
working
for
whatever
reason
we
can
always
switch
over
to
a
second
one,
the
work
is
being
done
by
a
new
joiner
to
the
p2p
team
mark.
So
if
you
want
to
pop
by
and
say
hello
to
him
and
talk
about
quick,
then
join
the
live,
b2b
channel
thoughts,
questions
better,
take
them.