►
From YouTube: Incremental Delivery Working Group - 2023-02-13
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
No
getting
sick
is
no
fun
indeed,
yeah.
C
A
I
totally
was
not
stuffing
my
face
just
literally
before
I
joined
the
call
so
yeah.
It's
just
cramming.
My
third
breakfast
in
hello,
Ivan,
hello,
Rob
how's.
It
going.
A
A
Rob
thanks
very
much
for
keeping
this
all
up
to
date
and
captured
in
the
discussions.
Super
helpful.
D
Yeah,
no
problem
I
posted
a
few
things
over
the
weekend
that
I
wanted
to
talk
through
today.
If,
yes,.
A
D
Yeah
sure
awesome
I
can
share
my
screen.
One
second.
D
Yeah,
so
so,
after
last
week's
meeting,
we
I
mostly
agreed
on
moving
forward
with
this
option,
for
where
we
had
a
static,
deduplication,
algorithm
and
I
was
working
on
implementing
that
based
off
work.
That
yaakov
had
done,
and
so
just
to
to
summarize
would
Yakov
had
built.
Originally
was
only
deduplicating
Leaf
fields,
and
it
was
my
understanding
that
that's
not
what
we
wanted
so
for
this
example,
you
have
a
defer
with
a
nested
object,
same
field
inside
of
them.
D
Id
gets
deduplicated
because
that's
a
leaf
yield,
but
nested
object
is
not.
You
still
have
this
defer
with
a
empty
object
being
returned,
so
I
started
working
on.
How
do
we
actually
deduplicate
object
fields
that
as
you're
working
up
the
tree
in
graphql
JS,
which
which
is
the
same
algorithm,
that
the
spec
does
mostly
what
I
came
up
with
was
doing
something
like
when
a
field
is
deduplicated
instead
of
just
removing
it?
D
We
return
some
kind
of
a
JavaScript
symbol,
but
just
any
kind
of
unique
value
that
the
implementation
could
track
and
if
all
of
your
Fields
inside
an
object
would
be
duplicated,
then
the
parent
would
also
get
you
duplicated
and
you
could
work
up
the
tree
that
way.
D
I
don't
know
if
there's
a
better
way,
but
that
was
what
I
came
up
with
just
trying
to
figure
something
out
and
that
works
for
for
this
case.
So
now
we
can
know
that
nested
object
is
totally
deduplicated
and
not
even
returned
that
defer
and
you
would
get
this
results.
D
D
So
now
we
don't
have
the
opportunity
to
see
like
are
all
the
fields
duplicated
and
instead
it's
not
you
duplicated
anymore,
and
that
differs
from
an
algorithm
that
I
imagine
that
you're
doing
if
you're
doing
like
a
static,
query
rewrite
you
would
Traverse
this
whole
thing
and
know
they
shouldn't
be
here
and
remove
it.
And
now
you
have
a
different
result
and
like
another
thing
you
could
do
is
like
well,
it's
null
so
I'll
treat
it
as
a
Lee
field,
and
this
nested
object
like
it's
not
in
it's
also
in
the
parents.
D
So
I
could
dedupe
that
and
get
back
to
the
same
result
of
one
payload
but
like
to
show
why
that
doesn't
work
exactly
is
if
the
fields
are
actually
different
and
it
shouldn't
be
to
do,
should
it
be
deduplicated,
it's
it
could
in.
F
Oh
sorry,
my
bad
so
I'm
just
wondering
we
we
de-duplicate,
we're
deduplicating,
leaves
now
I
think
by
saving
the
path.
So
we
just
record
also
the
path
of
anything
that
ends
up
being
no
I
haven't
looked
into
it
too
deeply,
but
is
that
too
difficult.
D
I
think
the
problem
is
not
I'm,
not
sure
that
this
is
like
someone.
What
I'm
trying
to
explain
here
is
that,
if
the,
if
you
do,
have
a
null,
but
there
are
non-overlapping
Fields
underneath
it
a
static
algorithm
would
not
be
deduplicating
it,
but
an
algorithm
that
doesn't
actually
Traverse
down
into
the
fields
beneath
that
null.
D
Wouldn't
know
that
and
you
would
have
a
different
result
and
I
guess
that
that's
kind
of
like
the
what
I
think
with
with
last
meeting,
we
had
the
assumption
that
you
could
write
something
that
worked
in
graphql.js
and
would
give
you
the
same
results
as
an
algorithm
that
was
statically,
rewriting
queries.
But
I.
Don't
think
that
that's
the
case.
B
Bro,
excuse
me
so
it's
great
you're
you're
talking
about
a
thing
being
null.
Are
you
talking
about?
Nested
object
being
nulled
here?
Yes,
so
in
that
case
it
wouldn't
be
able
to
collect
more
Fields
anyway.
I'm
assuming
this
is
like
it
wouldn't
be,
adding
anything
to
be
deferred.
I
think
I
might
be
misinterpreting
what
you've
got
going
on
here,
but
I
I
imagined
that
it
would
be
part
of
how
the
collect
Fields
algorithm
works,
so
you'd
be
effectively
doing
it
via
the
the
value
completion
collecting
the
fields
together.
B
So
once
you've
got
a
field
that
is
null
at
you'd
at
that
point
not
collect
anything
else.
I
I
always
imagined
it
coming
through
as
like
being
a
a
tweak
to
the
collect,
build
algorithm
where
effectively
you'll
return
a
set
of
these
fields
that
need
to
be
evaluated
now
and
a
set
of
fields
that
are
effectively
deferred
and
because
you
would
stop
at
the
null,
you
wouldn't
be
adding
any
fields
to
like
the
Deferred
list
to
be
done
later.
D
What
if
this,
what
if
there
was
another
object
in
between
hero
and
nested
object
and
the
defer
was
there
and
that
one
was
not
null,
but
nested
object
was
so
it's
not
like.
We
tried
to
collect
here
and
didn't
get
any,
but
we
do
actually
I
could
I
could
write
out
an
example
yeah.
B
Please
do
separate
separately
from
that
I
see.
You've
got
has
next
to
true
in
a
couple
of
examples
where
I
think
you
might
have
meant
has
next
false.
It's
probably
just
copy
paste
error.
D
Yeah,
it's
definitely
possible
I'm
I'm
missing
something
here.
So
that's
why
I
just
want
to
talk
it
through.
D
Yeah
so
does
does
this
change
anything
if
nested
object
is
null
here,
but
not
fair.
So
now
we
we
went
through
the
first
round
of
Club
fields.
We
have
that
this
should
not
be
in
the
initial
payload
and
this
should
be
deferred
and
now,
when
we
get
here
and
this
returns
and
all
we
we
don't
know
if
it
should
be
deduplicated
or
not,
because
we're
never
looking
at
the
subfields
of
that.
Yes,.
B
So
the
the
collect,
Fields
algorithm,
works
on
a
layer
by
layer
basis.
B
So
when
you're,
when
you're
resolving
the
layer,
that's
within
the
hero
selection
set,
you
would
see
that
there
is
first
object
which
is
not
deferred
and
then
you
would
see
another
first
object
again
and
you
would
effectively
reconcile
that
to
say
sure
any
selections
on
that.
Second
first
object
would
be
deferred,
but
effectively.
You've
only
got
one
thing
there
with
no
defers.
B
So
then
you'd
move
on
to
the
next
layer
during
the
value
completion,
or
at
least
that's
that's.
What
I
would
do
in
an
algorithm
that
I
would
write
based
on
this,
which
would
be
effectively
equivalent
to
statically
evaluating
it
up
front,
but
you
can
do
it
on
a
I.
Think
I
think
you
can
do
it
on
a
layer
by
layer
basis
via
collect
fields.
B
You
would
need
to
add
a
little
bit
of
extra
like
tracking,
to
know
that
the
selection
set
that
you
have
on
the
first
object
field
in
the
second
instance
of
that
is
effectively
inside
of
a
defer
and
is
thus
deferred
and
I.
Think
there'll
be
some
complexity
when
you
have
like
nested,
defers
and
tracking
what
those
are
where
they,
where
they
relate
to
each
other,
but
I
think
it.
It
should
be
possible.
I
was
hoping
to
write
something
up:
I've,
just
not
I've
not
got
around
to
it
yet
I'm
afraid.
B
B
If
I,
if
I,
try
and
write
something
up
before
our
next
meeting
and
see,
if
I
can
be
more
concrete
on
what
I'm
thinking.
D
Yeah,
if
you
have
time
for
that,
that
would
be
helpful
it.
It
might
just
be
that
I'm
being
biased
by
still
basing
off
of
my
first
implementation,
where
every
deferred
fragment
Forex
execution
entirely
where,
where
what
I'm
still
having
like
the
case
where
we,
when
we
get
to
first,
we
start
executing
those
deferries
and
get
down
into
the
tree,
but
I
think
you're,
saying
something
different
where
first
object
would
only
be
executed
once
still
right.
B
Yeah,
absolutely
and
I
think
that's
that's
critically
important,
especially
when
you
have,
for
example,
a
streamed
field
that
exists
both
inside
and
outside
of
a
defer.
You
still
only
want
that
stream
to
be
created
once
so.
I
think
it
is
critical
for
us
to
try
and
evaluate
that,
and
now
the
the
defer
stream
don't
have
labels
anymore,
and
we
don't
technically
have
to
tie
them
to
exactly
where
they
are
in
the
query.
B
We
could
actually
do
more
things
that
we
couldn't
do
previously.
So,
for
example,
we
could
just
say:
oh
now,
there's
you
know,
there's
a
pending
thing
at
the
hero.
First
object:
nested
object
path.
We
don't
actually
have
to
say
there's
a
pending
thing
at
the
hero
path.
Arguably
I'm,
not
necessarily
saying
that
we
should
adopt
that
right
now,
but
I'm
just
saying
it
is
a
possibility.
D
Okay,
so
I
think
I
need
to
spend
some
more
time
with
that
and
I
can
I
can
work
with
you
or
if
you
want
to
write
up
something
first,
that
would
be
helpful.
A
I
I,
don't
think
we've
totally
decided
labels
aren't
still
in
the
picture
or
did
we
were
we
in
agreement
on
that
because
I
know
we
still
have
that
as
an
open
question.
It
was
broken
out
separately.
B
Regard
to
labels,
or
any
other
I
mean
there's
two
purposes
for
labels.
From
what
I
understand
right,
one
is
the
identification
which
I
think
we've
ruled
out.
We
don't
need
that
because
we
might
do
named
fragments
or
aliases
on
the
parent
field
or
whatever
right
and
the
other
one
is
in
terms
of
indicating
the
order
in
which
these
things
are
executed
and
I
think
that
that
still
has
value
and
I
I
factored
that
into
what
I
was
saying
before,
like
it
should
still
work.
That's
what
I'm
thinking.
C
A
Are
we
Rob?
Why
are
you
having
this
open
if
you
scroll
down
a
little
bit,
so
we
can
see
your
example
a
just
the
actual
query
itself.
Oh
no
sorry
you
were
on
it.
Sorry
it
was
on
the
label,
one
that
you're
on.
Oh
okay,
sorry
yeah
just
right
there.
A
So
what
what
we're
saying
here
is
that
all
of
these
stuffers
are
merged.
Basically,
so
there's
you
know
everything's
coming
back
together,
because
they're
part
of
the
same
object.
D
A
A
I'm
just
gonna
say
like
is
that
will
that
trip
people
up
like
if
there
are
people
that
really
don't
understand
that
much
about
how
they're
you
know
their
their
businesses
graphql
apis
implemented?
You
know
it's
a
front-end
developer,
it's
building
an
application
and
they're
realizing
that
parts
of
their
query
are
slow,
some
of
the
specific
fields
in
a
selections
that
are
slow,
so
they
add
a
couple
of
differs
in
even
though
it's
part
of
the
same
object
and
they're
thinking
hey.
A
That
really
means
that
we're
going
to
be
able
to
split
up
the
execution
here
and
these
things
will
really
just
come
back
like
you
know,
the
promises
are
going
to
resolve
whenever
they
resolve
they're,
not
they're,
not
all
being
resolved
together,
but
instead,
what
we're
saying
here
is
no
matter
how
many
times
you
do
that
they
are
actually
all
going
to
resolve
together
and
I'm,
just
wondering
if
that
you
know,
we
know
why.
A
That
would
be
the
case
if
we're
understanding
what's
going
on
behind
the
scenes
and
why
it
would
make
sense
for
things
to
operate
this
way.
I,
just
don't
know
if
people
that
are
just
trying
to
use
defer
would
see
the
logic
behind
this.
G
Just
got
like
an
idea:
bro
it
to
a
discussion
if
we
say
like,
if
you
say,
people
should
use
LS,
fragments
to
say
something
should
be
executed
in
parallel
me,
and
quite
you
you
untie
things,
can
we
can?
We
say
same
thing
about
like
which
tricky
query
we
have
in
the
beginning
of
the
duplication
issue.
G
Can
we
say,
like
everything
is
merged,
like
even
between
parallel
things,
so
like
basically
like
treat
before
as
attribute
of
a
field,
and
if
you
want
to
the
duplication
on,
if
you
want
to
disable
the
duplication,
if
you
want
to
something
executive
in
parallel,
you
need
to
do
Alias,
fragments
right
because
now,
as
you
say,
it's
like
it's
weird
mental
model,
some
things
like
merged
and
some
not
and
we
base
that
on
implementation
details.
But
it's
hard
to
yeah
yeah.
G
We
can
explain
that
which
one
with
which
syntax
with
the
semantics
we
try
as
much
as
possible
to
just
duplicate
and
concrete
rule
based
on
what
we
can
statically
analyze
and
not
it's
an
answer.
It's
like
logical
answering
for
answer,
but
it's
not
it's
not
the
rule
of
thumb.
So
people
who
can
person
who
can
the
query
person
need
to
understand
right
some
more
complicated
rules.
G
Maybe
we
just
say,
like
everything
gets
like
fully
immersed
fully
deduplicate,
so
so
in
initial
query,
so
a
few
days
everything
is
like
much
but
but
and
to
untie.
If
you
want
Soul
field
a
and
so
field
B
to
B,
like
independent,
you
need
to
use
Alias
fragment
in
that
case,
like
mental
model
is
simple
like
if,
if
you
don't
use
LS
fragments
everything
is
like
Bunch
into
into
like
one
thing
as
much
as
possible
shift
shift
in
initial
response.
Everything
else
is
shaped
based
on
on
a
layer
and
batch
together.
G
So
so
few
days
off
will
be
patched
together,
but
if
you
want
to
have
it
independently,
you
use
earliest
fragments-
and
in
that
case,
like
mental
model
for
people
like
easy
default
default.
Behavior
is
deduplication,
but
you
have
full
control
to
enable
like.
G
G
No,
we
can
like
we
can
merge
stuff
and
create
like
a
if,
if
you
show
like
entire
example
of
acquiring
no
no
a
ball
example.
No
like
from
this
application
issue,
like
top
examples
that
you
wrote
yeah
example
B
and
which
one
is
more
complicated,
so
yeah.
So
we
will
send
a
basically.
G
We
will
send
GH
and
potentially
so
field
a
and
potentially
solved
field
b
as
one
pilot,
and
we
will
send
sorry
confused
yeah
we'll
send
the
first
path,
basically
like
empty
and
as
much
as
things
we
can
push
into
MTA
minion,
quake,
GH
and
potentially
solved
field
B
and
after
wet
sand.
G
G
We
just
break
a
rule
that
current
row
that
parallel
here
he
executed
independently
if
default,
if
G4
is
the
final
different
levels
that
the
first
execute
in
parallel
independently.
In
that
case,
we
have
like
one
by
what
per
path
we
have
statically,
predictable
shapes
and
we
will
have
like
like
we
will
basically
have
everything
accept.
You
will
always
have
a
soul
field,
B
being
delivered
first,
always
and
so
field
a
always
delivered
like
in
subsequent
pilot
in
the
without,
like
no
matter
what
which
one
will
get
the
result.
D
G
A
That
was
if
what
I've
been
saying
would
actually
work
that
doesn't
line
up
with
any
of
the
options
we
have
above.
Does
it
I?
Guess
it's
a
variation
of
one
of
the
options
with
a
need
to
have
Alias
fragments
be
able
to
use
Alias
fragments?
B
I
wrote
a
message
into
the
chat
here
regarding
what
you
asked
before,
with
all
the
nested
defers
in
the
same
selection
set
and
I.
Think.
B
Effectively
the
way
that
I
see
it
where
you've
got
sibling
to
first
then,
then
merging
makes
a
lot
of
sense
because
it's
just
like
field
merging
effectively.
If
you
imagine
that
the
app
defer
is
the
same
as
a
foo
field,
then
a
at
for
a
and
an
ad
for
B
would
become
an
antifa
A
B
same
as
through
a
and
fubi
would
become
Foo
a
b,
but
when
it's,
when
the
defers
are
effectively
at
the
same
path
but
nested
inside
of
each
other,
it
does
get
more
subtle
at
the
moment.
B
Yeah
I
I
agree
with
you.
There
I'm
I
think
it's
okay
for
us
to
do
that,
and
for
it
to
be
an
educational
thing,
as
you
say,
but
it
is
definitely
something
that
we
should
go
into
with
our
eyes
open
and
make
sure
that
we
make.
You
know
signpost
it
correctly
that
we've
thought
about
this,
and
this
is
why
we've
decided
to
do
it.
This
particular
way,
yeah.
A
Yeah
I
I
have
a
feeling
that
you
know
it
went
defer,
is
more
widespread,
you're,
just
we're
going
to
see
a
lot
of
developers
who
are
like.
Oh,
this
field
is
slow,
hey
I
can
just
put
defer
on
it
and
not
think
about
the
ramifications
at
all.
A
They're
just
gonna
be
like
I'll
just
get
this
later
and
then
they're
gonna,
say:
oh
that
worked
hey
this
Field's
slow,
I'm
gonna,
put
defer
on
it
too,
and
it's
gonna
be
in
the
same
selection
set
and
they're
not
really
going
to
think
about
what
that
means
behind
the
scenes
and
they're
just
going
to
expect
to
see
the
same
type
of
Behavior
when
they
do
that
as
they
did
with
the
first
field
and
all
of
a
sudden,
they
might
start
to
realize.
Oh
wait,
a
sec.
A
B
B
I
have
kind
of
the
the
same
expectation
of
user
behavior,
but
with
the
alternate
of
I
would
want
them
to
come
like
I
would
want
all
of
the
initial
stuff
first
and
then
all
of
the
Deferred
stuff.
Second
right
in
most
of
my
use
cases,
I
certainly
want
it,
wouldn't
want
it
spread
over
like
hundreds
of
payloads,
because
I've
done,
hundreds
of
defers
yeah,
so
I'm,
actually
I'm,
okay
with
that
behavior
and
making
it
so
that
I
have
to
explicitly
signpost
it.
B
If
I
want
to
say
actually
these
two
things
I
want
them
to
run
independently
of
each
other
yeah
as
much
as
anything
I
want
to
avoid
that
sort
of
explosion
of
future
payloads.
If
we
can
avoid
that
and
give
the
server
and
the
network
and
the
serialization
of
deserialization
and
the
client
writing
to
its
store,
all.
A
D
D
A
E
D
Anyway,
this
other
thing
I
wanted
to
discuss,
which
I
think
might
actually
be
a
symptom
of
the
same
issue
of
Fields
being
executed
multiple
times
when
they're
in
defer
and
figuring
out
a
solution
for
that
might
resolve
this.
But
if
you
have
a
query
like
this,
where
there's
a
blog
post
and
a
field,
that's
like
most
recent
comment.
D
You
have
IDs
in
there
you
have
author
and
we'll
assume
that
the
client
is
something
like
relight,
where
it
uses
the
ID
field
as
its
store,
Key
and
and
has
follows,
like
the
specification
that
you
know
its
are:
are
a
global
object,
our
way
to
globally
identify
objects?
D
If
the
execution
like
in
the
furthest,
Affair
does
execute
most
recent
comment
separately
than
in
the
initial
payload
and
we'll
say
there
was
a
new
comment
left
in
between
the
time
that
that
happened
and
all
these
IDs
get
deduplicated.
You
could
get
a
situation
where
you
know
you
have
like
details
about
the
author,
but
now
you
have
the
bio
comes
in,
but
it's
for
a
different
person
and
there's
no
way
for
a
client
to
know
that
the
initial
data
is
now
stale.
B
This
this
wouldn't
be
an
issue
with
the
way
that
I
was
proposing
earlier
the
the
collect,
Fields
based
approach,
because
there
would
be
no
second
execution
of
the
most
recent
comment
like
it
would.
It
would
already
be
carried
through,
and
the
selection
would
then
be
done
on
the
pre-resolved
value
of
the
the
author
that
had
already
been
pulled
down
with
the
ID
and
name.
The
bio
would
then
be
evaluated
on
that
same
object
at
a
later
stage
and
I
think
it's
essential
that
we
do
something
like
that.
B
D
Yeah
yeah
I
I
agree
that
I
think
that
this
shows
that
that
is
essential.
If
there's
also
going
to
be
deduplication,
so
yeah
I'll
I'll
give
you
some
time
to
write
it
up
or
if
you
just
want
to
explain
it
to
me
over
a
Discord
or
something
and
I
could
work
on
it
either
either
one
works
and
then
I
think
that
we
should
look
at
that
and
regroup
again.
B
Yeah,
this
is
actually
like
when
we,
when
we
did
the
input
Union
stuff.
We
came
up
with
these
sort
of
like
decision
points,
and
this
is
actually
a
decision
point
there
that
that
says,
if
we
don't
de-duplicate,
then
everything's
fine,
because
this
won't
break.
But
if
we
do
de-duplicate,
then
whatever
solution
we
come
up
with
must
not
cause
confusion
in
this
case,
and
we
can
now
use
this
example
as
a
as
a
criteria
to
apply
to
all
of
the
different
solutions
which
I
think's
really
really
valuable.
This
is
a
really
valuable
example.
B
A
Okay,
so
aim
to
regroup
is
that
the
game
plan.
C
A
Okay,
super
quick
question:
what's
what
is
the
tracking
issue
for
fragment
aliases?
Does
anyone
do
we
have
like
a
very
clear
tracking
issue
somewhere,
because
the
original
fragmentalius's
issue
in
the
graphql
spec
repo
was
closed
a
long
time
ago,
I'm
just
wondering
if
we
have
somewhere,
where
that's
clearly
defined
and
there's
somebody
that's
a
champion
for
it
et
cetera,
et
cetera,.
G
B
It
fragment
modularity,
oh.
E
F
I
think
the
first
step
is
fragment
arguments
and
I.
Think
and
then
and
then
you
know
sort
of
like
we're.
Building
to
that
got
it
you're.
G
A
G
I
think
so,
because,
like
previously,
since
we
are,
we
saying
that
people
need
to
have
control
over
these
things
and
we
specifically
remove
rainbow
in
favor
that
whether
it
can
be
done
with
fragmental.
Yes,
it's
been
like,
we
really
consider
fragment
addresses,
so
it's
it's
at
least
2x
stage,
one
right.
So
we
we
really
agree
that
there
is
use
case
and
we're
working
on
it.
G
So
the
whole
idea,
instead
of
projected
yeah
instead
of
rejected
it,
should
be
stage.
One
one
thing
I
would
suggest,
is
to
contact
Matt
and
ask
him
if
he
want
to
be
a
visual
champion,
and
if
you
want
to
be
efficient,
he
have
a
capacity
to
be.
In
that
case,
he
will
decide
he
will
decide
either
like
or
open
hold
one
or
create
new
one.
Whatever
will
work
for
him,
but
I
think
we
should
ask
him
first,
since
he
have
the
strongest
use
case
and
issue
was
opened
by
him
right
once
it
was
rejected.
No.
D
No,
this
issue-
this
is
very
old,
it's
not
very
old,
but
the
fragment,
modularity
discussion,
I
think
came
from
quite
a
bit
time
after
this
one
was
was
closed.
So
I,
don't.
G
G
A
D
Well,
it
is
in
the
there's
the
RFC
here
right,
I,
guess,
I,
don't
know
yeah
all
right,
but
also
like
yeah
as
Benji
wrote
in
the
chat,
I
fragment
Ellie
says,
doesn't
have
to
be
the
the
solution
right,
but
but
we
are
like
I.
Do
I
think
we're
in
agreement
that
we
don't
want
to
solve
that
right
now
and
it
could
be
fragment,
aliases
and
fragment.
At
least
it
doesn't
work
out.
It
could
be
another,
we
could
add
back
label
or
some
other
argument
onto
defer.
E
D
Yeah,
so
maybe
I
should
have
a
discussion
or
or
I
could
I
should
update
the
one
about
removing
label
to
say
that
yeah
yeah.
E
G
So
if
you
understand
correctly
so
previously,
how
do
I,
you
know
our
communication.
We
specifically
said
like
at
least
during
this
discussion,
Alice
fragments
and
I
assume,
like
all
the
moments
are,
but
in
reality
what
happened:
the
removable,
syk
I'm,
making
scope
smaller.
So
we're
not
like
rejected
this
idea.
We
just
said
like
we
don't
want
to
it's
like
the
whole
thing
is
taking
too
much
time.
There
is
too
many
coronary
cases
too
many
stuff,
so
we
will.
We
will
figure
out
the
Twitter
okay,
in
my
case,
one
thing
in
future.
G
D
Yeah,
basically,
those
those
two
issues
that
I
want
was
what
I
wanted
to
to
talk
about
today.
I,
don't
have
anything
else
right
now.
Did
anyone
else
want
to
go
over
anything
else
or.
F
If
we
I'm
sorry
so,
do
we
have
like
a
new
algorithm
that
that
we're
going
to
potentially
work
on
is
I'm.
Sorry
I
dropped
off.
Unfortunately,
due
to
connectivity.
D
Yeah
Benji
said
that
he
was
going
to
write
something
up
this
week
for
us
to
work
off
of
okay.
F
Great
great
I
mean
using
the
algorithm
we
have,
we,
we
could
introduce.
I
mean
right
now
we
we
we
are
caching
based
on
you,
know
whether
leaves
have
set
been
sent
for
a
deduplication.
It's
very
easy
to
add
in
you
know,
instead
of
to
make
sure
that
we
don't
re-execute
anything
I
mean
that's
very
easy.
To
add
in
to
you
know
again
based
on
the
path.
Is
that
something
that
would
solve
these?
These
issues.
D
I'm
worried
that
that,
just
that,
if
it's
an
algorithm
that
still
like,
tries
to
execute
things,
but
we
just
rely
on
a
cache
that
is
like
making
a
trade-off
for
more
memory.
That
may
not
be
the
right
trade-off.
B
Oh
so,
just
to
be
clear:
I'm
probably
gonna
write
some
spec
edits
rather
than
actual
code,
just
because
I
think
I
have
an
a
better
idea
of
what
I
would
do
in
terms
of
the
spec
edits,
and
then
we
can
pull
that
to
code
and
vice
versa.
C
D
Oh
yeah,
and
for
this
issue
that
is,
it's
still
label,
was
it
as
an
open
question,
but
this
is
the
one
where
basically
we're
saying
that
we're
removing
labels
and
merging
everything
under
the
same
object,
I
I,
feel
like
that.
It
is
like
mostly
settled
but
I,
but
I'm,
but
I'm
leaving
it
open.
D
I
was
thinking
that
it
would
stay
open
until
we
do
like
agree
on
deduplication
just
in
case
the
whole
idea
of
deduplication,
somehow
backtracks,
all
the
way
to
here
to
change
this
decision,
but
I,
but
I
think
that
moving
forward
in
this
is
like
has
the
assumption
that
this
one
is
settled.
Does
that
make
sense.