►
From YouTube: Status Core Dev Call #28 - Apr 20, 2020
Description
Welcome to the reboot of the Core Dev Call for the Status Network. These calls are used to sync on various development issues and make decisions amongst those that are building different parts of the Status Network ecosystem. Join in and listen!
B
So
there's
a
link
to
the
agenda
in
the
chat
and
yeah
welcome
to
the
2012
cortical
and
it's
kind
of
like
a
reboot
when
we
started
this
this
course
like
a
year
ago,
something
that
original
intention
was
to
make
it
stuff
open,
and
it's
incredible
this
sort
of
have
a
clear
agenda
beforehand
and
have
solid
notes.
So
people
can.
But
it's
bits
that
someone
has
an
echo
with
some
you'd.
Please.
C
A
B
All
right,
let's
keep
going
yeah
and
yes
essentially
makes
it,
make
it
possible
for
the
communities
of
participate
and
know.
What's
what's
going
on
and
with
live
streams
and
so
on,
and
so
try
to
get
back
to
that.
I
think
when
we
start
it
and
have
it
be
similar
to
the
theorem
quarter,
closed
I
think
we
stopped.
We
started
we
weren't
quite
yet
ready
for
here
because
we'll
be
talking
about
hey
you're
a
could
you
please
mute.
B
When
we
started
we'll
be
talking
more
about
specific
features
to
the
core,
app
and
so
on,
but
now
we
want
to
talk
more
about
so
the
spec
and
protocol
level,
and
now
we
actually
have.
We
have
a
version,
one
app
out
to
the
App
Store
and
the
Play
Store,
and
we
aspects
that
are
sort
of
fairly
stable.
So
we
have
something
to
build
on
now
and
we
can
sort
of
talk
about
them
with
different
stakeholder
groups.
B
We
have
the
core
app
and
where
the
Nimbus
team,
as
well
as
research
efforts
like
dagger
and
back
and
so
on,
so
that's
sort
of
roughly
roughly
go
and
we
also
have
more
team
stability,
just
a
brief
refresher
on
where
we
are
with
the
specs.
So
we
have
fixed
ourselves.
I
am
site
with
a
set
of
specifications
that
are
sort
of
stable
and
they
roughly
reflect
what's
in
the
version.
One
of
that
that's
released
and
essentially
the
writers
are
stabled.
That
means
it's
kind
of
a
contract
between
the
spec
developers
and
end
users.
B
Why
high
specs,
yeah
I
mean
it.
It
sort
of
allows
us
to
clarify
our
thinking
and
makes
it
it
makes
it
clear
there
what
what
we're
requiring
and
what
we're
providing
in
terms
of
security,
ents
and
capabilities,
and
so
on,
and
it's
very
useful
for
interfacing
with,
if
it's
audits
or
marketing
or
the
academic
community
or
the
film
community,
and
so
on.
It's
like
a
lot
of
really
good
reasons
to
have
solid
specs
for
the
stats,
client,
I
guess.
One
question
that
I
wanted
to
ask
is
start
start
off
with.
B
D
We
haven't
really
structured
Sprint's
enough
that
we
could
enforce
a
format
of
feature
requests
back
task
lists
tasks
like
implementation,
sort
of
like
flow,
so
that
then,
at
least
for
me,
is
what
I
perceive
as
it
being
like
the
biggest
the
biggest
pain
point
for
everyone,
myself
included.
In
fact,.
E
E
Discrepancies
between
specs
and
implementation-
so
say
you
know
regardless
which
one
you
start
with
say
that
you
start
with
specs.
Then
you
go
into
implementation.
Then
you
need
to
the
back
up
the
specs,
because
you
know
thank
you.
You
decided
to
discover
the
something
a
bit
different
and
sometimes
there's
a
bit
of
pressure
to
get
things
out.
You
know
so
you
know
like
you
want
to
get
this
feature
out
and
so
there's
not
much
time
to
basically
go
back
to
the
specs
as
soon
as
he's
out.
E
You
know,
gonna
get
bug
reports,
you
might
change
things,
it's
fun
and
so
forth.
So
the
thing
that
leads
to
a
bit
of
you
know
they
expect
in
that
behind
general
speaking,
and
so
one
way
to
overcome
this
is
to
get
protocol
changes
out
as
quickly
as
possible,
but
look
do
not
release
it.
So
like
they
just
the
change,
my
window
happened.
It
can
be
used
for
some
means,
so
it
can
be
tested
on
real
devices
and
it
can
be
used
somehow.
But
you
know
like
it's
not
maybe
available
to
users.
E
A
D
Mean
was
in
backyard,
the
funding
is
spec
for
protocol
like
those
are
very
different
from
running
the
spec
for
a
feature
and
how
a
feature
should
work
right,
I,
don't
think
I,
don't
think.
A
feature
requires
the
same
level
of
and
correct
me
if
I'm
wrong,
but
I
don't
think
a
feature
requires
the
same
level
of
scientific
exactitude
as
a
protocol.
Spec
requires.
B
B
E
Another
thing
is
that
it
was
sure
that
you
know
that
we
sort
of
F
of
waiting
to
bright
specks
in
back
I.
Don't
think
that
is
structured
enough.
As
you
know,
there's
a
squad
of
D'agostino
respectively
no
wear
specs
and
take
the
point
of
using
our
spec
should
be
and
I
think
having
a
bit
more
of
a
template
might
help
encourage
people
who
may
be
a
little
bit
suspect
yet
or
you
know,
I'm
not
sure
about
it.
E
How
to
write
them
just
do
and
just
make
it
easier,
as
well
for
other
people
to
jump
from
one
spec
to
the
other.
It's
a
little
thing,
they're
very
consistent
as
well
like
we
don't
have
good
news.
Sanity
check
can
I
leave
them
in
the
client
just
by
following
despairs.
We
realized
recently,
with
both
respect
that
that
wouldn't
have
been
the
case.
There
are
some
places
where
that's
not
so
clear.
B
B
Right
now
the
workflow
is
is
fairly
lightweight,
I
mean
it's
essentially
open
an
issue
and
they
a
pull
request
and
respects
repo,
and
then
people
in
in
the
protocol
group
and
like
whoever
sort
of
is
concerned
with
it
rearing
it
and
then
attach
the
sort
of
a
specific
lifecycle
state
to
it,
depending
on
how
far
along
with
its
like
an
ID
or
if
it's
in
production
and
so
on.
That's
roughly
the
process
this.
It's
not
an
end
ideas,
also
to
use
these
calls
to
discuss
specific
issues
and
PRS
and
make
decisions
on
them.
B
C
G
C
F
C
F
F
Described
it
as
actually
there's
no
problem
in
my
mind
with
that,
the
the
issue
I
supposed
I
I
found
more.
It's
just
that
I'm
thinking
from
the
perspective
of
if
I,
don't
know
what
the
process
is
to
submit
in
specifications
so
even
like
feature
requests,
then
I'll
be
hesitant
to
do
anything
until
I'm
I
know
how
to
do
that.
So
in
terms
of
the
formalization,
it's
more.
G
F
B
I
C
B
Yeah
because
because
ideally
I
mean
the
people
who
are
implementing
stuff
and
it's
launches
of
the
core
team
and
so
on,
they
are
domain
expert.
So
we
wanna
involve
as
many
people
as
possible,
so
right
think
of
things
that
they
know
the
most
about.
So
the
goal
is
to
get
more
people
to
contribute
and
have
the
specs
be
closer
to
reality.
And
then
the
question
is
what
is
blocking
people
right
now
in
terms
of
helping
with
that
endeavor.
C
B
So
not
not
documentation
for
specific
code
bases
and
also
not
fact,
because
we
have
the
process
that
works.
Okay,
and
in
fact
this
is
more
about
the
specs.
The
protocol
specification
to
make
up
a
status
client
and
in
that
gender
there's
also
like
a
list
of
various
things
that
are
missing
and
would
appreciate
some
help
from
core
contributors.
I
There's
no
mic
volume
indication,
maybe
they'll
see
it
so
in
this
case,
like
we're
speaking
about
documenting
something
retro
actively,
you
know
that
should
already
be
documented,
but
is
not,
and
what's
blocking
people
here
is
that
this
is
a
project
right.
This
is
there's
the
process,
which
is
that
we
should
been
doing
good
acts
on
an
ongoing
basis
as
part
of
every
feature
that
we
build.
I
But
in
this
case
you
know
this
is
something
that
we
need
to
make
a
concerted
effort
to
fix
to
catch
up
on.
So
this
is
going
to
require
an
allotment
of
time
from
the
whole
group
and
be
treated
as
a
project
with
some
kind
of
deadline.
It
just
hasn't
been
prioritized.
It
hasn't
been
structured
in
such
a
way
that
people
would
take
it
on.
You
know.
B
G
Yeah
I
missed
what
Rachel
Rachel
said,
because
my
audio
cut
but
I
just
wanted
to
say
regarding
the
core
team
I
think
it's
more
a
matter
of
defining
during
our
team
calls
what
we
should
write
specs
about,
rather
than
anything
that
regards
the
process
of
writing.
Specs
I,
don't
think
it's
a!
There
is
much
blockers.
G
As
you
said,
the
the
process
is
pretty
simple,
but
it's
just
that
we
don't
necessarily
know
what
to
write
about
and
if
it
needs
to
be
done
this
week
or
later
so,
I
think
it's
more
of
a
team
effort
to
as
part
of
the
retrospective
or
whatever
to
discuss.
Ok,
this
this
part
of
the
project
is
under
defined
and
let's
write
something
about
it
in
this
book.
B
Cool
yeah
I
just
want
to
add
to
what
you
said.
I
agree.
It's
definitely
part
of
it
is
retrospective,
but
I
also
just
want
to
say
the
part
of
it
is
also
a
future-oriented.
So
the
example
when
we
talking
about
image,
sending
and
so
on.
In
my
view,
ideally
that
type
of
discussion
would
happen
an
issue
or
something
like
it,
where
people
can
sort
of
come
up
with
different
proposals,
and
we
kind
of
way
pros
and
cons
with
that
and
have
discussions
in
calls
such
as
this
one
before
it
gets
implemented.
C
G
C
You
guys
hear
me
yeah,
yeah,
I,
think
in
general,
sometimes
it's
hard
to
just
like
read
through
a
spec
and
just
intuitively
sort
of
know,
what's
missing
at
me,
sometimes
as
you're
reading
through
it
yeah,
you
see
obvious
unanswered
questions
but
I
think
sort
of
the
easiest
way
or
this
for
me,
I,
think
to
where
you
find
issues
in
a
spec.
Is
you
just
try
to
build
something
using
it
right,
and
this
is
more
just
an
idea,
but
I
think
maybe
one
way
to
kind
of
flesh
these
things
out.
C
I
know
like
last
year
we
had,
you
know
a
little
weak
and
maybe
reduce
and
I
think
there
was
a
plan
to
have
again
this
year,
but
maybe
this
year
we
have
some
areas
that
we
try
to
focus
on.
Maybe
people
try
to
build
build
something,
even
if
it's
just
like
some
toy
clients
using
the
spec
and
I,
think
that
could
end
up
fleshing
out
a
lot
of
a
lot
of
things.
I
F
B
F
B
Yes,
I
think
it's
been
before
like
previously,
it's
been
a
bit
of
a
parallel
effort
where
we
had
the
protocol
group,
that's
of
consisted
of
both
both
people
from
back
and
and
core
and
so
on
and
I
think.
That's
worked,
okay,
at
least
in
terms
of
getting
the
basics
done,
but
I
would
love
to
see
it
of
core
take
on
ownership
of
this
of
the
specs
when
it
comes
to
status.
Clients
as
well,
because
also
keep
in
mind
that
this
is
different
from,
for
example,
devack
specs.
B
This
is
about
how
to
write
like
establish
client,
so
I
would
love
to
see
that
happen,
but
obviously
there
would
be
a
bit
of
back
and
forth
and
whoever
sort
of
it's
part
of
the
general
protocol
group.
So
the
research
efforts
also
help
out
in
terms
of
the
format
and
the
process
around
this
yeah
sort
of
meet
me
and
Corey,
and
and
Dean
and
Andrea
and
Kim,
and
so
on.
Who've
already
been
involved
in
this
for
a
while.
Okay.
B
Generally,
the
idea
is
also
like
anything,
that's
needed
kind
of
likely
like
the
EAP
process,
right,
it's
it's.
Anyone
who
is
doing
something.
That's
would
be
useful
for
service
client
right
now.
There's
mate
mainly
one
size
font,
but
that
might
change
with
with
embark
and
with
Nimbus
and
so
on.
So
anyone
who
is
writing
something
like
a
general
description
of
how
to
make
something
the
sows
client
they
would
own
that
spec
right
and
then
there's
sort
of
a
process
around
it.
Just
like
the
EPI
process,
essentially,
okay
and.
C
B
B
F
I
I
I
F
F
So
what
so?
What
I've
started?
I'll
talk
a
little
bit
about
what
I've
studied.
If
we're
talking
about
documentation.
Now
we're
not
just
specification
necessarily
I,
also
on
the
status
code
repository,
we,
we
have
a
lot
of
packages
and
most
of
them
don't
have
documentation
and
if
they
do
have
documentation
in
my
eyes,
it's
not
as
it's
to
be
honest,
I
wouldn't
really
say
fit
fit
for
purpose.
F
So
to
take
somebody
with
zero
knowledge
up
to
workable
knowledge
of
the
codebase,
so
I'm
pretty
certain
that
that
the
team
is
probably
already
well
aware-
and
this
is
not
a
criticism
because
I
understand
whenever
you're
right
building
something
out
you
will.
You
all
have
to
get
to
the
point
where
you
have
to
make
a
decision
about
if
you've
got
time
to
spend
whether
you're
building
functionality
or
whether
you're
writing,
documentation
and
almost
always
the
the
priority,
goes
to
the
functionality.
F
So
I
saw
what
I've
done
as
I
opened
up
one
issue
for
just
one
package
and
that's
the
package
that
I've
actually
been
working
on
since
basically
as
I
started,
and
my
plan
for
this
is
to
actually
roll
out
a
new
issue
after
every
package
has
been
I,
refactored
or
being
documented
to
to
a
well
enough
degree
that
somebody
was
zero.
Knowledge
of
the
repository
can
read
that
and
then
get
up
to
a
relevant
level
of
competency
with
the
functionality,
or
at
least
the
expected
functionality
of
of
that
particular
package.
F
B
That's
a
great
thing:
I
think
that
maybe
for
the
purposes
of
this
call,
we
could
sort
of
fork
to
discussion
around
documentation
with
specific
implementations
to
a
course
specific
or
cuz
I'm,
not
sure
it's
relevant
to
everyone
here.
Okay
is
fine,
but
it's
a
fair
point
and
I
think
it's
good
to
bring
it
up,
and
hopefully
we
can
follow
up
from
that
in
there
in
the
constitute
core
in
some
way,
yep.
C
I
H
All
right,
yeah
so
with
respect
to
I,
guess
some
of
the
documentation,
slash
protocol
specification
levels
of
detail
of
a
it's
reasonable,
its
I've
been
building
on
the
threat,
modeling
process,
and
this
kind
of
plays
into
that,
because
I
want
a
diagram
built
for
everything
that
we
end
up.
Spec'ing
out,
I
think
it's
a
good
starting
point
to
get
done.
H
If
you
have
a
diagram
that
explains
at
a
high
level
how
things
are
put
together,
how
they
work,
you
can
build
the
appropriate
documentation,
slash
specification
from
that,
including
the
threat
model
associated
with
it,
we're
just
kind
of
which
is
kind
of
part
of
it
anyway.
So
if
we
I
think,
if
I
personally
feel,
if
we
get
something
done
everywhere,
we
can
work
from
there
to
see
what
needs
to
be
done.
H
That's
kind
of
associated
to
what
it
is,
whether
it
be
just
documentation
of
a
given
feature,
implementation
details
of
a
some
part
of
the
spec
or
like
a
specification
itself
or
underlying
protocol,
but
like
they
all
have
some
core
of
the
same
thing,
which
is
describing
what
the
hell
supposed
to
do.
The
level
of
detail
you
go
into
is
dependent
upon
the
audience
you're
trying
to
kind
of
talk
to
about
it.
B
Yeah
yeah
yeah,
no,
no
yeah.
It
means
a
good
opportunity
to
have
if
we're
I
said
like,
while
everyone
is
here
and
we
can
do
various
types
of
follow-ups
after
in
smaller
groups
as
well,
so
I
think
the
first
one
here
is
that
could
be
1.2,
spec
change
and
essentially
well
that's
about
this-
that
the
specs
right
now
reflect
the
version
1
of
the
app.
But
then
with
1.2
we
have
sort
of
relaxed
the
requirements
on
whisper
and
introduced
the
capability
of
back
loop.
B
F
C
F
B
F
B
C
B
D
Well
here
so
I'm
gonna
take
blame
on
that
one
I
was
going
to
hand
out
some
work,
indecent
prep
work
for
the
team
last
week,
so
we
can
assign
the
issues
to
the
people
that
have
most
relevant
knowledge
of.
What's
going
to
expect
has
it
happened
last
week
just
came
and
went,
and
I
really
didn't
have
a
chance
to
do
it
so
right
after
this
call,
rich
and
I
are
going
to
go
through
the
list
and
assign
it
to
assign
each
item
to
people
today.
D
B
Cool,
that's
fine.
Do
you
see
there's
no
need
to
do
that
during
this
call
yeah,
it
can
be
done
done
after
correct
yeah.
Next
question
is
Esther.
Anything,
that's
not
on
this
list
that
should
be
in
this
list.
So
I'll
just
do
a
brief
recap.
So
these
are
things
that
are
already
in
the
app,
and
the
ones
mentioned
are
how
we
use
access
gateway
for
sneakers.
B
How
notifications
work,
how
we
interface
with
them,
if
your
locks
in
through
it
in
foreign
culture,
how
clients
use
key
card
other
third
party
API,
is
used
for
core
functionality
that
browser
API
usage,
as
well
as
other
things
on
the
right
sensor,
mentions
and
images,
and
so
on.
It
shouldn't
be
major
missing
there.
I.
D
B
That
is
yeah
so
to
make
a
service
client
includes
making
like
a
browser
right
and
and
to
have
a
functioning
browser.
You
need
to
do
certain
things
and
then
it
also
impacts
things
like
privacy
and
availability,
depending
on
how
you
integrate
with
in
Ferrara
and
I
profess
and
how
you
deal
with
cookies
or
whatnot.
So
it's
a
bit
it's
a
bit
of
a
mix
between
feature,
but
but
in
essentially,
if
someone
else
wants,
you
might
be
status,
client
and
you
want
to
be
able
to
use
the
same
focus
with
a
browser
and
any
API.
D
B
B
D
B
A
B
Not
to
my
knowledge,
I
think
that
would
be
based
on
we
use
acquisition
and
then
looking
at
her
across
the
forms
and
so
on.
Okay,
so
I
would
imagine
that
would
be
a
core
/
core
infra
check,
but
but
algorithmically
I
think
you
would
still
hit
that
at
some
point,
but
yeah
then
it
becomes
the
probation
issue
as
well.
B
E
C
E
Know
one
thing
that
we
we
I,
don't
remember
where
we
stand
on
this,
but
you
know
that
we
talked
about
discovery,
but
this
is
not
we're
not
even
really
about
these
careers.
Just
wanted
for
boot
notes
as
I
understand.
You
know
that
so
the
initial
bootstrap,
because
this
is
you
know,
discovery
it's
a
much
more
dynamically
static
list
that.
B
Was
the
original
idea,
but
I
think
that
was
changed
with
correct
me
if
I'm
wrong,
ed
Dean,
but
like
I,
think
the
idea
was
also
to
use
it
as
a
basic
foam
discovery?
Why,
in
order
to
D
risk
this
discovery,
if
I
work,
and
so
on,
at
least
as
a
potential
usage,
so
not
only
butch
up
at
Lisa?
That's
why
I'm
sunny?
Let.
A
E
A
E
So
I
think
these
questions
need
answering
sort
of
like
maybe
is
know
something
it
is.
You
know
like
in
dispatch,
they
will
change,
but
you
know
how
we
use
these
those
important
to
discuss
because
I
don't
think
it
is
very
clear
from
the
coop
perspective
before
we
do
any
implementation,
we
need
to
understand
how
to
use
it,
what
the
language
is
going
to
be
and
what
it
is.
In
fact,
it
would
be
alright.
C
C
B
D
For
the
core
of
not
just
not
anytime
soon
will
we
have
group
chat
and
notifications
coming
up.
We
have
a
keycard
coming
up.
We
have
cerpac
and
referrals
coming
up
so
because
capacity
is
still
not
an
issue
that
we
foresee
hitting
in
the
near
future
like
we're,
trying
to
we're
trying
to
balance
things
that
would
give
us
capacity
problems
so
that
we
can
address
the
capacity
if
that
makes
sense
kind
of
interact
to
solve
problems
when
I
need
to
solve
them.
That.
B
A
B
B
I'll
probably
merge
the
straw
until
we
have
some
implementation
that
does
specifically
something
which
related
to
back.
You
notes,
because
then
is
I
mean.
If
it
is
a
quick
thing,
then
it
will
quickly
go
into
draft
and
being
actually
used
end
to
end
in
as
in
developer
whatever,
and
then,
after
that,
it
will
be
stable.
Okay,.
C
B
And
just
father,
if
it's
not
clear
with
the
lifecycle
thing
essentially
stable
means
it's
a
raw
mean
citizens,
a
just
like
general
idea.
That
sort
of
this
spec
exists
and
maybe
there's
some
code
whatever,
but
it's
essentially
inspect
writer
as
written
something
and
then
draft
is
essentially
that
is
kind
of
like
a
contract
between
a
spec
and
and
implementations,
there's
some
sinker
and
on
there
in
terms
of
changing
the
spec.
That
means
that
that
draft
it's
the
implementation
is
changing.
B
C
D
D
Like
in
the
IP
or
standards
and
that
kind
of
defines
how
this
should
be
done
or
how
it's
implemented
on
other
customers
or
clients,
sorry,
and
basically
there
there's
this
e
IP.
It's
a
draft
that
hasn't
been
picked
up
in
three
years,
so
I
mean
it's
it's
a
little
bit
broader
than
what
we
are
intending
to
do
right
now.
D
D
A
D
Will
do
yeah,
so
basically,
you
know
we
have
a
couple
options
here,
like
I,
don't
want
to
bring
anything
in
that
status
that
is
interrupts
without
it
being
a
standard
or
defined
in
a
spec
somewhere,
because
then
it's
just
another
standard,
and
we
don't
want
that.
So
you
know
like
basically
just
kind
of
introduce
it
into
the
problem.
D
I
would
I
would
very
much
like
to
even
propose
in
in
prev,
indeed
status
field
that
links
to
statuses,
Universal
links
handler
from
the
manager,
if
that's
possible
and
yeah
figure
out
for
now
how
the
profile
other
profile
image
field
should
be
stored
in
and
how
we
can
do
that
from
our
end
too.
So
that's
yeah!
That's!
We
can
chat
about
it
later,
but
that
was
kind
of
my
point
to
address
or
to
address
that
is.
D
F
Do
have
a
recommendation
that
it's
not
a
directs,
it's
something
that
I
floated
by
reg.
Actually,
but
basically
there
is
a
project
called
three-box
and
they
are
basically
the
same
thing,
so
they
may.
There
may
already
be
an
effort.
That's
been
put
into
this
particular
issue
that
has
provided
a
solution
that
might
be
compatible
with
statuses
approach,
yeah.
D
F
Yes,
yeah
I,
understand
that
then
a
standard
they
have
an
infant
but
they're
also
an
active
project
that
are
working
towards
the
same
goal.
So
whether
or
not
the
specification
exists,
I
suppose
or
a
standard
exists,
a
is.
It
is
a
separate
issue,
but
we
could
possibly
collaborate
on
that
together.
So
you're
saying,
there's
a
three
year
old
sort
of
standard
that
we
say
it's
an
EIP,
this
yeah
anyway,
okay.
So
this
is
three
role:
the
IP.
So
obviously
it's.
F
Chat
for
another
time,
but
in
terms
of
solutions
that
might
have
already
been
created,
there
is
an
Avenue
as
but
whether
or
not
it's
and
when
I
meant
compatible,
didn't
necessarily
mean
no
technology
technological
level.
It
was
more
on
a
sort
of
standards.
Compliance
even
made
on
a
philosophical
level.
D
D
So
basically
my
name
I'm
a
motivator
here
is
two,
so
right
now
being
driven
by
what
a
yet
what
ENS
manager
thinks
is
the
right
thing
to
do
kind
of
feels
finicky
to
me.
We
already
we're
already
a
client
of
ENS,
so
I
think
we
should
go
forward
with
ENS.
I
just
want
to
make
sure
that
this
stuff
gets
defined
into
a
standard.
D
A
A
C
D
That'd
be
great
cuz,
then
we
can
just
agree
like,
for
example,
the
the
avatar.
The
idea
Vitara
is
the
URL
to
an
image.
We
have
a
suggestion
about
that,
but
maybe
you
know
maybe
that
there's
no
point
changing
it.
So
as
long
as
it
gets
the
foot
like
changed
into
like
a
standard
I'm
happy
to
I'm
here,
yeah
happy
to
move
forward
with
the
work.
Just
anything
that
says
draft
makes
me
nervous
a
complete.
D
F
H
D
C
B
D
Don't
mind
having
lots
of
issues
as
long
as
we
can
look
at
them
and
prioritize
them,
and
it
doesn't
get
any
more
public
than
what
we
have
right
now.
Anyways,
so
I
feel
that
the
issues
are
easier
to
navigate,
because
you
can
actually
see
what's
what
the
conversation
has
been
around
each
one
of
them
and
then
what
the
state
is
I.