►
From YouTube: Core Dev call 34
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
I
think
it
just
needs
review,
I'm
not
sure
has
ever
been
reviewed,
so
just
push
notification
server
and
some
updates
on
before
we
were
using
a
single
entry
for
each
device
for
all
the
devices
you
had
and
now
we
use
different
entries
for
each
device
you
have,
and
that
makes
basically
no
difference.
It's
just
that.
We've
seen
that.
B
A
B
C
B
C
Andrea
will
not
be
able
to
give
an
approval
because
he's
now
a
co-author,
so
anybody
that's
in
call
rajiv,
has
given
comments
but
has
not
actually
approved
or
unapproved,
so
they
can
just
need
somebody
to
to
re.
Read
this
and
then
and
and
then
we
can
merge
it,
it's
effectively
ready.
In
fact
it's
it
might
need
to
change,
because
this
is
a
draft,
but
it's
in
production.
So
we
might
as
well
fold
this
into
these
stable
specs.
C
B
C
A
So
another
reason
would
be
performance.
You
know,
because
you
know
dimension
performance.
Just
just
clarification.
So
basically
is
the
passing
of
the
message.
So
what
we
want
to
do
is
there's
going
to
be
an
auto
complete
and
that
autocomplete
will
basically
client
side,
so
not
statistical,
but
it
plays
dimensions,
but
also
we
want
to
say
if
you
don't
use
the
complete
and,
for
example,
you
just
write,
but
you
don't
actually
click
on
the
autocomplete.
A
We
want
that
message
to
be
passed
as
an
extra
step,
just
to
make
sure
that
we
catch
all
the
all
the
dimensions
that
that's
what
we
were
actually
talking
about.
I
believe
romanesque
has
made
more
context
yeah
and
so
whether
we
want
to
have
the
same
behavior
in
that,
but
we
don't
want
to
have
the
same
behavior
in
that
stuff,
whether
we
want
to
have
the
code.
A
B
A
D
So
this
was
only
when
we
say
performance.
That's
after
clicking
send
message.
There
will
be
some
like
computation,
which
might
take
some
time.
It's
only
about
sending
the
message.
It's
not
about
suggestions,
how
to
complete
and
stuff
like
this.
That's
only
about
performance
when
we
press
this
send
button,
and
I
I
doubt
that
it
will
be
really
noticeable
for
for
the
user,
the
way
how
it
is
implemented
right
now.
E
D
It
is
already
written
in
polarity,
it's
not
like.
We
will
say
anything
if
you
write
it
in
status.
Go
right
now,
because
another
problem
which
we
have
is
that,
as
I
took
this
task
after
eric-
and
he
already
worked
on
this
on
postscript
side,
I
did
not
even
like
I
didn't
think
about
this-
that
we
want
to
have
it
on
status
go.
D
This
is
probably
this
problem
should
have
been
discussed
before
all
this
stuff
as
requirements
of
this
task,
because
there
was
no
requirements,
so
there
was
no,
it
looks
so
for
me,
there
was
no
discussion
about
where
the
code
should
be
placed
and
that's
the
problem
now.
I
don't
know
why
this
question
arised
today
not
like
two
months
ago,
because
it
would
make
much
more
sense.
D
B
D
D
A
So
is
to
the
place,
you
know,
if
you
don't
use
the
autocomplete
right.
Is
it
not
that
that
was
my
internet?
If
you
don't
use
the
autocomplete,
then
you
just
type
at
three
random
world
names.
That's
gonna
get
replaced,
so
that's,
that's
only
was
valuable
to
put
in
status,
but
not
the
rest,
because
the
rest
is
very
much
ui
focused
and
just
started
getting
completely.
D
A
D
Sorry,
if
we
like,
when
we
have
after
complete,
we
suggest
like
names
which
can
be
replaced
with
public
keys
later
and
if,
for
instance,
we
suggest
some
name
which
won't
be
recognized
on
status,
go
site
later
and
will
not
be
passed
after
sending
the
message.
It's
a
problem
right,
but
right
now
how
it
I
I
thought
of
implementation,
where
we
replace
mentions
with
public
keys
only
after
sending
the
message
so
regardless,
if
you
click
on
autocomplete
or
not,
we
do
not
replace
anything
because
well,
it
actually
doesn't
make
sense.
D
A
B
A
A
C
C
You
will
basically
be
exposing
your
your
ip,
so
any
client
any
status
client
that
wants
to
get
that
ens
avatar
has
to
ping
a
server
and
basically,
whenever
you
do
that,
that
means
that
particular
device
is
exposing
unless
it's
using,
maybe
a
vpn
or
something
like
that,
but
we
don't
want
to
have
to
rely
on
that
being
the
case.
We
wanted
to
be
secure.
C
So
we
had
some
other
discussions,
had
a
version,
two
specification,
and
basically
we
came
to
the
conclusion
that
profile
images
while
sort
of
feasible.
You
would
basically
need
to
download
a
lot
of
data
to
make
it
work.
So
maybe,
if
you're,
using
on
a
wi-fi
connection,
it
probably
might
not
be
too
much
of
a
problem,
but
it
could
be
a
problem
if
you're
using
mobile
data.
C
Swarm
came
up,
I'm
not
even
certain
who
came
up
with
the
idea.
I
know
it
wasn't
me,
but
it
was
avatars.
Basically,
you
pre-define
an
image
avatar,
so
it'd
be
something
along
the
line
of
bitmojis.
I
matches
shared
some
examples,
there's
actually
a
document.
That's
currently
on
the
go
at
the
moment.
If
I
can
share
that
in
the
chat.
C
So
this
is,
this
is
one
of
the
document,
one
of
the
documents,
not
the
specification
documents
that
we're
working
on.
This
is
a
new
document
that
mache
has
presented
today,
basically
just
talking
through
how
we
want
to
make
these
avatars
work.
It's
basically
the
the
solution
to
profile
images
in
a
way
that
is
bandwidth
sensitive.
So
what
would
happen?
Is
you
would
compose
your
own
avatar
from
base
components?
C
C
So
any
any
message
that
you
send
could
have
this
identity
avatar
associated
with
it,
and
I
think
that's
as
far
as
we
got,
although
either
I
know
andrea
and
andre
are
also
on
the
call
as
well
and
they've
been
involved
in
that.
So
I
probably
missed
some
things,
so
I'd
be
happy
for
them
to
fill
in
anything
that
I've
not.
A
A
A
C
C
C
C
C
So
I
don't
know
if
that
really
constitutes
an
exhaustive
discussion
of
of
this
topic,
but
I
don't
I
don't
know,
I
think
it's
a
good
idea.
I
and
I
think
it
could
really
work.
So
the
the
short
answer
is:
no,
I
don't
think
so,
but
maybe
we
could
have.
Maybe
we
could
have
that
conversation
to
see
if
there's
anything
else.
B
C
Yeah,
I
think
so.
I
think
this
is
the
purpose
of
the
stage
that
we're
at
currently
so
writing
of
proposals
sort
of
rough
specification
guide
for
what
we're
wanting
to
do
so
in
in
the
conversations
that
we've
had
the
the
intent
has
been
that
we
will
we'll
get
so
far
with
developing
a
sort
of
rough
outline
of
how
we
envisage
it
and
then
kick
it
back
to
marketing
could
go
back
to
the
community
and
basically
say
so
profile.
Images
are
a
thing
that
you
want,
but
they're
not
realistic.
C
B
C
Yeah,
so
we
so
we
basically,
I
was
actually.
I
was
quite
a
proponent
of
profile
images,
but
the
the
main,
I
think
the
main
issue
that
we
came
upon
was
that
you
need
to
be
able
to
have
the
user
decide.
So,
like
you
said,
if
the
user
is
happy
with
high
bandwidth
use,
then
then
the
then
our
version,
2
specification
would
probably
work.
Fine,
actually
2.5
would
be
fine,
where
the
you
would
only
you
download
a
profile
image
for
everybody
that
you
come
into
contact
with.
C
C
B
B
E
The
only
thing
is
all
these
layer,
two
constructions-
they
rely
generally
rely
on
a
some
kind
of
operator
of
the
server
right.
So
the
theory
would
be
that
you
could
the
problem
with
that.
You
know
that's
a
censorship
vector
a
centralization
vector
that
could
you
know,
remove
users,
privacy,
because
they're
just
using
because
they're
not
going
they're,
not
transmitting
through
a
privacy
preserving
protocol.
E
So
if
they
were
able
to,
you
know
that
the
operator
can
can
censor
their
their
transaction.
They
can
withhold
it
from
you,
yeah
from
being
submitted
or
being
included
until
proof,
so
if,
if
they
replace
the
operator
and
just
use,
say
waku
topics
for,
for
you
know
a
poll
or
for
any
kind
of
layer,
two
solution
to
aggregate
the
messages
you
know
now
it
becomes
a
censorship
resistant
way
to
do
it
and
and
privacy
preserving
as
well.
E
E
E
E
E
Well,
so
last
last
we
checked
the
ice.
The
response
I
saw
was
that
it's
expected
you
know
before
your
end.
I
don't
know
if
that's
necessarily
how
long
we
want
to
want
to
wait
to
to
start
using
something
some
kind
of
api
like
this,
and
that's
why
you
know
we're
open
to
ideas
on
how
we
can
use
the
current
version
of
wahoo.
E
You
know
in
the
browser
today
you
know
an
alternative
idea.
We're
exploring
right
now
is
so
there's
three
box
and
they
started
this
ceramic
network
which
three
box
itself
uses
ipfs
for
messaging,
but
ceramic
lets
you
replace
the
the
storage
and
the
transport
layer,
for
you
know
a
different
one
that
you
want
to
use.
E
So
you
could
you
know
we
could
make
like
waku
part
of
that
surround
alliance,
so
that
it's
one
of
the
transport
layers
you
could
use.
But
in
that
case
we
could.
We
could
start
building
some
kind
of
like
like
that,
like,
for
example,
governance
dapps
for
status
today,
using
ceramic
which
will
initially
use
ipfs
to
store
to
aggregate
these
messages
and
so
forth.
It's
not
ideal,
because
I
mean,
because
I
mean
there's
the
privacy
preserving
aspect
of
ipfs.
E
I
don't
think
it
it
gives
you
any
guarantees
as
far
as
privacy,
because
of
the
you
know
the
networking
with
the
way
this
networking
works,
but
it
it
at
least
let
us
create,
let's
say,
gaps
today,
that
on
the
surface
level
function
you
have
the
same
type
of
functionality
and
then
later
on,
when
waku
v2
is
available,
we
can
integrate
it
into
ceramic.
You
know
using
this.
Basically
us
the
same
name
or
this
or
similar
api
and
sort
of
just
swap
out.
Let's
say
the
the
layer
that
we're
using
for
waku.
E
I
don't
know
if,
when
people
vote,
if
it's,
they
necessarily
need
that
level
of
privacy
in
general.
If
they're
signing
a
message
today
and
they're,
sending
it
to
ethereum
chances
are
they're
sending
it
through
in
mira-
and
it's
I
mean
in
my
opinion,
I've
always
said
that
it's
not
clear
what
information
here
is
capturing,
but
they
certainly
can
see
what
your
ip
address
is.
A
Another
thing
to
consider
is
that
I
mean
currently
the
only
limitation
that
we
have
is
that
what
it
does
not
that,
basically
the
work
runs
on
dev
psp
and
that's
why
it
cannot
be
run
on
the
browser
and
that's
why
we're
moving
through
it.
But
I
mean
there's
nothing
that
prevents
us.
You
know
writing
an
adapter
that
runs
on
our
status
server.
You
know
like
and
the
brow.
A
You
know
that
using
the
just
forwards
envelopes
and
then
you
have
all
the
waco
code
on
the
browser
that
does
the
decryption
and
so
on
and
so
forth,
but
you
don't
have
the
connection
is
under
through
or
any
other
technology
really
doesn't
really
matter
three
web
sockets,
so
you
know
like
having
an
adapter
from
waco
version,
one
to
something
that
lives
in
the
browser
it
is
possible.
I
don't
think
it's
technically
feasible.
E
A
Is
it
slightly
so
it
was
a
bit
more
ambitious,
so
what
they
were
trying
to
do
is
like
this
thing
had
no
discovery
as
well
in
leap
year
to
peer,
so
it
would
just
basically
like
connect
to
other
peers,
but
we
don't
really
you
know
for
these.
You
know
we
probably
don't
really
care
much
about
centralization.
This
has
been
decentralized
and
so
like
connect.
If
these
adapted
nodes
that
are
done,
this
will.