►
From YouTube: Agenda dev core #40
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
D
Hey
yeah,
I'm
sorry,
I'm
just
quickly
opening
up
the
issue
again,
so
there
were
like
several
discussions
that
we
were
having
with
michael
and
yuri
was
having
with
with
michael
and
I
was
having
separately
with
oscar,
and
so
we
thought
it
would
make
sense
to
quickly
bring
it
into
the
core.
Dev
call
to
have
a
brief
discussion
on
the
current
stimus
integration
with
nimwaku
what
it
means
to
be
a
production
ready
for
nimwaku
how
that
integration
with
nem
status
will
look
and
what
that
means
for
nim
desktop.
D
So
one
of
the
main
issues,
for
example,
that
we
have
is
how
we
handle
storage
for
these
separate
things,
because
I
know
that
michael
was
working
on
an
sqlite
integration
for
nymph
status,
which
is
using
sql
cipher
we're
using
a
separate
sql
integration
for
messages,
because
we
need
that
as
well.
How
all
that
interaction
looks
with
each
other.
I
guess,
and
also
michael
had
mentioned,
that
yuri
mentioned
that
you
guys
won't
be
integrating
nimwaku
v1
using
the
nim
client,
but
continue
using
the
status
go
client.
E
Yeah,
I
think,
that's
probably
more
an
open
issue
than
like
a
subtle
thing,
but
that
was
something
that
we
wanted
to
to
discuss
and
kind
of
consider
the
different
ramifications
I
mean.
In
other
words,
we
have
a
working
v1
implementation
in
status.
Go
that
we're
using,
and
so
we
didn't
know
if
there
was
a
lot
to
be
gained
from
having
both
a
v1
and
v2
nem
implementation
inside
the
library.
F
F
But
you
know
it's
not
like
we're
saying.
Oh
we're
only
going
with
this
version
and
that's
it
like
it's
not
necessary
like
that,
although
it
would
be
interesting
to
see
how
you
guys
envisioned
this
like
if
we
support
like
both
audiovision
networking
on
the
client,
like
the
person
chooses
which
version
to
use,
how
do
you
picture
that.
D
D
C
Yeah,
I
can
jump
a
minute,
give
a
bit
more
context,
so
name
vacuum.
It
implements
a
spec,
yes,
but
that's
also
a
subset
of
what
status
go,
provides
specifically
to
the
core
app.
So
one
reason
for
implementing
the
investor
we
want
this
is
of
stepping
stone
is
because
it
reduces
risks
and
it
makes
it.
It
depends
a
bit
specifically
how
you
use
this
as
go
and
the
way
the
key
management
happens
and
how
this
bubbles
up
to
the
app,
but
just
by
switching
to
an
impact
v1.
C
It's
not
unlikely
that
some
issues
will
sort
of
surface,
whether
that's
sort
of
using
specific
apis
that
are
not
integrated
in
baku
or
something
name
specific
or
something
with
the
json
rpc,
how
that
works
or
whatever.
So
so.
The
idea
with
that
is
that
the
code
can
should
be
able
to
be
structured
in
such
a
way
that
you
can
toggle
between
these
two
and
that
would
be
a
stepping
stone.
But
it's
also
right
that
it's
potentially
a
question
of
priorities.
C
In
that
sense,
it
might
make
sense
to
go
from
cisco
back
to
to
vacuum,
to
directly
just
being
mindful
that
that
probably
increases
risk
and
so
on
regardless.
I
think
it
would
probably
be
a
good
code
structure
if
it's
allowed
for
having
nimba
v1,
even
if
that's
not
actually
pursued
in
terms
of
priorities.
E
F
F
E
F
F
C
And
then,
just
briefly,
the
point
with
backup
v2
is
that
it
would
be
useful,
depending
on
bandwidth,
for
this
installer's
name
and
desktop
and
so
on.
This
is
it
would
be
useful
to
have
integrated
all
integrations
as
well
as
possible,
because
that
gives
us
feedback
on
the
api
and
so
that
we
we
work
on
anything
of
any
rough
benches
and
so
on
that
are
discovered.
So
that
would
be
the
argument
for
having
some
force
experiment
total
early
integration.
D
So
I
was
having
a
discussion
last
week
with
michael,
where
we
were
talking
about
storage,
where
storage
of
messages-
and
I
feel
like
we
probably
both
misunderstood
what
we
were
saying
where
I
was
talking
about
the
storage
which
is
needed
for
the
history
protocol,
and
I
think
michael,
was
talking
about
the
then
already
decoded
payload
storage
for
wacom
messages
that
is
queried
for
then
displaying
messages
again
in
chat.
Is
that
correct,
michael.
E
D
Well,
so
here's
the
thing
right
like
if
you,
if
you
are
in
the
mindset
of
nem
status's
use
case
that
is
useful
for
us
as
well,
because
then
we
know
what
what
is
expected
for
us
to
be
provided
by
nimwaku,
which
right
now
sometimes
is
a
bit
of
building
in
the
dark,
because
we
have
the
protocol
done
and
the
api
for
the
protocol
works.
But
what
do
you
guys
expect
beyond
that
right?
So,
like
persistence
of
messages?
Is
that
something
you
want
us
to
do?
D
E
F
Yeah,
that's
that's
right!
That's
correct!
Yeah!
In
fact,
I
think
something
no
neutrality
is
assigned
to
that
or
the
initial
work
for
that
and
that's
yeah.
It's
like
it's
some
I
mean
the
protocol
is
kind
of
abstracted
right
and
the
storage
of
messages
is
up
to
the
up
to
the
client,
not
the
client,
but
the
library
that's
using
using
the
protocol
protocol.
A
B
A
And
when
you
say
okay,
so
this
is
a
question
that
you
know
because
of
obviously,
like
my
perspective,
is
from
the
core
team,
so
we're
one
step
further,
we're
not
in
in
stimulus
we're
not
in
work,
and
so
now
the
question
goes
to
stimulus.
You
know
like
what
does
it
mean
for
you,
integration,
successful
integration
like
these
messages?
Are
we
talking
about
raw
messages
or
we're
talking
about
protocol
messages?
Well,.
F
Actually,
we
already
have
it
working
with
the
withdrawal
raw
messages
on
a
working
on
the
cons
to
to
get
it.
You
know
working
for
for
real
in
quotes,
but
for
me,
like
a
for
me,
that
don
is
integrate
his
name
status,
integrated
or
steamboats,
or
integrated,
with
both
desktop
and
mobile,
and
working
as
it
is
everything
with
the
flag
or
option
to
support
the
bucket
v2.
A
Yeah
essentially
like
yeah,
I
mean
you're
like
the
app
shouldn't
be,
should
be
no
different
from
what
it
is
now
effectively
yeah.
You
know,
of
course,
we
can
cut
some
corners.
You
know
like
if
there's
going
to
be
some
performance
heat
like
minor
performances
at
the
beginning,
because
I
mean
I
know
that
we're
going
to
breach
probably
messages,
and
so
maybe
whatever
we're
not
going
to
get
all
the
benefits
from
what
could
do
that?
That's
that's
fine,
of
course,
if
they're
major
performance
issues,
that's
gonna
be
issue
but
easy.
E
D
So
from
my
understanding
up
until
the
bridge
is
running,
that
would
be
the
case
any
from
my
understanding
as
well.
Any
node
can
run
a
bridge,
so
any
v2
node
could
run
a
bridge
that
bridges
v1
messages
to
v2.
Oscar
can
probably
comment
more
on
that,
because
I
haven't
actually
looked
that
much
into
the
bridge.
Yet.
C
C
C
So
old
clients
would
would
send
messages
on
on
the
back
to
v1
as
normal,
and
this
would
be
picked
up
by
some
node
in
a
cluster
that
you're
connected
to,
and
this
node
would
run
back
to
v1
and
vacuum
v2.
And
then
there
will
be
a
shared
sort
of
data
structure
and
it
would
make
sure
that
messes
are
propagated
to
the
v2
network
and
likewise
for
incoming
v2
messes.
It
would
propagate
to
the
v1
network
for
backwards
compatibility
speaking.
E
D
F
E
C
B
C
F
B
F
A
A
C
I
I
wanted
to
make
sure,
is
it
like?
Is
it
clear
the
differences
with
the
api
and
so
on
or
the
end
he
got
just
to
have
eros
in
there,
because
it's
it's
a
slightly
different
interaction
with
the
sort
of
name
native
nymph
node
api.
This
is
the
previous
one.
So
yeah,
I
guess,
there's
an
open
question
because.
D
E
That's
right,
I
basic
for
our
what
we
call
our
smoke
test
for
the
basic
integration.
I
just
took
the
basic
chat
example
and
adapted
it.
You
know
it
very
clear
from
looking
at
the
v1
v2
versus
v1
chat.
Examples
how
the
waco
v2
is
is
a
layered
system
and
you
compose
the
things
together
the
filters
and
so
on.
E
I
it's
probably
unknown
unknowns
at
this
point,
and,
and
I'm
sorry
for
that-
it's
just
that
we
haven't
spent
most
of
our
time
thus
far
has
not
been
spent
on
the
waku
integration
side.
It's
been,
we've
been
working
on
some
other
aspects
of
the
library
getting
the
database
pieces
and
the
crud
pieces
for
the
database
in
place.
The
sql
cipher
integration
was
a
huge
bear
for
the
last.
I
don't
know
six
weeks
or
something
so
I
think
probably
starting
this
week,
we'll
be
looking
more
at
the
integration.
Is
that
crackery.
F
D
D
C
B
Yeah,
no,
it's
no
worries
hi
everyone.
I
haven't
met
most
of
you,
but
yeah.
I've
just
recently
joined
and
I'm
working
on
the
non-nem
api.
So
many
of
these
integration
issues
that
you're
talking
about
now
will
probably
be
relevant
for
me
as
well.
So
and
it's
going
to
be
sort
of
erased
based,
though,
for
now
since
secure
http
servers
aren't
supported,
it's
just
going
to
be
a
json
rpc
api
kind
of
following
race
principles
and
yeah.
So
for
non-number
clients.
A
So
in
this
review
of
previous
actions,
I
think
the
only
action
we
had
was
for
trauma
to
update
with
his
findings
about
how
to
better
optimize
requests
for
wallet,
and
I
believe
that
they
stand
there.
So
if
anyone
wants
to
take
a
look,
I
can
just
attach
a
link
later
on
on
the
issue
and
okay,
so
that
would
be
it
as
anyone
anything
that
we
would
like
to
talk
about.